Опубликовали на Хакере историю одного пентеста.

Рассказали, как недостатки конфигурации STUN сервера позволили проникнуть во внутреннюю сеть, обойти средства защиты и проэксплуатировать Log4Shell. Как удалось захватить виртуальную инфраструктуру с помощью генерации сессии для SAML-аутентификации, продвинуться по сети и получить доменного администратора с помощью классической техники «Pass the hash».

Статья родилась по итогам проекта для крупной ИТ-компании. Мы оценили возможность проникновения во внутреннюю сеть из внешней и дали рекомендации по устранению уязвимостей. Развивая атаки во внутренней сети, СЗИ блокировали вредоносный трафик, но обойдя СЗИ и проэксплуатировав Log4Shell, удалось получить доступ к гипервизору и захватить виртуальную инфраструктуру. Сделать дамп памяти, получить доменную учетную запись, повысить свои привилегии и стать администратором домена.

Короткий вывод — уровень злоумышленника необходимый для захвата ИТ-инфраструктуры должен быть достаточно высоким. Заказчик увидел пробелы в своем процессе патч-менеджмента и промашки администраторов — они хранили пароли в открытом виде и переиспользовали их на разных сервисах.

Можно ли считать этот результат удовлетворительным? Как вообще оценивать результаты пентеста? — Вот, что об этом думают специалисты со стороны заказчика:

«В одном из проектов была уязвимая библиотека, которая имела достаточно высокий CVSS и, при этом, достаточно просто эксплуатировалась. PoC не было, но составить его было вполне можно — коллеги из Китая оставили очень хорошие описания к CVE, за недельку можно заиметь боевой образец. Однако мы знали, что, в силу дополнительных усилений с нашей стороны, эта уязвимость была неприменима.

Мы ждали отчет с кричащими тегами «CRITICAL». В отчете мы увидели эту библиотеку с маркером «LOW». Исполнители прекрасно понимали, как мы защитились, сами же описали причину, по которым эта уязвимость не может быть проэксплуатирована и корректно подсветили факт того, что библиотека является уязвимой и её следует обновить, когда появится патч.

После такого понимаешь:

1) Твоё временное решение проблемы с уязвимостью в компоненте является компетентным — сторонняя команда пришла к тому же выводу.

2) Исполнитель не просто использовал какие-то анализаторы, но осмыслил происходящее, проанализировал потоки данных, сопоставлял логику уязвимости и бизнес-процессы. Получив такое, хочется верить, что он был настолько же дотошен и в других параметрах оценки».

В следующем посте расскажем другие критерии хорошего аудита. Стей Тюнд 🙌

#бенчмарк_пентеста