Всем привет! На связи Карпенко Савелий, специалист по тестированию на проникновение из группы по борьбе с уязвимостями в компании ТехВилл.
В рамках нашей работы мы регулярно тестируем Active Directory (AD). Это центральный сервис аутентификации и управления доступом во многих корпоративных сетях. С практической точки зрения ошибки в конфигурациях AD часто становятся главной причиной взлома, среди проблемных аспектов можно назвать неверное назначение прав, доступов и использование устаревших механизмов аутентификации. Наличие недостатков в конфигурациях даёт атакующему возможность последовательно поднимать уровень своих привилегий. Ниже собраны типовые ошибки конфигурации, которые чаще всего встречаются на проектах, и показано, как они складываются в цепочки компрометации.
На практике аудит и тестирование обычно начинаются с исходных учетных данных, которые предоставляет заказчик. Если их нет, проникновение в инфраструктуру часто происходит через внешн��е веб-сервисы и ошибки на периметре (утечки паролей, небезопасные публикации, уязвимости бизнес-приложений). В российской практике одним из наиболее частых векторов для входа считается инфраструктура 1С, из-за повсеместного использования и различного уровня поддержки здесь чаще встречаются и слабые настройки, и типовые уязвимости.
В рамках анализа типовых ошибок конфигурации Active Directory целесообразно выделить несколько повторяющихся классов misconfiguration, которые регулярно встречаются на проектах.
Открытые SMB-шары.
SMB-шары часто доступны Domain Users на чтение и нередко на запись. Отдельная проблема — это анонимный доступ к шарам, его необходимо убирать в первую очередь, потому что он даёт атакующему стартовую точку для инвентаризации ресурсов и поиска случайно оставленной информации. Запись в общую папку может использоваться не только для подмены/размещения файлов, но и как триггер для .lnk и подобных файлов, провоцирующих сетевые обращения и способных перехватывать NetNTLMv2 с последующим офлайн-подбором. В целом smb-шара на запись — это отдельная большая тема, количество вариантов злоупотребления там такое, что это заслуживает отдельной статьи. В связи с этим необходимо регулярно инвентаризировать шары и их ACL, а также ограничивать доступ по принципу наименьших привилегий.
Ошибки AD CS.
Неправильные шаблоны сертификатов AD CS дают выпускать сертификаты, пригодные для аутентификации, от имени других учётных записей, при наличии соответствующих условий и разрешений. Семейство ESC-сценариев даёт возможность повышения привилегий в рамках домена через один критичный сервис. На рисунке ниже показан пример шаблона, где сочетаются условия, характерные для ESC1: здесь аутентификация по сертификату разрешена, контроль выдачи упрощён, а права на запрос доступны широким группам пользователей.
NTLM relay при отсутствии подписи.
Если SMB signing и/или LDAP signing не являются обязательными, в��зможны атаки класса NTLM relay. В связке с другими проблемами (AD CS web enrollment) создается возможность для эскалации привилегий. По возможности нужно включать подпись и ограничивать NTLM (на практике включение подписи может приводить к замедлению работы сервисов, поэтому к данному вопросу нужно подходить с осторожностью).
Ниже приведена упрощённая схема, показывающая общий смысл relay-сценария. При отсутствии подписи атакующий может ретранслировать аутентификационные данные между сторонами, превращая попытку входа на одну цель в доступ к другой.
Kerberos delegation.
Неправильное делегирование дает возможность сервису обращаться от имени пользователя к сервисам и повышать свои привилегии внутри сети. Unconstrained delegation — рискованный механизм сам по себе, потому как при компрометации хоста/сервиса, которому оно выдано, атакующий может получить доступ к Kerberos-артефактам (в т. ч. TGT) пользователей, а затем использовать их для действий от их имени вплоть до компрометации домена. По возможности unconstrained delegation следует не применять, но при необходимости минимизировать охват, контролировать, где этот механизм работает, и мониторить подозрительную активность.
Также нередко старт тестирования на проникновение начинается с поиска доступных сетевых ресурсов, в том числе открытых или анонимно доступных SMB-шар. На таких шарах нередко оказываются скрипты и конфигурации, где порой ошибочно оставляют секреты (пароли, токены, ключи). Получив низкопривилегированную учётную запись, атакующий ищет пути эскалации, один из наиболее «коротких» путей — злоупотребление AD CS. При совпадении условий можно сделать сертификат, пригодный для аутентификации, и дальнейшего повышения привилегий вплоть до доменного администратора.
Это лишь одна из множества популярных цепочек для проникновения, в условиях крупной инфраструктуры, где взаимосвязи между сервисами не всегда очевидны, целесообразно привлекать опытного аудитора, способного последовательно выявить и описать системные проблемы, характерные для конкретной организации.
Сервисные учётные записи с SPN дают возможность запросить Kerberos service ticket, после чего слабый пароль можно подбирать офлайн в рамках атаки Kerberoasting (MITRE ATT&CK T1558.003). В связи с этим необходимы сильные пароли и регулярный аудит учётных записей с SPN и их привилегий.
Говоря о паролях, следует упомянуть частный кейс, связанный с ними, а именно переиспользование пароля локального администратора. Даже если на скомпрометированной машине нет сессий доменного администратора, наличие локального администратора с паролем, совпадающим на множестве хостов, безусловно, дает атакующему быстро собрать широкую поверхность для последующего продвижения и атаки.
Windows LAPS решает проблему повторного использования паролей локальных администраторов, их пароль становится уникальным для каждого устройства, а доступ к его чтению в каталоге ограничивается правами.
Следует подчеркнуть, что приведенные сценарии представляют лишь небольшую часть возможных путей компрометации Active Directory. Реальные attack path зависят от архитектуры домена, уровня зрелости администрирования и исторических решений, принятых в инфраструктуре.
На практике часто бывает так, что одной критичной мисконфигурации достаточно, чтобы открыть путь к полной компрометации, однако часто в компаниях со сформированным подходом к информационной безопасности продукта мисконфигурации формируются как сочетание нескольких проблем, которые соединяются в цепочку. Поэтому при аудите важно оценивать не только отдельные настройки, но и их взаимосвязь, имеющиеся разрешения и делегирование, аутентификационные параметры (signing/NTLM), управление секретами (gMSA/LAPS) и состояние AD CS.
Для нас аудит — это повседневная практика, мы проводим глубокий анализ, ориентированный на понимание того, как конкретная инфраструктура может быть атакована.
Буду рад обсуждению и вопросам в комментариях.