Содержание статьи
На мысль написать такой текст меня навел комментарий заказчика, оставленный после завершения проекта. Он демонстрирует, какие, казалось бы, обычные вещи могут впечатлить и порадовать.
У нас была уязвимая библиотека с высоким CVSS, и при этом она легко эксплуатировалась. PoC не было, но составить его не проблема — коллеги из Китая оставили очень хорошие описания к CVE, за недельку можно заиметь боевой образец. Но мы знали, что благодаря нашим усилиям эта уязвимость была неприменима.
Мы ждали отчет с кричащими тегами CRITICAL. Но увидели эту библиотеку с маркером LOW. Исполнители прекрасно понимали, как мы защитились, сами же описали причину, по которой эта уязвимость не может быть проэксплуатирована, и корректно отметили, что библиотека уязвима и ее нужно обновить, когда появится патч.
После такого понимаешь:
Твое временное решение проблемы компетентно, раз сторонняя команда пришла к тому же выводу.
Исполнитель не просто использовал какие‑то анализаторы, но осмыслил происходящее, проанализировал потоки данных, сопоставил логику уязвимости и бизнес‑процессы. Получив такое, веришь, что он был настолько же дотошен и в других параметрах оценки.
Программа минимум
Итак, что же нужно делать, чтобы заказчики были счастливы и писали приятные отзывы?
- Самый важный аспект — вникать в логику работы. Не просто сканировать инфраструктуру, валидировать баги руками, что‑то тыкать и фаззить, но еще и понять, как работает сервис, посмотреть потоки данных и взаимодействие с остальными микросервисами и интеграциями.
- Покрывать все сервисы автоматизированными средствами.
- Валидировать все уязвимости. Не просто отдавать репорты сканера, обернутые в логотипы твоей компании, а обязательно проверять, что каждая найденная уязвимость реальна.
- Корректировать уровень опасности уязвимостей согласно критичности сервиса и возможности эксплуатации. Даже если сканеры пишут, что уязвимость критична, нужно учитывать обстоятельства: можно ли ее проэксплуатировать, есть ли реальные уязвимости с PoC, критичный ли сервис и так далее.
- Весь чек‑лист пройден в ручном режиме. 90% работы над проектом должно занимать ручное тестирование, ресерч, попытки эксплуатации именно в ручном режиме.
Как писать отчет
Отчет — это результат проекта, ради него все и делается, поэтому переоценить его значение вряд ли возможно. В хорошем отчете должны быть:
Единый стиль изложения, отсутствие грамматических и стилистических ляпов, описание рисунков, схем, таблиц. Чтобы всем было приятно смотреть на отчет и содержание было предельно ясным.
-
Детальное описание недостатков. Не просто общее описание, а для конкретных случаев: где нашли уязвимость, в каком параметре или модуле.
-
Примеры эксплуатации. Показаны найденные баги, прикреплена картинка как пруф. Читающий может повторить действие с картинки. Также не помешает детальное описание процесса тестирования, ссылки на базы уязвимостей ФСТЭК России или техник MITRE.
-
Рекомендации также прописаны для конкретных случаев, описаны точечные советы, именно для того фреймворка и стека технологий, который использует заказчик. Нет двусмысленности. Есть разные варианты устранения.
Например, ты нашел уязвимость, которая позволяет перебирать пользователей. Система реагировала по‑разному в тех случаях, когда пользователь существует и когда его нет. Можно дать общую рекомендацию — внедрить CAPTCHA-тест. Но если знаешь, что у заказчика используется, например, Django, то можно дать рекомендации именно для этого фреймворка.
Резюме работы с цифрами, рекомендациями и выводом.
Отчет оформлен на основе вопросов, заданных заказчиком перед проектом. Затем идет то, что специалисты считают важным и релевантным. Если вопросов не было, то по иерархии критичности всех находок.
Приведена аналитика: количество уязвимостей, хостов, которые были проверены, или топ уязвимостей в компании, или динамика по предыдущим пентестам и времени жизни уязвимостей, если есть такая возможность.
-
Моделирование угроз поведения злоумышленника. Нужно показать, что случится, если злоумышленник проэксплуатирует уязвимость. Например, уязвимость с SMS-спамом, как правило, заказчики не понимают. Поэтому нужно показать, в чем ее риск, объяснить, что провайдер позволяет крупным компаниям отправлять до 3 тысяч SMS в секунду. На отправку 200 запросов компания тратит 400 рублей в секунду. Если атака длится час, то злоумышленник сожжет почти 1,5 миллиона рублей с баланса компании.
Что важно обсудить
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»