Что такое LDAP Simple Bind и почему это плохо

Даже считая себя опытным специалистом в какой-то сфере нужно периодически вспоминать о базовых вещах.

К такому выводу я пришел просмотрев видеов духе «20 секретов Excel для начинающих» :)

Ну а раз так, то вполне себе можно перенести эту идею на безопасность инфраструктуры и поговорить о LDAP Simple Bind :)

С одной стороны — то, что Simple Bind используется в инфраструктуре — это плохо. С другой — из личного опыта — в 90% компаний, с которыми мне пришлось работать, я лично видел пролетающие по сети пароли в открытом виде.

Итак, подтвердим в тестовой среде, что LDAP Simple Bind это действительно небезопасно.

Для этого используем контроллер домена (Windows 2016), клиента, который будет подключаться к контроллеру по LDAP (Windows 10, IP: 10.0.0.200, ПК в домене, на этот ПК установлены инструменты RSAT) и ПК потенциального злоумышленника (Windows 10 с установленным Wireshark)

Запускаем LDP клиент -

 simple_bind1

На ПК злоумышленника не забываем запустить Wireshark -

simple_bind1_1

Подключаемся с доменного ПК к контроллеру -

simple_bind2

simple_bind3

simple_bind4

И выполняем bind, используя тип simple bind -

simple_bind5

 

simple_bind6

Проверяем, что все в порядке -

 simple_bind7

Переходим на ПК «злоумышленника». Т.к. нас интересует протокол LDAP — установим соответствующий фильтр  -

 simple_bind8

Ищем bind request, так как именно в нем живет все самое интересное :) -

 simple_bind9

Если «злоумышленник» терпелив и в вашей инфраструктуре находится длительное время — крайне велика вероятность, что рано или поздно он соберет большинство логинов\паролей из вашего активного каталога.

Перейдем ко второй части упражнения. Ответим на вопрос «А насколько все плохо?». Ничего новго изобретать не будем, а использум статью, которая уже упоминалась в блоге.

На контроллере домена фильтруем журнал событий  Directory Service нас интерсуют 2 типа событий 2886 и 2887 -

 simple_bind10

Эти события помогут нам оценить масштабы бедствия. Но для того чтобы ответить на вопрос «Кто виноват» необходимо пойти дальше.

simple_bind11

Microsoft идет нам в этом на встречу и позволяет включить расширенное протоколирование событий LDAP Interface Events.

Для включения логирования нужно в ветке реестра HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics изменить значение параметра «16 LDAP Interface Events» с 0 на 2. (Очевидно, для отключения нужно поменять 2 на 0) -

 simple_bind12

simple_bind13

Проверим результат -

 simple_bind14

Теперь мы имеем полное представление какая учетная запись потенциально скомпроментирована и какой хост в этом виноват.

Выводы?

Нужно проанализировать конфигурацию «инициатора» небезопасных подключений и сделать так, чтобы критическая информация не путешествовала по сети в открытом виде :)