Взлом протокола NTLM

Автор: Марк Гамачи (Mark Gamache)

Обновлено: кажется, многие ребята не умеют читать. Интерес этого метода заключается в том, что получен хэш БЕЗ физического или административного доступа к системе. Да, я знаком с множеством утилит, которые «уже делают это» с использованием локальных прав администратора.

Во-первых, не могу сказать, что я взломал протокол «рукопожатия» NTLM (NTLM handshake); многие сделали это; видимо, я единственный, кто собрал все воедино.

Существует множество статей, выступлений на хакерских конференциях и постов в блогах, посвященных слабым местам аутентификации NTLM (и LM). Хотя, слабости, описанные в предыдущих работах, носили в основном теоретический характер или при их использовании требовались права администратора. Однако это означает, компьютер жертвы уже скомпрометирован, что делает все подобные эксплоиты скучными и неоригинальными. В связи с тем, что протокол NTLM работает по принципу вопрос-ответ, нельзя просто взять и перехватить хэш. В лучшем случае получить его вне хоста можно лишь в том случае, если провести атаку вида «человек посередине» с подменой выбранного запроса. Это сработает в том случае, если жертва возжелает соединиться посредством протокола NTLM без установленного флага Session Security Flag. После того как хэш перехвачен, злоумышленник при помощи радужных таблиц (rainbow tables) хэшей предопределенных паролей пытается подобрать пароль жертвы. Такой сценарий весьма труден для реализации.

Протокол NTLM содержит в себе четыре вида механизмов «рукопожатий», которые идут в порядке возрастания уровня безопасности и сложности: LM, NTLM, NTLM session security и NTLMv2. В настоящее время только NTLMv2 считается безопасным. В случае использования первых трех механизмов не существует никакого другого способа защиты, кроме шифрования передаваемых данных при помощи, например, IPSec. Однако хорошая новость в том, что в данный момент во всех операционных система Microsoft присутствует ключ в реестре, который может управлять настройками «рукопожатий». MS выпустила KB и обновленные советы по безопасности, информацию можно найти ниже.

Спасибо Мокси Марлинспайк (Moxie Marlinspike), создателю сервиса Cloudcracker. Атакующий может пропустить выбранный запрос, а затем на основе запроса и ответа подобрать NTLM-хэш. Если жертва работает под ОС Windows XP ситуация еще хуже, Cloudcracker возвратит хэш, который может быть расшифрован за одну ночь.

Почему это важно сейчас?

Прежде чем я расскажу о деталях эксплоита, позвольте мне прояснить, как эти технологии связаны с сегодняшними реалиями. Вы можете подумать, что сейчас никто не использует NTLM или, боже упаси, LM. Уже довольно долгое время по планете гуляет NTLMv2. Разумеется, все его используют. Верно?

Ответ: неверно!

Согласно последним данным с сайта W3 Schools, на 21% компьютеров установлена ОС Windows XP, в то время как NetMarketShare заявляет о 39%. За исключением случаев, когда эти системы настроены должным образом (установка патчей здесь не при чем), многие компьютеры продолжают обмениваться LM и NTLM-запросами! В этот список не включены серверные операционные системы, например, Windows 2003 все еще использует NTLM-запросы по умолчанию. Да, каждая ОС компании Microsoft, начиная с NT 4.0 SP4, поддерживает NTLMv2, но NTLM и LM используются по умолчанию во всех ОС вплоть до Висты.

Но и это еще не все! В компаниях с разнородными средами используется Active Directory Group Policy (что ослабляет безопасность) из-за страха потери соединений с Samba. Само собой, Samba уже давно поддерживает NTLMv2, но большинство IT-специалистов размышляют примерно так: «Зачем укреплять безопасность, если можно что-нибудь нарушить? Никто не заявляет о взломе NTLM».

Ну, вот, теперь кое-кто заявляет: «Я взломал NTLM».

«Молодец, теперь расскажи, как защититься».

Про защиту чуть позже. (Я не могу поставить себе в заслугу взлом NTLM. Я не математик. Моя специализация - прикладная криптография, я просто заглянул в нужное место в нужное время).

Механизм атаки

Когда я прочитал обзор Мокси Марлинспайка про взлом MS-CHAPv2, мне стало ясно, что дело не в наличии какой-то серьезно уязвимости. Фишка была в системе, которая подбирала DES-ключи, являющиеся сердцем механизма «вопрос-ответ». Менее чем за 24 часа, при наличии известного 64-битного обычного текста-запроса (challenge) и зашифрованного текста-ответа (response), Cloudcracker возвращает DES-ключ.

Тут я подумал, куда бы еще можно применить эту чудо-систему, которая с такой легкостью получает DES-ключи.

В то время я не сильно углублялся в механизмы атаки, поскольку изучал протокол NTLM и написал пост об атаках типа «Pass the Hash». Понимаю, об этом уже много сказано, но я не нашел ни одной статьи, которая отвечала бы на все мои вопросы, и решил написать ее сам. Во время исследований я в основном изучал детали протокола. Исчерпывающую информацию о NTLM вы можете найти на странице Эрика Гласса (Eric Glass).

Изучая работу Эрика, я обратил особое внимание на следующие строки (выделено жирным шрифтом).

Формирование NTLM-ответа происходит следующим образом:

Алгоритм MD4 message-digest (описанный в RFC 1320) шифрует Unicode-пароль чувствительный к регистру. В результате получаем NTLM-хэш размером в 16 байт.

К 16-байтному NTLM-хэшу добавляются нули (до 21 байта).

Происходит разбивка на три блока (по 7 байт).

Создается три DES-ключа (из каждого 7-ми байтного блока).

Каждый из ключей используется для шифрования текста запроса (получаются три 8-ми байтных шифра, которые входят в Type 2 message).

Все три зашифрованных куска соединяются вместе, и получается 24-байтный NTLM-ответ.

Заметьте, отличие схемы NTLM-ответа состоит лишь в вычисление хэша; сам ответ формируется схожим образом (как и LM-схеме).

Для того чтобы исследовать запрос/ответ, мне необходимо подобрать две итерации DES, которые содержат 56-битные ключи, и еще одну, содержащую 2-битный кусок от 56-битного ключа. Наглядную схему смотрите на рисунке ниже.

Тут же я стал изучать информацию, чтобы выяснить, как Cloudcracker может помочь мне в подборе ключей. После некоторых исследований я обнаружил, что в MS-CHAPv2 используются те же самые математические выражения, что и в механизмах LM/NTLM. Мокси показал мне строчку кода, при помощи которой можно передать запрос и ответ, а на выходе получить NTLM (или LM) хэш.

print "CloudCracker Submission = $99$%s" % base64.b64encode("%s%s%s%s" % (plaintext, c1, c2, k3[0:2]))

Просто соедините запрос, первые два блока ответа и k3 в кодировке base64 и дело в шляпе. Единственное чего я не понимал, почему k3 состоит только из двух байтов. Полагаю, чтобы сэкономить вычислительные мощности, нужно подобрать последний ключ перед тем, как отправлять запрос в Cloudcraker. Механизм подбора просто соединит его с двумя первыми ключами и отправит итоговый результат. Поскольку последний ключ единственный, у которого первый 5 байт нулевые, это просто.

Используя пример со страницы Эрика Гласса, я отправил строку $99$ASNFZ4mrze8lqYwcMegYR0ZrKbLfRoDz2Ag= в Cloudcracker. Строка состоит из следующих частей: запрос - 0123456789ABCDEF, первая часть ответа - 25A98C1C31E81847, вторая часть ответа - 466B29B2DF4680F3, и D808 первые два байта из третьей части – это хэш, который я подобрал на своей машине. Если вы решите последовать моим путем, обязательно обратите внимание на корректировку четности ключей (на странице Гласса). На самом деле размер DES-ключей 64-бита, а не 56, но самый младший бит каждого байта – бит четности. Эти биты не учитываются при шифровании. Для корректировки четности вы также можете использовать Java-код.

Через некоторое время я получил сообщение по электронной почте от сервиса CloudCracker:

CloudCracker успешно провел атаку для «рукопожатия» CHAPv2. Полученный NT-хэш приведен ниже. Далее, используя утилиту «chapcrack», вы можете расшифровать пакеты или произвести аутентификацию на сервере:

cd06ca7c7e10c99b1d33b7485a2ed808

Операция получения хэша заняла 68799 секунд. Работа завершена, спасибо за использование сервиса cloudcracker.com.

Еще раз повторю тем, кто пропустил нить рассуждения. Я только что получил NT-хэш, который используется в протоколе запрос/ответ. Все мои манипуляции были выполнены без взлома клиента и сервера. Для атаки мне достаточно, например, отправить письма такого содержания:

Кому: Всем сотрудникам

От кого: Отдел кадров

Тема письма: Обновление памятки для сотрудников

Сообщение: Отдел кадров внес значительные изменения в памятку для сотрудников. Хотя многие из них незначительны, с ними полезно ознакомиться всем сотрудникам компании. Служащие с престарелыми родителями будут рады увеличению оплачиваемого отпуска по уходу за престарелыми иждивенцами. Также обновлено руководство по проведению корпоративных мероприятий с алкогольными напитками.

Наконец, с введением Washington Initiative 502, мы опубликовали новые правила по применению марихуаны на рабочем месте.

Памятку находится здесь:

\\hrFiles.ru\HRFiles\EmployeeManualv3.docx

С наилучшими пожеланиями,

Отдел кадров

Я назвал эту атаку «Запрос хэша». Извините за каламбур, но мне кажется после прочтения письма, сразу же возникает желание скачать и прочитать новые правила компании.

Хорошие новости

Прежде всего, я выражаю благодарность компании Microsoft, которая сделала по умолчанию использование NLTMv2 (как в Висте) и оставила возможность, для тех, кому это важно, использования LM и NTLM «рукопожатий». Однако я думаю, MS следует добавить настройку на уровень локальной политики безопасности, чтобы администраторы доменов могли использовать ее по мере необходимости.

При внедрении изменений в политику безопасности на предприятиях могут возникнуть проблемы несовместимости, однако хорошая новость в том, что механизмы LM, NTLM и NTLMv2 используются довольно продолжительное время. Ключ реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel позволяет выбрать, какие типы «рукопожатий» разрешены в системе. Для рабочих станций предпочтительнее установить значение 3 или выше. Хотя ситуация может быть не так однозначна, поскольку многие системы под управлением ОС Windows могут быть как рабочими станциями, так и серверами (предоставляя ресурсы $admin, c$ и т. п.). Одни те же настройки могут отличаться по смыслу на разных версиях систем. В отличной статье, написанной Джеспером Йоханссоном, рассказывается про клиентские и серверные системы. Лично я на всех своих системах установил значение 5. Если вы установите значение меньше 5, то, значит, в вашей сети допускается использование NTLM или LM «рукопожатий».

Уровень	Наименование групповой политики	Допустимые форматы запросов	Разрешено принимать	Запрещенные форматы запросов
0	Отправлять только LM и NTLM-ответы	LM, NTLM, NTLMv2 Session Security если необходимо	LM, NTLM, NTLMv2	NTLMv2 Session Security (в системах Windows 2000 ниже SRP1, Windows NT 4.0, и Windows 9x)
1	Отправлять LM and NTLM—использование NTLMv2 session security если необходимо	LM, NTLM NTLMv2 Session Security если необходимо	LM, NTLM, NTLMv2	NTLMv2
2	Отправлять только NTLM-ответы	NTLM, NTLMv2 Session Security если необходимо	LM, NTLM, NTLMv2	LM и NTLMv2
3	Отправлять только NTLMv2-ответы	Только NTLMv2 Session Security	LM, NTLM, NTLMv2	LM и NTLM
4	Отправлять только NTLMv2-ответы/запрещать аутентификацию LM	NTLMv2 Session Security	NTLM, NTLMv2	LM
5	Отправлять только NTLMv2-ответы/запрещать аутентификацию LM и NTLM	NTLMv2, Session Security	NTLMv2	LM и NTLM

Вы можете спросить: «Какая разница, если мой сервер разрешает LM или NTLM-аутентификацию?» Если не все клиентские машины под контролем, то сервер может быть использован для получения учетной записи клиента с небезопасными настройками.

Я установил свежий дистрибутив Ubuntu, SMB/CIFS-клиент посылает только NTLMv2-ответ, даже при попытке даунгрейда с использованием Cain. Но у меня пока не было возможности протестировать браузеры, которые поддерживают NTLM-аутентификацию через SPNEGO. Большинство браузеров поддерживают NTLM-аутентификацию через HTTP-протокол, в случае если достоверный сайт требует этого.

Напоминание о последствиях «ничегонеделания»

В то время как браузеры выполняют NTLM-аутентификацию лишь в случае достоверных сайтов (по умолчанию), кажется, системы под управлением ОС Window не различают достоверные и недостоверные зоны при использовании, например, протоколов CIFS/SMB, SQL/TDS или RPC. Это предоставляет широкие возможности для фишинговых атак (когда отправляется ссылка вида file://server//share). Суть в том, что при клике пользователем на ссылку операционная система попытается залогиниться, через протокол SSPI, используя закешированные учетные данные жертвы. В итоге злоумышленнику вовсе не обязательна ваша успешная авторизация, поскольку и так понятно, что передаваемые учетные данные верны. Возможно вы, прочитав статью об атаках типа «Pass the Hash», последовали моему совету и блокировали использование NTLM-протокола в сети. Однако это не остановит одного из ваших клиентов, который, скажем, работает у себя дома и также может использовать NTLM-рукопожатие. Как видите, существует вариантов проникновения в вашу систему при использовании LM или NTLM соединений. Ок, злоумышленник получил хэш, но находится вне вашей сети. Находитесь ли вы в безопасности? Нет! В данный момент у атакующего есть корректный хэш, и он вполне может использовать учетную запись для кражи ваших данных. Для этого есть два пути:

· Если в системе используется LM-ответы, получить пароль проще некуда. В случае с NTLM-хэшем ситуация чуть сложнее. В сервисе Cloudcracker много радужных таблиц. За 20$ я могу получить пароль «усредненного» пользователя (тот, который не слишком сложен). Само собой, есть много способов, как использовать полученные учетные записи внутри защищенной сети. Мокси, если ты читаешь эти строки, как насчет того, чтобы после получения хэша сразу проверить его по радужным таблицам?

· Но подождите! Злоумышленнику не нужен пароль. Полученный хэш, по сути, является паролем! Первый шаг NTLM и NTLMv2-авторизации – преобразование пароля к NT-хэшу, и это облегчает работу злоумышленника. После того как хэш украден, единственные два пути сделать его бесполезным - поменять пароли или удалить все каналы, по которым он может быть передан (последний вариант кажется фантастическим).

Как защитить себя и свою компанию

Если вы простой пользователь, на всех компьютерах установите значение у параметра LmCompatibilityLevel=3 или выше посредством локальной политики безопасности, групповой политики или в реестре.

В случае с компанией обязательно пропишите в групповой политике принудительную установку параметра LmCompatibilityLevel значения 3 или выше. Как вы могли заметить, уровни 4 и 5 запрещают контроллеру домена принимать некоторые виды авторизаций. Однако это также не спасает от взлома, поскольку хэш в этом случае все равно передается и, следовательно, может попасть в руки злоумышленника. Конечно, если злоумышленник видит успешную авторизацию, то понимает, что тут есть чем поживиться. Однако даже в случае нескольких неудачных попыток входа на сервер говорит о наличии закешированных учетных записей на машине клиента и хэш, скорее всего, также рабочий и может подойти как минимум к клиентской машине, а как максимум к контроллеру домена. Если вы используете Samba-клиент, в файле конфигурации введите такую строку «client ntlmv2 auth».

Заключительная параноидальная мысль

После установки безопасных настроек ПОМЕНЯЙТЕ ВСЕ ПАРОЛИ!

Я сделал этот открытие после того, как понял, что подобрать DES-ключ можно за копейки. После этого я начал обдумывать список механизмов, которые уязвимы наряду с DES. И я уверен, что тот же самый список начали составлять все разведслужбы, когда получили достаточные компьютерные мощности для подбора DES-ключей. Полагаю, что у них были такие возможности на протяжении последних 5-10 лет.

Приношу извинения перед шпионами, если перед ними захлопнулась дверь. Я прочитал в одной книге: «Закрывается одна дверь, открывается другая» ;-).

Приложение А: Концептуальный код

Для обоснования своих концепций я запрограммировал простую утилиту и создал CloudCracker-токен. Во-первых, хотел бы заметить, что я не профессиональный программист, поэтому не сильно не смейтесь, когда будете изучать мой код. Во-вторых, код Эрика Гласса сильно помог мне. Его алгоритм реализован на Java, в то время как мой – на C#. И, наконец, я использовал крипто библиотеки Bouncy Castle для C# по двум причинам. В .NET библиотеки не поддерживают хэширование MD4, поскольку этот алгоритм очень слабый, а также в них происходит блокировка слабых DES-ключей. Механизм NTLM не учитывает использование слабых ключей.

Мой код слегка не оптимален, поскольку каждый проверка в CloudCracker стоит 20$, и мне не хотелось отправлять ошибочные варианты в процессе отладки программы.

Код можно скачать здесь.

Запрос и ответ должны быть шестнадцатеричном формате, а пароль – простой текст.