При проведении внутреннего тестирования на проникновение в сетях Microsoft первостепенной целью атаки, разумеется, является Microsoft Active Directory, а одним из возможных и перспективных сценариев реализации успешной атаки на компьютеры в домене является NTLM-Relay. Суть атаки NTLM-Relay сводится к тому, чтобы вмешаться в процесс аутентификации по протоколу NTLM и получить доступ к стороннему ресурсу с привилегиями атакуемого пользователя. Атака может быть реализована в отношении любого протокола, поддерживающего NTLM-авторизацию (SMB, HTTP, LDAP и т.д.).
Если копнуть несколько глубже в практическую плоскость, тогда можно обнаружить следующие ограничения при проведении атаки NTLM-Relay:
- Невозможность провести атаку в отношении системы, с которой пришел запрос авторизации после установки обновления безопасности MS08-068 (для волосатых осей) или при использовании более поздних версий ОС Windows (ограничение не действует в случае объединения систем в кластер).
- "Ограничение на один хоп", т.е. после успешной атаки в отношении некоторого ресурса, невозможно дальнейшее использование привилегий атакованного пользователя с этого ресурса к смежным компонентам сети (общее ограничение NTLM). Можно провести повторную атаку NTLM-Relay к другому ресурсу, но нельзя использовать полученный токен доступа для развития атаки по сети.
- Рабочий сценарий проведения атаки NTLM-Relay предполагает, что атакуемый пользователь обладает правами администратора на ресурсе, в отношении которого производится атака [1,2]. В противном случае атакующий ограничен функционалом доступных наколенных и зачастую сырых решений, что очень сильно затрудняет его действия.
- NTLM-Relay относится к "шумным" сценариям проведения атаки, что может привлечь внимание соответствующих защитных систем.
Несмотря на перечисленные ограничения, как уже было сказано ранее, NTLM-Relay является весьма перспективным способом добраться до привилегий администратора домена. Повсеместное использование аутентификации по протоколу NTLMv1 подталкивает исследователей к развитию атаки NTLM-Relay. В подтверждении этому стоит вспомнить инструмент ZackAttack, который выводит проведение атаки NTLM-Relay на качественно новый уровень и позволяет выжать из него максимум. Однако и при использовании ZackAttack атакующий сталкивается со множеством проблем. Так может существует альтернатива NTLM-Relay, лишенная перечисленных недостатков выше?
Все новое – хорошо забытое старое [ЗАРАЗА, 2004 г.]
В конце прошлого месяца мое внимание привлекла публикация Марка Гамачи (Mark Gamache) с громким названием "Взлом протокола NTLM" (ссылка на оригинал). Автор публикации, ссылаясь на наработки Moxie Marlinspike, посвященные взлому MS-CHAPv2, обратил внимание на то, что в NTLMv1 и MS-CHAPv2 используются единые алгоритмы. А это в свою очередь означает, что доступный за денюжку CloudCracker может использоваться для подбора NTLM-хеша пользователя, участвующего в процессе аутентификации по протоколу NTLMv1. Это возможно по причине использования уязвимого алгоритма шифрования, применяемого в обоих протоколах аутентификации.
Алгоритм генерации NTLM-Responce
То есть все три DES-блока вычисляются независимо. Ключ к третьему DES-блоку восстанавливается за доли секунды, а использование разных ключей шифрования над одним открытым текстом для оставшихся двух блоков позволяет сократить число DES-операций вдвое. Таким образом, обладая достаточными вычислительными ресурсами становится возможным восстановить NTLM-хеш за приемлемое время. Подобные вычислительные ресурсы общедоступны через CloudCracker.
Используем это
Итак, для того, чтобы восстановить NTLM-хеш, необходимо отловить в сетевом трафике процесс аутентификации пользователя по протоколу NTLMv1. При этом, могут использоваться любые пассивные варианты прослушивания трафика (например, tcpdump). Далее, кормим перехваченные данные балалайке, любезно собранной Mark Gamache и за тем, получившуюся строку в формате base64 отдаем на перебор сервису CloudCracker.
Ожидаем результата… (в моем случае результат был получен через 15 суток, вопреки заявленным 22-м часам) Бинго!
На последнем шаге достаточно прописать на контролируемую систему добытые креды (например, через WCE) и да здравствует прозрачная аутентификация к информационным ресурсам домена со всеми графическими приблудами :)
Резюме
Если атакующий располагает небольшим запасом времени, а у вас в сети до сих пор гуляет NTLM первой версии, то каким-бы сложным и стойким к перебору не был ваш пароль, атакующий "в тихом" режиме способен получить ваши привилегии не беспокоя при этом используемые вами системы обнаружения и предотвращения атак.
Так это... Если у нас есть возможность запустить на машине wce, то зачем вся эта движуха с перехватом? Почему просто не извлечь clear text пароля? Кажется, я чего-то важного не догнал :)
ОтветитьУдалитьВсе, дошло. WCE используем только для присвоения сессии на "клиенте" для дальнейшего использования.
ОтветитьУдалитьВсе равно, дропнуть агента легче, чем ждать/привлекать сессии аутентификации :D
Дропнуть агента? Вы о чем?
ОтветитьУдалитьДмитрий, подскажи, есть ли возможность использовать хеш для авторизации через IE в OWA, например? Беглый поиск в гугле результатов не принес.
ОтветитьУдалитьЕсли OWA использует аутентификацию NTLM, а не form-based (которая настроена по умолчанию), тогда да. Поднимаем креды на своем терминале через wce и прописываем в IE, что OWA является частью нашей интрасети -> profit
ОтветитьУдалить+ нужно понимать, что если основной интерфейс form-based, то это вовсе не значит, что рядом не используется ntlm-based аутентификация (например, можно попробовать тыкнутся сюда /owa/oma или в глобальную адресную книгу)
Спасибо, направление понял, будем смотреть)
ОтветитьУдалитьenglish version of this?
ОтветитьУдалитьsee http://markgamache.blogspot.ru/2013/01/ntlm-challenge-response-is-100-broken.html
ОтветитьУдалить