Comments 9
Проводите периодические тестирования на проникновение — они помогут вам найти тонкие места, которые вы могли пропустить на стадии разработки или при переходе с тестовых сред на боевые.
А еще лучше проводить периодический аудит кода и инфраструктуры. Т.е. давать аудиторам возможность работы методом белого, а не черного, ящика. И дешевле, и результативнее.
у нас недавно тоже тесты делали, а может и не делали, прислали список проблем, где только название атаки и всё, типа если хотите подробнее это за дополнительную плату :D
не знаю сколько это стоило, но такой список и я бы мог составить, особенно если учесть что ничего серьёзного не нашли, может надо «русских хакеров» порекомендовать нашим, надо только выяснить есть ли правильный сертификат у таких тестеров
не знаю сколько это стоило, но такой список и я бы мог составить, особенно если учесть что ничего серьёзного не нашли, может надо «русских хакеров» порекомендовать нашим, надо только выяснить есть ли правильный сертификат у таких тестеров
Да лишь бы только при всех этих прикольностях перевести результаты в реальные риски и деньги, и заставить всё это пофиксить. А то иной раз приходишь, открыл прошлогодний отчёт, и повторил его по пунктам
Хороший комментарий, но к сожалению не все зависит от нас. Потому что часть работы должна быть выполнена внутренней службой ИБ.
Перевести в реальные риски и деньги могут только внутренние безопасники, мы обычно с ними обговариваем к чему могут привести найденные нами уязвимости\недостатки, а дальше уже они принимают решение сколько стоит та или иная уязвимость в деньгах и решают со своим руководством — фиксить или нет.
К сожалению да, иногда встречаются случаи когда не фиксят уязвимости найденные в прошлом году.
Перевести в реальные риски и деньги могут только внутренние безопасники, мы обычно с ними обговариваем к чему могут привести найденные нами уязвимости\недостатки, а дальше уже они принимают решение сколько стоит та или иная уязвимость в деньгах и решают со своим руководством — фиксить или нет.
К сожалению да, иногда встречаются случаи когда не фиксят уязвимости найденные в прошлом году.
Было бы интересно узнать статистику.
В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.? Были ли какие-то случаи, когда ничего сделать не получалось? Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.? Были ли какие-то случаи, когда ничего сделать не получалось? Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
Поделиться внутренней статистикой я не смогу, ее надо полноценно готовить.
Могу поделиться исследованием Rapid7 (https://www.rapid7.com/research/report/under-the-hoodie-2019/), в нем есть статистика, и она, в принципе, будет похожа на нашу.
Если говорить про остальное, то:
>В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.?
В целом, можно сказать 100%, правда это будет не совсем правдой, т.к. не всегда перед нами ставится задача пройти периметр. Иногда это были задачи по получению доступов к определенным серверам на внешнем периметре.
Если говорить про максимальные привилегии в проектах по внутреннему тестированию на проникновение, то всегда, правда, были проекты, где это было не нужно, и мы получали доступы на сервера обозначенные клиентом почти с минимальными правами.
>Были ли какие-то случаи, когда ничего сделать не получалось?
Чтобы прям совсем ничего — нет, бывали случаи, когда мы не закрывали все цели из списка задач клиента.
В целом надо понимать, что проект по пентесту длится ограниченное время и с ограничениями в используемых подходах (например, нельзя использовать эксплойты на определенных серверах).
>Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
По векторам ответил выше ссылкой.
Но если ответить кратко, то будет как-то так:
1) да, чаще всего это уязвимости web — sqli\file-upload\торчащие админки
2) плохие парольные политики и реиспользование паролей, причем это характерно как для внешних, так и для внутренних тестов
3) устаревшее ПО и отсутствие патчей, нередки ситуации, когда патчатся известные уязвимости (ms17-010), но на внешнем периметре может находиться редкий веб-сервер, для которого есть rce 2-3 летней давности
Могу поделиться исследованием Rapid7 (https://www.rapid7.com/research/report/under-the-hoodie-2019/), в нем есть статистика, и она, в принципе, будет похожа на нашу.
Если говорить про остальное, то:
>В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.?
В целом, можно сказать 100%, правда это будет не совсем правдой, т.к. не всегда перед нами ставится задача пройти периметр. Иногда это были задачи по получению доступов к определенным серверам на внешнем периметре.
Если говорить про максимальные привилегии в проектах по внутреннему тестированию на проникновение, то всегда, правда, были проекты, где это было не нужно, и мы получали доступы на сервера обозначенные клиентом почти с минимальными правами.
>Были ли какие-то случаи, когда ничего сделать не получалось?
Чтобы прям совсем ничего — нет, бывали случаи, когда мы не закрывали все цели из списка задач клиента.
В целом надо понимать, что проект по пентесту длится ограниченное время и с ограничениями в используемых подходах (например, нельзя использовать эксплойты на определенных серверах).
>Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
По векторам ответил выше ссылкой.
Но если ответить кратко, то будет как-то так:
1) да, чаще всего это уязвимости web — sqli\file-upload\торчащие админки
2) плохие парольные политики и реиспользование паролей, причем это характерно как для внешних, так и для внутренних тестов
3) устаревшее ПО и отсутствие патчей, нередки ситуации, когда патчатся известные уязвимости (ms17-010), но на внешнем периметре может находиться редкий веб-сервер, для которого есть rce 2-3 летней давности
Подскажите, какой вы использовали инструмент для рекурсивного брутфорса поддоменов. Он автоматических набрутил поддомен пятого уровня или вы его перенастраивали при нахождении очередного поддомена?
Всегда по разному и мы используем разные инструменты.
Например для автоматического рекурсивного подбора можно использовать — github.com/rbsec/dnscan
Я иногда предпочитаю руками делать, потому что можно будет отказаться от некоторых поддоменов и проводить работы более тонко, для этого я использую — github.com/infosec-au/altdns
Например для автоматического рекурсивного подбора можно использовать — github.com/rbsec/dnscan
Я иногда предпочитаю руками делать, потому что можно будет отказаться от некоторых поддоменов и проводить работы более тонко, для этого я использую — github.com/infosec-au/altdns
Sign up to leave a comment.
Записки пентестера: случаи на охоте