zyn3rgy/ldaprelayscanПроверка защиты LDAP в отношении ретрансляции NTLM-аутентификации
Инструмент для проверки контроллеров домена на наличие серверных защит LDAP, связанных с ретрансляцией NTLM-аутентификации. Если вас интересуют подробности перечисления на основе ошибок, см. ниже. Подробнее о том, что можно сделать при обнаружении отсутствия защит LDAP, см. в разделе «Ссылки».
Существует несколько серверных защит, которые действуют при попытке ретрансляции NTLM-аутентификации в LDAP на контроллерах домена. Защиты LDAP, которые пытается перечислить этот инструмент, включают:
Применение привязки канала для LDAP по SSL/TLS можно определить с неаутентифицированной точки зрения. Это связано с тем, что ошибка, связанная с невозможностью клиента LDAP правильно выполнить привязку канала, возникает до проверки учетных данных в процессе bind LDAP.
Однако, чтобы определить, применяется ли серверная защита стандартного LDAP (требования целостности подписи сервера), сначала необходимо проверить учетные данные клиента во время bind LDAP. Потенциальная ошибка, указывающая на применение этой защиты, обнаруживается с аутентифицированной точки зрения.
Рекомендуется использовать Docker или виртуальное окружение Python при запуске этого проекта.
git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScandocker build -f docker/Dockerfile -t ldaprelayscan .docker run ldaprelayscan -hgit clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScanvirtualenv envsource venv/bin/activatepython3 -m pip install -r requirements_exact.txtpython3 LdapRelayScan.py -hПРИМЕЧАНИЕ: DNS должен правильно разрешаться. Если вы используете SOCKS или работаете на хосте, не входящем в домен, убедитесь, что это работает.
Инструмент имеет два метода: LDAPS (по умолчанию) и BOTH. Для LDAPS требуется только IP-адрес контроллера домена, поскольку эту проверку можно выполнить без аутентификации. Метод BOTH требует имя пользователя и пароль или NT-хэш. Домен Active Directory не требуется — он будет определен через анонимный bind LDAP.
arguments:
-h, --help show this help message and exit
-method method LDAPS or BOTH - LDAPS checks for channel binding, BOTH checks for LDAP signing and LDAP channel binding [authentication required]
-dc-ip DC_IP DNS Nameserver on network. Any DC's IPv4 address should work.
-u username Domain username value.
-timeout timeout The timeout for MSLDAP client connection.
-p password Domain username value.
-nthash nthash NT hash of password
python3 LdapRelayScan.py -method LDAPS -dc-ip 10.0.0.20
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -p badpassword2
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -nthash e6ee750a1feb2c7ee50d46819a6e4d25
ПРИМЕЧАНИЕ: Возможность использования SOCKS передается через переменную окружения
PROXY_CONFIG. Если требуется SOCKS, также необходимо использовать флаг--network=host, чтобы правильно маршрутизировать трафик. См. примеры ниже.
docker run ldaprelayscan -h
docker run ldaprelayscan -dc-ip 10.0.0.20
docker run ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass
docker run -e PROXY_CONFIG='socks5 127.0.0.1 9050' --network=host ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass
На контроллере домена, получившем обновления после CVE-2017-8563, появилась возможность принудительного применения привязки канала для LDAPS. Соответствующая политика называется Domain Controller: LDAP server channel binding token requirements и может иметь значения Never, When supported или Always. По умолчанию она не требуется (на момент написания этого текста).
Расшифровка и мониторинг трафика LDAP по SSL/TLS на контроллере домена позволили выявить различие в ошибках при попытках bind в зависимости от того, применяется ли привязка канала. При попытке bind к LDAP по SSL/TLS с неверными учетными данными вы получите ожидаемый resultCode 49, а в тексте сообщения об ошибке будет data 52e. Однако если привязка канала включена, а клиент LDAP не вычисляет и не включает токен привязки канала (CBT), resultCode останется 49, но сообщение об ошибке будет содержать data 80090346, что означает SEC_E_BAD_BINDINGS или что привязки канала SSPI, предоставленные клиентом, неверны.
ПРИМЕЧАНИЕ: Упоминания ошибки
data 8009034при bind LDAP по SSL/TLS [1] [2] [3] [4] [5]
Эта конкретная ошибка позволяет легко учесть случай, когда политика Domain Controller: LDAP server channel binding token requirements установлена в Always. Достаточно выполнить NTLM-based bind LDAPS с использованием клиента, не поддерживающего привязку канала, и поискать data 80090346 в ответной ошибке. Но что если политика установлена не в Always, а, скажем, в When supported? Ответ: выполните bind к LDAPS с NTLM-аутентификацией и намеренно неверно вычислите информацию привязки канала.
Сначала нам нужен LDAP-клиент, поддерживающий привязку канала. Для реализации PoC будет использоваться реализация SkelSec в msldap. Привязка канала появляется как значение AV_PAIR во время процесса NTLM challenge/response, а именно в Type 3 или AUTHENTICATE_MESSAGE. Вот еще один взгляд на расшифрованный трафик LDAPS на контроллере домена, показывающий, как выглядит попытка bind от клиента с поддержкой привязки канала:
Намеренный неверный расчет этого значения, когда рассматриваемая политика установлена в When supported, приведет к той же ошибке data 80090346. Это дает нам возможность различать все возможные значения этой политики в ее текущем виде без аутентификации. То, как это значение намеренно искажается, важно, поскольку простая ручная замена значения во время challenge/response аннулирует MIC.
На контроллере домена политика Domain Controller: LDAP server signing requirements может быть установлена в None, Require signing или быть неопределенной. Если политика не определена, по умолчанию подпись не требуется (на момент написания). Ошибка, указывающая на обязательность этой защиты, возникает, когда sicily NTLM или simple bind-запрос отвечает resultCode 8, означающим strongerAuthRequired. Это происходит только в том случае, если учетные данные при bind LDAP были проверены.
Несколько бесценных ресурсов для контекстуализации этого материала и понимания того, как он вписывается в типовые сценарии атак.