В данной статье рассмотрим уязвимости, которые легко проэксплуатировать в Active Directory — так называемые «низко висящие фрукты». Они часто встречаются и в результате дают возможность атакующему продвинуться вглубь инфраструктуры или получить дополнительную информацию.
Комбинация таких участков часто позволяет достичь полного контроля над средой Active Directory с правами администратора домена или расширить исходные привилегии.
Не углубляясь в технические дебри, я хочу показать, какие типовые проблемы существуют в домене Active Directory, что они из себя представляют и какие меры защиты стоит применить либо принять во внимание.
Широковещательные протоколы в сети: LLMNR, mDNS, NBT-NS и WPAD
Начнем с одного из типовых шагов для получения первоначальной учетной записи в корпоративной сети.
Протоколы LLMNR, mDNS и NBT-NS предназначены для поиска хостов по DNS-имени в широковещательном домене в случае, если основной DNS не смог дать ответ или вообще отсутствует в сети.
Это было полезно в те времена, когда обладание собственным DNS-сервером требовало больших вычислительных мощностей (очень давно). Однако с тех пор данные протоколы включены в конфигурации Windows по умолчанию.
Атакующий может поднять сервис, который будет отвечать на все подобные запросы в широковещательном сегменте, указывая адрес злоумышленника как искомый адрес. В результате хосты-жертвы, которые получили ответ, могут отправить запрос на хост злоумышленника.
После этого атакующий может потребовать аутентификацию для выполнения запроса, которую автоматически отправит хост жертвы (как правило, будет включать логин и хешированное значение пароля учетной записи, под которой работает пользователь на уязвимом хосте).
Альтернативным способом обработки полученного подключения от жертвы является реализация Relay-атаки (подробнее о ней — далее в статье). В рамках такой атаки злоумышленник выступает своего рода прокси-сервером между клиентом-жертвой и целевым сервером, выбранным хакером: перехватывает запрос на аутентификацию и перенаправляет его на другой хост от своего имени.
В результате это позволяет получить доступ к целевому хосту от имени жертвы (получить доступ к сетевым ресурсам, выполнить команды). Преимущество такой атаки для злоумышленника в том, что ему не нужно восстанавливать или знать пароль жертвы.
Вернемся к широковещательному трафику. На скриншотах ниже показан процесс атаки при помощи утилиты Responder (https://github.com/lgandx/Responder):
Атакующий отправил жертве по адресу 192.168.40.130 ответ на широковещательный запрос DNS-имени WINSHARE и WINSHARE.LOCAL.
Далее жертва выполнила попытку подключения к злоумышленнику с указанием используемых учетных данных (пользователь skvortsova).
В результате злоумышленник получил NetNTLM-хеш пароля пользователя, на основе которого может подобрать используемый пользователем пароль при помощи утилиты hashcat или подобных.
Отдельно стоит отметить протокол WPAD — это протокол автоматического получения конфигурации прокси-сервера в сети. Конфигурация хранится на WPAD-сервере в файле wpad.dat.
Для получения конфигурации рабочая станция осуществляет следующие этапы:
Местоположение WPAD-сервера может быть задано в конфигурации DHCP (опция 252 «auto-proxy-config»). В случае, если обнаружено, переходим к пункту 4.
Отправка запроса адреса WPAD к DNS-серверу. Например, если наш домен имеет имя domain.local, то будет выполнен запрос адреса wpad.domain.local. В случае, если обнаружено, переходим к пункту 4.
Поиск записи в широковещательном домене при помощи протоколов LLMNR и NBNS. В случае, если обнаружено, переходим к пункту 4.
Если сервер был обнаружен, то выполняется обращение к конфигурационному файлу по адресу http://wpad.domain.local/wpad.dat.
Атакующий может использовать широковещательный трафик в пункте 3 для отправки поддельного DNS-ответа о WPAD-сервере. В результате обращения жертвы по указанному злоумышленником адресу будет предоставлена конфигурация прокси-сервера, после чего злоумышленник может перехватывать трафик жертвы и аутентификационные данные (простейший пример — в качестве конфигурации установить, что прокси-сервер требует аутентификации).
Как защититься?
Необходимо отключить широковещательные протоколы (mDNS, LLMNR, NBT-NS) на всех узлах в сети.
Отключить протокол WPAD. Если в сети используется прокси-сервер, то необходимо установить его вручную, например, через групповые политики.
Что можно почитать:
Описание атаки на ресурсе MITRE с рекомендациями по защите и описанием инструментов для эксплуатации: https://attack.mitre.org/techniques/T1557/001/
Статья об отключении LLMNR с использованием доменных политик: https://www.blackhillsinfosec.com/how-to-disable-llmnr-why-you-want-to/
Статья о способах защиты от рассмотренных атак: https://cccsecuritycenter.org/remediation/llmnr-nbt-ns
IPv6
IPv6 включен на устройствах Windows по умолчанию, но редко используется в корпоративной сети.
Злоумышленник может разместить собственный DHCPv6-сервер и назначать произвольную сетевую конфигурацию жертвам, у которых включена поддержка IPv6. Поскольку сетевая конфигурация IPv6 имеет приоритет над IPv4, то это позволяет реализовывать атаки типа «человек посередине» (Man-in-the-Middle, MitM), в том числе перенаправлять весь трафик или его часть на произвольный хост в сети.
Как правило, вредоносный IPv6 DHCP-сервер (DHCPv6) используется для получения первоначального доступа к корпоративной инфраструктуре. Атакующий в сетевой конфигурации указывает свой DNS-сервер, который любые DNS-запросы определяет в IP-адрес хоста, подконтрольного злоумышленнику.
В результате все обращения клиентов перенаправляются на подконтрольный атакующему хост, что приводит к утечке конфиденциальных данных, например, учетных данных в хешированном виде (но бывают случаи, что и в открытом).
Как обнаружить и отключить?
Обнаружить IPv6 в сети можно при помощи DHCPv6 Solicit пакетов. Хосты с включенным IPv6 рассылают эти пакеты для поиска DHCPv6-сервера:
Если же есть доступ к рабочим станциям, то выяснить, отключен ли IPv6, можно следующим запросом в реестр (в результате его выполнения должно вернуться значение 0xff, если IPv6 отключен):
reg query
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v
DisabledComponentsВ случае, если вернулось пустое значение, то это означает, что меры против IPv6 не реализованы.
Согласно Microsoft, отключить IPv6 не рекомендуется, вместо него необходимо использовать приоритизацию конфигурации IPv4 над IPv6.
Это можно сделать при помощи следующей команды:
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v
DisabledComponents /t REG_DWORD /d 0x20 /f Отключить IPv6 можно следующей командой:
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v
DisabledComponents /t REG_DWORD /d 0xff /fАльтернативный способ отключения IPv6 через групповые политики описан по ссылкам ниже:
Relay-атаки
Как упоминалась ранее, в случае, когда злоумышленник получил запрос от жертвы, он может перенаправить его на другой хост в сети.
Для понимания сути атаки нам необходимо копнуть чуть глубже и понять, как реализована аутентификация в рамках NTLM-протокола.
NTLM — это протокол в формате challenge/response, он используется другими протоколами, в которых необходима аутентификация пользователя (таких как SMB, HTTP, SMTP).
Протокол состоит из трех этапов:
На первом этапе пользователь, который хочет выполнить аутентификацию на сервере, отправляет запрос NEGOTIATE_MESSAGE, в котором указывает свои параметры.
Далее сервер отправляет в ответ CHALLENGE_MESSAGE с целью установить подлинность клиента, а именно — отправляет ему случайное число (challenge), которое должно быть зашифровано при помощи хешированного значения пароля пользователя, который хочет аутентифицироваться.
В последнем сообщении, AUTHENTICATE_MESSAGE, клиент отправляет зашифрованное значение challenge, имя пользователя, имя хоста и имя домена (если есть). Сервер проверяет корректность зашифрованного сообщения, и, если оно корректно, аутентификация считается пройденной.
При реализации Relay-атаки злоумышленник выступает прокси-сервером для клиента, который к нему обратился, и передает запросы от жертвы к целевому серверу, к которому хочет получить доступ, и обратно. Таким образом, хост атакующего для жертвы — это сервер, с помощью которого выполняется аутентификация; для целевого сервера — это клиент, который выполняет аутентификацию.
Задача атакующего сводится к тому, чтобы прозрачно передать все этапы аутентификации от жертвы к серверу и обратно. Ключевым этапом является передача CHALLENGE_MESSAGE от целевого сервера к жертве, чтобы она его зашифровала, а затем злоумышленник передает AUTHENTICATE_MESSAGE от жертвы серверу, чтобы подтвердить подлинность.
В результате целевой сервер устанавливает сессию с атакующим, поскольку считает, что атакующий — это пользователь, который только что прошел аутентификацию.
Стоит отметить, что используемые протоколы аутентификации (LM и NTLM) протоколонезависимые, что позволяет иногда использовать запрос, полученный по одному протоколу, для аутентификации на другом сервисе.
Углубляться не буду, приведу лишь таблицу протоколов и как их можно перенаправить. Красным выделено отсутствие поддержки, зеленым — наличие поддержки.
Способы защиты:
Использование принудительной подписи SMB на всех хостах в сети: на серверах и рабочих станциях, и подписи LDAP на серверах.
Принцип наименьших привилегий — чем меньше прав у типового пользователя для входа на машины, тем меньше последствия успешной эксплуатации атаки.
Что можно почитать:
Статья, в которой детально описаны Relay-атаки https://beta.hackndo.com/ntlm-relay/
Отличная статья об актуальных способах Relay-атаки в 2022 году https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/
Статья с описанием способов проведения Relay-атаки (от авторов инструмента Impacket) https://www.secureauth.com/blog/we-love-relaying-credentials-a-technicalguide-to-relaying-credentials-everywhere/
Если вам интересна эта тема и у вас появились вопросы, приглашаю послушать мое выступление на онлайн-событии CyberCamp 22 (мой доклад — первый, 14 сентября в 10:30). Подключайтесь — обсудим онлайн.
Источники изображений в этом посте: «Инфосистемы Джет»
Владимир Ротанов
руководитель группы практического анализа защищенности «Инфосистемы Джет»