Битрикс имеет довольную обширную базу кода, для изучения которой нужно потратить в разы больше времени. Мы хотели бы заняться изучением и этой CMS’ки, но пока это скорее в планах, т.к. нужно будет еще обсуждать все с владельцами системы.
Joomla и Wordpress уже неплохо освещены в различных исследованиях и секьюрити блогах, а мы хотели сконцентрироваться на менее обсуждаемых, но часто встречающихся CMS системах.
Они это делают, похожим образом, но делают.
Но не успевают, ведь нужно некоторое время на индексацию и анализ «вредоносного» сайта, а за это время злоумышленники могут успеть собрать сливки с первых своих жертв и перейти к следующим вариантам фишинга.
Люди должны учиться и знать базовые основы ИБ — не переходить по ссылкам от неизвестных лиц, проверять сайт поиском в гугле\яндексе, не вводить данные если есть подозрения и т.д. Не стоит свою безопасность и безопасность своих данных перекладывать на большие компании, ведь даже если они будут это делать быстрее, злоумышленники могут найти новые способы для фишинга.
В статье описывается начальный уровень зрелости у компании, имеющей команду защиты (SoC), т.е. компания которая только внедряет или закончила внедрять SoC.
Хотели сказать следующее – компания решила внедрить свой (аутсорсинговый) SoC, она хочет понять и сделать правильные настройки, для этого она может заказать киберучения, такой purple team. В этом случае команда атакующих и команда защиты будет работать совместно и проверять сразу настройки IoC, срабатывание СЗИ и указывать на их подгонку под клиента.
Но да, если говорить про начальный уровень зрелости (без расчета SoC), то улучшение защищенности стоит начинать с анализа защищенности\пентеста.
Отвечу просто в ветке: DenisTrunin как правильно заметили выше — зайти под его учеткой, сделать экспорт паролей и использовать их в сети.
VitalKoshalew админ это не всегда сотрудник обладающий правами админа в домене, это может быть администратор какой-либо системы. База паролей позволяет получить доступы чуть по другому.
Всегда по разному и мы используем разные инструменты.
Например для автоматического рекурсивного подбора можно использовать — github.com/rbsec/dnscan
Я иногда предпочитаю руками делать, потому что можно будет отказаться от некоторых поддоменов и проводить работы более тонко, для этого я использую — github.com/infosec-au/altdns
Поделиться внутренней статистикой я не смогу, ее надо полноценно готовить.
Могу поделиться исследованием Rapid7 (https://www.rapid7.com/research/report/under-the-hoodie-2019/), в нем есть статистика, и она, в принципе, будет похожа на нашу.
Если говорить про остальное, то:
>В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.?
В целом, можно сказать 100%, правда это будет не совсем правдой, т.к. не всегда перед нами ставится задача пройти периметр. Иногда это были задачи по получению доступов к определенным серверам на внешнем периметре.
Если говорить про максимальные привилегии в проектах по внутреннему тестированию на проникновение, то всегда, правда, были проекты, где это было не нужно, и мы получали доступы на сервера обозначенные клиентом почти с минимальными правами.
>Были ли какие-то случаи, когда ничего сделать не получалось?
Чтобы прям совсем ничего — нет, бывали случаи, когда мы не закрывали все цели из списка задач клиента.
В целом надо понимать, что проект по пентесту длится ограниченное время и с ограничениями в используемых подходах (например, нельзя использовать эксплойты на определенных серверах).
>Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
По векторам ответил выше ссылкой.
Но если ответить кратко, то будет как-то так:
1) да, чаще всего это уязвимости web — sqli\file-upload\торчащие админки
2) плохие парольные политики и реиспользование паролей, причем это характерно как для внешних, так и для внутренних тестов
3) устаревшее ПО и отсутствие патчей, нередки ситуации, когда патчатся известные уязвимости (ms17-010), но на внешнем периметре может находиться редкий веб-сервер, для которого есть rce 2-3 летней давности
Хороший комментарий, но к сожалению не все зависит от нас. Потому что часть работы должна быть выполнена внутренней службой ИБ.
Перевести в реальные риски и деньги могут только внутренние безопасники, мы обычно с ними обговариваем к чему могут привести найденные нами уязвимости\недостатки, а дальше уже они принимают решение сколько стоит та или иная уязвимость в деньгах и решают со своим руководством — фиксить или нет.
К сожалению да, иногда встречаются случаи когда не фиксят уязвимости найденные в прошлом году.
Битрикс имеет довольную обширную базу кода, для изучения которой нужно потратить в разы больше времени. Мы хотели бы заняться изучением и этой CMS’ки, но пока это скорее в планах, т.к. нужно будет еще обсуждать все с владельцами системы.
Joomla и Wordpress уже неплохо освещены в различных исследованиях и секьюрити блогах, а мы хотели сконцентрироваться на менее обсуждаемых, но часто встречающихся CMS системах.
Но не успевают, ведь нужно некоторое время на индексацию и анализ «вредоносного» сайта, а за это время злоумышленники могут успеть собрать сливки с первых своих жертв и перейти к следующим вариантам фишинга.
Люди должны учиться и знать базовые основы ИБ — не переходить по ссылкам от неизвестных лиц, проверять сайт поиском в гугле\яндексе, не вводить данные если есть подозрения и т.д. Не стоит свою безопасность и безопасность своих данных перекладывать на большие компании, ведь даже если они будут это делать быстрее, злоумышленники могут найти новые способы для фишинга.
Хотели сказать следующее – компания решила внедрить свой (аутсорсинговый) SoC, она хочет понять и сделать правильные настройки, для этого она может заказать киберучения, такой purple team. В этом случае команда атакующих и команда защиты будет работать совместно и проверять сразу настройки IoC, срабатывание СЗИ и указывать на их подгонку под клиента.
Но да, если говорить про начальный уровень зрелости (без расчета SoC), то улучшение защищенности стоит начинать с анализа защищенности\пентеста.
Тут скорее это пример того, что иногда забывают настроить FW до конца.
DenisTrunin как правильно заметили выше — зайти под его учеткой, сделать экспорт паролей и использовать их в сети.
VitalKoshalew админ это не всегда сотрудник обладающий правами админа в домене, это может быть администратор какой-либо системы. База паролей позволяет получить доступы чуть по другому.
Например для автоматического рекурсивного подбора можно использовать — github.com/rbsec/dnscan
Я иногда предпочитаю руками делать, потому что можно будет отказаться от некоторых поддоменов и проводить работы более тонко, для этого я использую — github.com/infosec-au/altdns
Могу поделиться исследованием Rapid7 (https://www.rapid7.com/research/report/under-the-hoodie-2019/), в нем есть статистика, и она, в принципе, будет похожа на нашу.
Если говорить про остальное, то:
>В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.?
В целом, можно сказать 100%, правда это будет не совсем правдой, т.к. не всегда перед нами ставится задача пройти периметр. Иногда это были задачи по получению доступов к определенным серверам на внешнем периметре.
Если говорить про максимальные привилегии в проектах по внутреннему тестированию на проникновение, то всегда, правда, были проекты, где это было не нужно, и мы получали доступы на сервера обозначенные клиентом почти с минимальными правами.
>Были ли какие-то случаи, когда ничего сделать не получалось?
Чтобы прям совсем ничего — нет, бывали случаи, когда мы не закрывали все цели из списка задач клиента.
В целом надо понимать, что проект по пентесту длится ограниченное время и с ограничениями в используемых подходах (например, нельзя использовать эксплойты на определенных серверах).
>Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
По векторам ответил выше ссылкой.
Но если ответить кратко, то будет как-то так:
1) да, чаще всего это уязвимости web — sqli\file-upload\торчащие админки
2) плохие парольные политики и реиспользование паролей, причем это характерно как для внешних, так и для внутренних тестов
3) устаревшее ПО и отсутствие патчей, нередки ситуации, когда патчатся известные уязвимости (ms17-010), но на внешнем периметре может находиться редкий веб-сервер, для которого есть rce 2-3 летней давности
Перевести в реальные риски и деньги могут только внутренние безопасники, мы обычно с ними обговариваем к чему могут привести найденные нами уязвимости\недостатки, а дальше уже они принимают решение сколько стоит та или иная уязвимость в деньгах и решают со своим руководством — фиксить или нет.
К сожалению да, иногда встречаются случаи когда не фиксят уязвимости найденные в прошлом году.