Нахождение уязвимости составляет лишь половину работы специалиста по тестированию на проникновение. Вторая половина заключается в том, чтобы убедить бизнес закрыть эту брешь, а не скрыть её в таблице с пометкой «принятый риск» ради соблюдения сроков релиза.
Построение цепочки атаки: от пассивной разведки до закрепления
Профессиональное тестирование на проникновение никогда не начинается с запуска автоматических сканеров. Хаотичный перебор уязвимостей без понимания архитектуры цели приводит к шуму в логах и нулевому результату. Процесс строится строго по фазам, где каждая последующая опирается на данные, собранные на предыдущей.
Пассивная разведка (OSINT) позволяет собрать информацию, не оставляя следов в логах целевой инфраструктуры. Использование инструментов вроде Amass или Subfinder помогает выявить забытые поддомены, которые часто остаются без обновлений и защиты. Запрос amass enum -passive -d target.com собирает данные из открытых источников, не отправляя ни одного пакета на целевые серверы. Параллельно проверяются утечки в Shodan или Censys. Поисковый запрос http.title:"Панель управления" org:"НазваниеКомпании" часто выдает забытые тестовые стенды или административные интерфейсы, доступные из внешней сети.
Активная разведка требует осторожности. Сканирование портов через Nmap должно быть настроено так, чтобы не положить сервис и не спровоцировать срабатывание систем предотвращения вторжений. Команда nmap -sV -sC -p- --min-rate 1000 --max-retries 2 target.com обеспечивает баланс между скоростью и скрытностью. Флаг -sV определяет версии сервисов, что критически важно для поиска конкретных CVE, а --min-rate предотвращает слишком агрессивное поведение, которое может быть расценено как DoS-атака.
После выявления вектора проникновения начинается фаза эксплуатации. Получение первоначального доступа (Initial Access) редко является конечной целью. Настоящая ценность представляет горизонтальное перемещение и повышение привилегий. Найденная уязвимость в веб-приложении часто служит лишь трамплином для доступа к внутренней сети, где расположены базы данных, контроллеры домена или системы управления конфигурациями. Закрепление в системе (Persistence) обеспечивает сохранение доступа даже после перезагрузки сервера или смены паролей администраторами.
Реальный сценарий: почему «внутренняя» уязвимость часто оказывается критической
Наиболее частые споры между пентестерами и разработчиками возникают вокруг уязвимостей, обнаруженных во внутренних сервисах. Разработчики часто аргументируют снижение критичности тем, что система находится за корпоративным периметром и недоступна из интернета. Этот аргумент игнорирует реальность современных корпоративных сетей, где граница доверия размыта.
Рассмотрим конкретный кейс. В ходе тестирования внутренней системы документооборота обнаружена уязвимость SSRF (Server-Side Request Forgery). Разработчик классифицирует её как Low или Medium, утверждая, что атакующий и так находится внутри сети, и доступ к внутренним ресурсам не является чем-то экстраординарным.
Пентестер строит цепочку эксплуатации, доказывающую обратное. Через SSRF отправляется запрос к внутреннему сервису Jenkins, который часто развернут без аутентификации в локальной сети. Используя функционал Jenkins Script Console, пентестер выполняет произвольный код на языке Groovy. Это дает полноценный Remote Code Execution (RCE) на сервере сборки. С этого сервера, имеющего повышенные привилегии в домене, извлекаются учетные данные или выполняется атака типа Pass-the-Hash для захвата контроллера домена.
В этом сценарии первоначальная уязвимость SSRF превращается в критическую точку компрометации всей инфраструктуры. Ограничение доступа извне не защищает от скомпрометированной рабочей станции сотрудника, которая уже находится внутри периметра и может инициировать этот запрос.
Аргументация через CVSS: как математически доказать критичность
Эмоциональные споры о степени опасности уязвимости бесполезны. Единственный объективный язык, понятный и специалистам по безопасности, и руководителям, — это метрики CVSS (Common Vulnerability Scoring System). Версия 3.1 предоставляет детальный калькулятор, позволяющий обосновать оценку цифрами.
Вернемся к примеру с внутренним SSRF, ведущим к RCE. Разработчик настаивает на оценке Medium. Пентестер заполняет вектор CVSS следующим образом:
- Attack Vector (AV): Network (N). Уязвимость эксплуатируется по сети.
- Attack Complexity (AC): Low (L). Для эксплуатации не требуются специальные условия.
- Privileges Required (PR): None (N) или Low (L), в зависимости от того, нужна ли аутентификация в исходном приложении.
- User Interaction (UI): None (N). Действия жертвы не требуются.
- Scope (S): Changed (C). Это ключевой момент. Уязвимый компонент (веб-приложение) и скомпрометированный компонент (сервер Jenkins или контроллер домена) находятся под разными границами безопасности. Изменение Scope автоматически повышает базовый балл.
- Confidentiality (C), Integrity (I), Availability (A): High (H). Полный контроль над системой означает компрометацию всех трех параметров.
Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H дает оценку 9.1 (Critical). Предъявление разработчику этого вектора с пояснением, что параметр Scope изменен из-за выхода за пределы исходного приложения, снимает субъективные возражения. Математика не оставляет места для интерпретаций.
Переговоры с разработчиками: скрипты и тактика отстаивания рисков
Ситуация, когда заказчик просит понизить критичность уязвимости перед релизом, чтобы избежать задержек, является классической проверкой профессионализма пентестера. Соглашение на такое требование перекладывает ответственность за будущий инцидент на специалиста по безопасности.
Первое правило переговоров: не принимать решения в одиночку. Если разработчик или менеджер проекта давит с требованием снизить оценку, ответ должен быть перенаправлен на уровень выше. Фраза «Я не могу изменить оценку, так как она рассчитана по стандартной методологии. Если вы считаете риск приемлемым, давайте оформим это как принятый риск (Risk Acceptance) с подписью вашего руководителя или CISO». Это мгновенно меняет динамику разговора, так как менеджер редко готов взять на себя персональную ответственность за игнорирование критической уязвимости.
Второй аргумент касается будущих аудитов. «Снижение критичности сейчас не удалит уязвимость из системы. При следующем внешнем или внутреннем аудите эта же уязвимость будет обнаружена снова, и в отчете будет указано, что она была известна, но проигнорирована. Это создаст гораздо больше проблем для вашего отдела, чем задержка релиза на один спринт для установки патча».
Третья тактика — предложение временного компенсирующего контроля. Если полноценный фикс действительно требует времени, пентестер может предложить временное решение. Например, ограничение доступа к уязвимому эндпоинту через правила WAF или настройку сетевого экрана до момента выпуска обновления кода. Это демонстрирует гибкость и нацеленность на решение бизнес-задачи, а не просто на создание проблем.
Инструментарий и стандарты оформления отчета
Качество отчета определяет восприятие всей работы пентестера. Разработчик не будет читать многостраничные эссе о методологии. Ему нужны четкие, воспроизводимые инструкции.
Каждая найденная уязвимость в отчете должна содержать следующие обязательные блоки:
- Краткое описание и оценка CVSS.
- Влияние на бизнес (Impact): что именно злоумышленник может сделать, выраженное в бизнес-терминах (утечка персональных данных, остановка производства), а не только в технических.
- Пошаговое руководство по воспроизведению (Reproduction Steps).
- Рекомендации по устранению (Remediation).
Раздел воспроизведения должен быть настолько точным, чтобы разработчик мог скопировать команду и получить тот же результат. Использование формата curl предпочтительнее скриншотов из Burp Suite, так как текст можно скопировать и выполнить.
Пример корректного описания шагов:
# 1. Получаем валидный токен аутентификации
TOKEN=$(curl -s -X POST https://target.com/api/login -d '{"user":"test","pass":"test"}' | jq -r '.token')
# 2. Эксплуатируем уязвимость, подменяя параметр id
curl -s -X GET "https://target.com/api/document?id=1' OR '1'='1" \
-H "Authorization: Bearer $TOKEN"Такой формат исключает двусмысленность. Скриншоты добавляются только как визуальное подтверждение успеха, но не как замена текстовой инструкции.
Для управления процессом тестирования и генерации отчетов профессиональные команды используют специализированные платформы, такие как Dradis или Faraday. Эти инструменты позволяют импортировать результаты сканеров (Nmap, Nessus), структурировать находки, назначать ответственных и отслеживать статус исправления уязвимостей в режиме реального времени, интегрируясь с Jira или другими трекерами задач.
Отчет не является конечной точкой взаимодействия. Презентация результатов техническим командам — обязательный этап. На этой встрече пентестер проходит по каждому критическому и высокому риску, демонстрирует эксплойт в действии и совместно с разработчиками обсуждает реалистичные сроки и методы устранения. Такой подход превращает пентест из «аудитора, который ищет недостатки» в партнера, помогающего сделать продукт безопаснее.