LDAP Relay Scan

Инструмент для проверки контроллеров домена на наличие серверных защит LDAP, связанных с ретрансляцией NTLM-аутентификации. Если вас интересуют подробности перечисления на основе ошибок, см. ниже. Подробнее о том, что можно сделать при обнаружении отсутствия защит LDAP, см. в разделе «Ссылки».

Краткое описание

Существует несколько серверных защит, которые действуют при попытке ретрансляции NTLM-аутентификации в LDAP на контроллерах домена. Защиты LDAP, которые пытается перечислить этот инструмент, включают:

• LDAPS - привязка канала
• LDAP - требования к подписи сервера

Применение привязки канала для LDAP по SSL/TLS можно определить с неаутентифицированной точки зрения. Это связано с тем, что ошибка, связанная с невозможностью клиента LDAP правильно выполнить привязку канала, возникает до проверки учетных данных в процессе bind LDAP.

Однако, чтобы определить, применяется ли серверная защита стандартного LDAP (требования целостности подписи сервера), сначала необходимо проверить учетные данные клиента во время bind LDAP. Потенциальная ошибка, указывающая на применение этой защиты, обнаруживается с аутентифицированной точки зрения.

TL;DR - LDAPS можно проверить без аутентификации, но проверка LDAP требует аутентификации.

Установка

Рекомендуется использовать Docker или виртуальное окружение Python при запуске этого проекта.

Docker

1. Убедитесь, что на вашей машине установлен docker
2. Клонируйте репозиторий и перейдите в каталог
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Соберите Docker-контейнер
   • docker build -f docker/Dockerfile -t ldaprelayscan .
4. [необязательно] Убедитесь, что скрипт работает правильно
   • docker run ldaprelayscan -h

Виртуальное окружение Python

1. Убедитесь, что на вашей машине установлен python virtualenv
2. Клонируйте репозиторий и перейдите в каталог
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Создайте виртуальное окружение Python для проекта
   • virtualenv env
4. Активируйте виртуальное окружение Python
   • source venv/bin/activate
5. Установите зависимости точных версий из requirements
   • python3 -m pip install -r requirements_exact.txt
6. [необязательно] Убедитесь, что скрипт работает правильно
   • python3 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

Примеры использования Docker

ПРИМЕЧАНИЕ: Возможность использования 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

Особенности перечисления на основе ошибок

[LDAPS] Требования к токену привязки канала

На контроллере домена, получившем обновления после 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]

«Never» против «When supported» против «Always»

Эта конкретная ошибка позволяет легко учесть случай, когда политика Domain Controller: LDAP server channel binding token requirements установлена в Always. Достаточно выполнить NTLM-based bind LDAPS с использованием клиента, не поддерживающего привязку канала, и поискать data 80090346 в ответной ошибке. Но что если политика установлена не в Always, а, скажем, в When supported? Ответ: выполните bind к LDAPS с NTLM-аутентификацией и намеренно неверно вычислите информацию привязки канала.