Защита привилегированных аккаунтов домена: LM-хэши – Хорошие, Плохие, Ужасные

Остальные статьи цикла:

Защита привилегированных аккаунтов домена: безопасность парольных хэшей

Я осознаю, что LM-хэши (LanMan) для многих являются прошлым веком, однако недавно я обнаружил, что LM-хэш даже более опасен, чем мне раньше казалось. Причинами тому являются как простота взлома LM-хэшей на современном оборудовании, так и неявный факт того, что Microsoft не дает возможности удалять эти хэши из памяти. Поэтому, даже если вы считаете, что уже слышали о LM-хэшах все что можно, я рекомендую вам дочитать эту статью, дабы убедиться, что вы осведомлены о LM-хэшах, таящихся в памяти.

Плохие

Хотя проблемы LM-хэшей хорошо задокументированы, позвольте мне кратко описать, как создаются LM-хэши. После этого вы сразу увидите несколько значительных проблем данного алгоритма. Эти проблемы позволяют выявить причины, по которым нам необходимо избавиться от LM-хэшей. Вот как работает алгоритм LM-хэширования (материал с Википедии):

• Пароль пользователя, состоящий из ASCII-символов, приводится к верхнему регистру
• Результат дополняется нулями до длины 14 байт
• Полученные 14 байт делятся пополам
• Каждая из половин используется в функции шифрования DES для создания двух 8-байтовых шифртекстов
• Два полученных шифртекста конкатенируются в 16-байтовое значение, которое и является значением LM-хэша
• В создании хэша соль не используется

В дизайне алгоритма есть множество изъянов. Позвольте мне кратко описать некоторые из них:

• Факт того, что каждый символ пароля является ASCII-символом (одним из 95 печатных символов), означает, что есть только 95 вариантов для каждого символа пароля. Однако все даже хуже, поскольку каждый символ нижнего регистра заменяется соответствующим символом верхнего регистра, так что на самом деле вариантов для символа всего 69.
• Максимальное количество символов в пароле равно 14. Все пароли меньшей длины дополняются нулевыми байтами. Результирующее 14-байтовое значение затем делится на две равные части. Разделение данного значения на две половины сильно уменьшает область поиска для любой программы взлома паролей. В этом случае ей нужно угадать два значения из 69⁷ (~7.5 триллионов) возможных вместо одного из 69¹⁴ возможных (~55 септиллионов). Это меньше примерно на 13 порядков, что значительно облегчает задачу взломщика паролей.
• Наконец, не используется соль. Соль – дополнительный фрагмент данных, который, как правило, зависит от машины и/или от пользователя и добавляется к паролю перед хэшированием так, чтобы получившийся выходе хэш различался для двух пользователей, имеющих одинаковый пароль. Например, если соль не добавляется, а мой и ваш пароль имеют значение "abc123", то хэши наших паролей будут совпадать. Поскольку они одинаковы, возможно предварительно вычислить множество распространенных (и не распространенных) паролей и сохранить их вместе с соответствующими хэшами для быстрого и простого восстановления пароля по хэш-значению.

Данные существенные проблемы приводят к тому, что атаки на LM-хэши с помощью предвычисленных радужных таблиц столь эффективны. Наиболее эффективная реализация атаки на LM-хэши, которую мне приходилось видеть, была указана Чедом Тилбури. Преподавая курс SANS Forensics 408, Чед обратил внимание обучающихся на проект, суть которого в размещении радужных таблиц LM-хэшей на SSD-дисках. Это невероятно быстрое и недорогое решение для взлома очень сложных 14-символьных паролей всего за 5-11 секунд! Что это значит? Это значит, что если ваш LM-хэш (или хэш одного из ваших пользователей) станет известен атакующему, он узнает ваш пароль почти мгновенно.

Ужасные

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

По умолчанию ОС Windows, начиная с Vista, не хранят LM-хэши на диске (в базе данных SAM) из-за того, что в регистре включена опция "NoLMHash". Более того, данная статья MS описывает, как отключить эту опцию для более старых систем и в Active Directory. Она, коротко говоря, описывает, как установить опцию NoLMHash через Групповую Политику. Это показано в настройках моего тестового доменного контроллера:

Другое предоставленное Microsoft средство борьбы дает способ предотвратить аутентификацию в Windows по сетевому протоколу аутентификации вызова-ответа (challenge-response) LMv1/LMv2. Через несколько недель я опубликую статью, в которой будет подробно рассмотрена сетевая аутентификация, поэтому здесь я не буду останавливаться на всех тонкостях ее работы. Стоит лишь сказать, что LM-хэш требуется для завершения сетевой вызов-ответной аутентификации типа LMv1 или LMv2. Так что, если мы средствами Microsoft отключим вызов-ответные протоколы и разрешим использование только более нового протокола NTLMv2 (которому необходим лишь NT-хэш, а не LM), тогда Windows перестанет нуждаться в LM-хэшах, так ведь? По крайней мере, я так думал.

Итак, здесь я выставил наиболее безопасный уровень сетевой аутентификации, который разрешает лишь NTLMv2 (равно как и Kerberos) – эффективно отключив протоколы вызова-ответа:

Теперь я хочу протестировать эффективность данных изменений и посмотреть, настолько ли хорошо они отключают LM-хэши, как я того ожидаю. Я сделаю это на системе Windows 7 SP1 в надежде на то, что современная ОС предоставит большую степень защиты от LM-хэшей.

На своей тестовой машине (USER-WIN7) под управлением Windows 7, которая присоединена к домену MSAD2 из моей предыдущей статьи, я обновил Групповую Политику так, чтобы она отражала изменения, ранее сделанные в Групповой Политике домена. Вот как новые настройки отображаются на клиенте с Windows 7.

Вдобавок я изменил пароль локальной учетной записи MIKE и пароль доменной учетной записи MSAD2-RESPONDER2, а затем перезагрузил машину:

Теперь-то и начинается настоящий ужас. Применив политику запрещения хранения LM-хэшей, мы не должны видеть LM-хэши на диске. Применив политику, отключающую сетевые протоколы вызова-ответа на базе LM, мы должны были исключить необходимость хранения LM-хэшей в памяти. В конце концов, с чего бы им храниться в памяти или на диске, если они больше не нужны ни для локального, ни для удаленного использования? Что ж, настало время посмотреть, как дело обстоит на практике.

После применения показанных выше изменений, которые предположительно должны были предотвратить хранение и использование LM-хэшей, я выполнил вход через консоль на машине с Windows 7 под доменной учетной записью MSAD2-RESPONDER2. Я также запустил команду RunAs, чтобы войти под локальным пользователем MIKE. Это позволит нам увидеть хэши обоих пользователей, загруженные в память. (Вспомним, что учетная запись должна иметь текущую интерактивную сессию входа, чтобы хэш ее пароля был загружен в память – для подробностей см. мою статью о парольных хэшах).

Сначала давайте посмотрим, какие локальные хэши хранятся на диске.

• Здесь я запустил утилиту pwdump6, которая покажет хэши локальных аккаунтов, хранящиеся на диске (в БД SAM):
  

Как и ожидалось, нет ни одного LM-хэша. Первые два аккаунта по умолчанию отключены, поэтому для них не было установлено никакого пароля. Для аккаунта MIKE хранится лишь NT-хэш пароля. До сих пор все идет как надо!

Теперь давайте посмотрим, какие хэши присутствуют в памяти.

• Для данной задачи используем Windows Credentials Editor (WCE).
  

Это совершенно недопустимо! Оказывается, что Windows вычисляет и сохраняет LM-хэш в памяти при условии, что пароль имеет длину менее 15 символов, независимо от настроек хоста или домена, касающихся храненеия LM-хэшей и протоколов вызова-ответа!

Теперь, имея на руках LM-хэши, мы можем легко взламывать пароли. Здесь я использую ранее упомянутую SSD-реализацию радужных таблиц LM от Objectif Sécurité:

• Взломанный пароль локального аккаунта MIKE:
  
• Взломанный пароль доменного аккаунта MSAD2-RESPONDER2:
  

Выглядит пугающе, не правда ли? Это означает, что любой пользователь, чья машина была скомпрометирована и чьи хэши были выгружены из памяти, по сути открывает свой пароль, поскольку свободно доступные радужные таблицы LM могут взламывать наиболее сложные 14-символьные пароли за считанные секунды.

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

Проблема размещения LM-хэшей в памяти была отмечена в документе Гернана Окоа, описывающем его утилиту Windows Credentials Editor (см. страницу 23 данного документа). Для дополнительного подтверждения наличия проблемы вдобавок к документу Гернана и моим собственным тестам я связался с Microsoft и получил неофициальный ответ, в котором говорилось, что они в курсе дел. Суть их ответа сводилась к тому, что даже если бы они исправили данный недостаток, все равно остались бы значительные проблемы, связанные с атаками передачи хэша и LSA-шифрованными паролями (о которых я расскажу в следующий раз), так что они не видят смысла рисковать, меняя значительный кусок кода.

Хорошие

Понимаю, что это натяжка, но здесь я хотел бы отметить одну "хорошую" вещь, касающуюся LM-хэшей – тот факт, что пароль длиной 15 и более символов сделает алгоритм вычисления LM-хэша абсолютно неприменимым, поэтому Windows не сможет вычислить и сохранить LM-хэш в памяти (или на диске). Так что, у вас есть один способ справиться с рассмотренной проблемой –сделайте длину вашего пароля не менее 15 символов.

Чтобы продемонстрировать это, я поменяю пароли локального пользователя MIKE и доменного пользователя MSAD2-RESPONDER2 так, чтобы они имели длину более 14 символов:

Теперь после выхода и повторного входа давайте снова проверим эти хэши в памяти:

Фуф! Единственное положительное свойство LM-хэша в том, что мы можем полностью избавиться от него, выбрав достаточно длинный пароль. Здесь есть хороший побочный эффект: устанавливая пароль длиной 15 и более символов, вы также делаете ваш NT-хэш очень устойчивым к атакам на основе предвычисленных значений. Однако, нам все еще нужно защищать NT-хэши от злоупотребления ими в атаках передачи хэша. Как уже говорилось в моей предыдущей статье, этого можно добиться, избегая интерактивных входов в систему под привилегированной учетной записью.

Заключение

Учитывая эффкетивность использования радужных таблиц LM на современном оборудовании, LM-хэши могут, по сути, считаться эквивалентными паролям, записанным открытым текстом. К сожалению, Microsoft не предоставляет нам механизма для удаления LM-хэшей из памяти. Поэтому, единственный способ защитить аккаунты, используемые вами при интерактивном входе, – убедиться, что соответствующий пароль имеет длину не менее 15 символов. Это сделает алгоритм LM-хэширования неприменимым.

Это довольно простое решение для одноразовых аккаунтов, но все становится гораздо сложнее, когда мы пытаемся защитить тысячи аккаунтов конечных пользователей. Хотя вы возможно встретите ожесточенное сопротивление (а может даже будете подняты на смех), стоит по меньшей мере обсудить в вашей организации реализацию политики 15-символьных паролей или политики парольных фраз... или же надавить на Microsoft, чтобы она предоставила нам лучший вариант решения проблемы.

Это еще не все, следите за новостями!