Что такое lm хэш
Существует 2 возможности получения пароля — через реестр, или получив прямой доступ к файлам-кустам реестра. В любом случае нужны будут либо привелегии пользователя SYSTEM, либо хищение заветных файлов, например, загрузившись из другой ОС. Здесь я не буду описывать возможности получения доступа, но в целях исследования нагляднее будет выбрать первый вариант, это позволит не заострять внимание на структуре куста реестра. А запуститься от системы нам поможет утилита psExec от sysinternals. Конечно, для этих целей можно использовать уязвимости windows, но статья не об этом.
V-блок
Windows до версии Vista по умолчанию хранила пароль в двух разных хэшах — LM и NT. В висте и выше LM-хэш не хранится. Для начала посмотрим где искать эти хэши, а потом разберемся что из себя они представляют.
Пароли пользователей, а так же много другой полезной информации хранится в реестре по адресу HKLM\SAM\SAM\Domains\Account\users\[RID]\V
, известном как V-блок. Раздел SAM находится в соответствующем файле c:\Windows\System32\config\SAM. RID — уникальный идентификатор пользователя, его можно узнать, например заглянув в ветку HKLM\SAM\SAM\Domains\Account\users\names\ (параметр Default, поле — тип параметра). Например, RID учетной записи «Администратор» всегда 500 (0x1F4), а пользователя «Гость» — 501 (0x1f5). Доступ к разделу SAM по умолчанию возможен только пользователю SYSTEM, но если очень хочется посмотреть — запускаем regedit c правами системы:
PsExec.exe -s -i -d regedit.
Чтобы наблюдать V-блок в удобном виде можно, например, экспортировать его в текстовый файл (File-Export в Regedit).
Вот что мы там увидим:
От 0x0 до 0xCC располагаются адреса всех данных, которые находятся в V-блоке, их размеры и некоторая дополнительная информация о данных. Чтобы получить реальный адрес надо к тому адресу, что найдем прибавить 0xCC. Адреса и размеры хранятся по принципу BIG ENDIAN, т.е понадобится инвертировать байты. На каждый параметр отводится по 4 байта, но фактически все параметры умещаются в одном-двух байтах. Вот где искать:
Адрес имени пользователя — 0xС
Длина имени пользователя — 0x10
Адрес LM-хэша — 0x9с
Длина LM-хэша — 0xa0
Адрес NT-хэша — 0xa8
длина NT-хэша — 0xac
В данном случае имя пользователя найдется по смещению 0xd4 + 0xcc и его длина будет 0xc байт.
NT-хэш будет располагаться по смещению 0x12c + 0xcc и его размер (всегда один и тот же) = 0x14.
int lmhashOffset = userVblock[0x9c] + userVblock[0x9d] * 0x100 + 4 + 0xcc;
int nthashOffset = userVblock[0xa8] + userVblock[0xa9] * 0x100 + 4 + 0xcc;
int lmhashSize = userVblock[0xa0] + userVblock[0xa1] * 0x100 - 4;
int nthashSize = userVblock[0xac] + userVblock[0xad] * 0x100 - 4;
int usernameOffset = userVblock[0xc] + userVblock[0xd] * 0x100 + 0xcc;
int usernameLen = userVblock[0x10] + userVblock[0x1a] * 0x100;
userVblock — значение HKLM\SAM\SAM\Domains\Account\users\\V в виде массива байт.
Еще про V-блок можно почитать тут.
Алгоритмы
Теперь разберемся в алгоритмах шифрования.
Формирование NT-хэша:
1. Пароль пользователя преобразуется в Unicode-строку.
2. Генерируется MD4-хэш на основе данной строки.
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.
Формирование LM-хэша:
1. Пароль пользователя преобразуется в верхний регистр и дополняется нулями до длины 14 байт.
2. Полученная строка делится на две половинки по 7 байт и каждая из них по отдельности шифруется алгоритмом DES. В итоге получаем хэш длиной 16 байт (состоящий из двух независимых половинок длиной по 8 байт).
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.
4. В windows 2000 и выше оба полученых хэша дополнительно шифруются алоритмом RC4 с помощью ключа, известного как «системный ключ» или bootkey, сгенерированого утилитой syskey, и шифруются довольно хитрым образом.
Рассмотрим общую последовательность действий для получения исходного пароля и каждый шаг в отдельности
1. Получаем bootkey, генерируем на его основе ключи для RC4, расшифровываем хэши с помощью RC4
2. Получаем ключи для DES из RID'ов пользователей, расшифровываем хэши DES'ом
3. Полученые хэши атакуем перебором.
Bootkey
Системный ключ (bootkey) разбит на 4 части и лежит в следующих разделах реестра:
HKLM\System\CurrentControlSet\Control\Lsa\JD
HKLM\System\CurrentControlSet\Control\Lsa\Skew1
HKLM\System\CurrentControlSet\Control\Lsa\GBG
HKLM\System\CurrentControlSet\Control\Lsa\Data
Раздел system находится в файле c:\Windows\System32\config\system
Следует отметить, что раздел CurrentControlSet является ссылкой на один из разделов controlset и создается в момент загрузки системы. Это значит что не получится его найти в файле system, если система неактивна. Если вы решили искать ключ в файле — необходимо узнать значение ContolSet по умолчанию в HKLM\SYSTEM\Select\default.
например если HKLM\SYSTEM\Select\default = 1 — вместо HKLM\System\CurrentControlSet\ ищем в HKLM\System\controlset001\
У каждого ключа реестра есть некий скрытый атрибут, известный как «class». Regedit его так просто не покажет, однако его можно увидеть, например, если экспортировать эти ключи реестра в текстовые файлы. В winapi для получения этого атрибута есть функция RegQueryInfoKey.
Фрагменты хранятся в строковом представлении шестнадцатеричных чисел, причем по принципу BIG ENDIAN (т.е не строка задом наперед, а число).
Например мы обнаружили вот такие записи:
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD
Class Name: 46003cdb =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
Class Name: e0387d24 =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
Class Name: 4d183449 =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data
Class Name: 0419ed03 =
Собраный из четырех частей ключ будет массивом байт:
Далее элементы этого массива переставляются на основе некоторого константного массива p
key[i] = scrambled_key[p[i]];
В нашем примере получится массив:
этот массив и есть так называемый bootkey. Только в шифровании паролей будет учавствовать не он а некий хэш на основе bootkey, фрагментов f-блока и некоторых констант. Назовем его Hashed bootkey.
Hashed bootkey
для получения Hashed bootkey нам понадобятся 2 строковые константы (ASCII):
На основе этих значений, склееных в один большой массив формируем MD5 хэш, который будет являться ключем для шифрования RC4
rc4_key = MD5(F[0x70:0x80] + aqwerty + bootkey + anum).
Последним шагом для получения hashed bootkey будет rc4 шифрование( или дешифрование — в rc4 это одна и та же функция) полученым ключем фрагмента F-блока F[0x80:0xA0];
Hashed bootkey у нас в руках, осталось научиться с ним правильно обращаться.
Дешифруем пароли с помощью Hashed Bootkey
для паролей LM и NT нам понадобятся еще 2 строковые константы —
string almpassword = "LMPASSWORD";
string antpassword = "NTPASSWORD";
а так же RID пользователя в виде 4х байт (дополненый нулями) и первая половина Hashed Bootkey (hashedBootkey[0x0:0x10]);
Все это склеивается в один массив байт и считается MD5 по правилам:
rc4_key_lm = MD5(hbootkey[0x0:0x10] +RID + almpassword);
rc4_key_nt = MD5(hbootkey[0x0:0x10] +RID + antpassword);
полученый md5 хэш — ключ для rc4, которым зашифрованы LM и NT хэши в V-блоке пользователя
userLMpass = RC4(rc4_key_lm,userSyskeyLMpass);
userNTpass = RC4(rc4_key_lm,userSyskeyNTpass);
На этом этапе мы получили пароли пользователя в том виде в каком они хранились бы без шифрования syskey, можно сказать, что самое сложное позади. Переходим к следующему шагу
private byte[] sid_to_key1(byte[] rid) byte[] s = new byte[7];
s[0] = (byte)(rid[0] & 0xFF);
s[1] = (byte)(rid[1] & 0xFF);
s[2] = (byte)(rid[2] & 0xFF);
s[3] = (byte)(rid[3] & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];
private byte[] sid_to_key2(byte[] rid) byte[] s = new byte[7];
s[0] = (byte)((rid[3]) & 0xFF);
s[1] = (byte)(rid[0] & 0xFF);
s[2] = (byte)((rid[1]) & 0xFF);
s[3] = (byte)((rid[2]) & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];
Ну здесь особо комментировать нечего, кроме функции des_set_odd_parity(ref key) — это одна из функций библиотеки openssl, задача которой добавить некоторые «биты нечетности», используется для повышения стойкости ключа к атакам.
Далее разбиваем NT (или LM) хэш на 2 части по 8 байт и дешифруем DES'ом -одна половина зашифрована ключем сформированым функцией sid_to_key1, вторая — sid_to_key2.
obfskey_l = userNTpass[0x0:0x7]
obfskey_r = userNTpass[0x8:0xF]
byte[] deskey1 = sid_to_key1(RID);
byte[] deskey2 = sid_to_key2(RID);
byte[] md4hash_l = DES(obfskey_l, deskey1);
byte[] md4hash_r = DES(obfskey_r, deskey2);
После склеивания двух половин мы получим md4 хэш -в случае NT, или LanMan (DES) — в случае LM. Полученый хэш полностью готов к атаке перебором.
Кстати, md4 Хэш от пустого пароля — 31d6cfe0d16ae931b73c59d7e0c089c0
Исследование проведено на основе исходного кода ophcrack-3.3.1, а так же статьи Push the Red Button:SysKey and the SAM
Это вторая статья из цикла "Защита привилегированных аккаунтов домена". Моя главная цель – помочь сотрудникам службы реагирования на инциденты безопасности (IR) защитить их привилегированные аккаунты при взаимодействии со скомпрометированными хостами, однако я полагаю, что эта информация будет полезна и всем тем, кто администрирует и защищает системы Windows.
Остальные статьи цикла:
Я осознаю, что LM-хэши (LanMan) для многих являются прошлым веком, однако недавно я обнаружил, что LM-хэш даже более опасен, чем мне раньше казалось. Причинами тому являются как простота взлома LM-хэшей на современном оборудовании, так и неявный факт того, что Microsoft не дает возможности удалять эти хэши из памяти. Поэтому, даже если вы считаете, что уже слышали о LM-хэшах все что можно, я рекомендую вам дочитать эту статью, дабы убедиться, что вы осведомлены о LM-хэшах, таящихся в памяти.
Кому нужен сломанный ключ?
Интерес этого метода заключается в том, что получен хэш без физического или административного доступа к системе.
Автор: Марк Гамачи (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-ми байтного блока).
Все три зашифрованных куска соединяются вместе, и получается 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 успешно провел атаку для «рукопожатия» CHAPv2. Полученный NT-хэш приведен ниже. Далее, используя утилиту «chapcrack», вы можете расшифровать пакеты или произвести аутентификацию на сервере:
cd06ca7c7e10c99b1d33b7485a2ed808
Кому: Всем сотрудникам
От кого: Отдел кадров
Тема письма: Обновление памятки для сотрудников
Наконец, с введением Washington Initiative 502, мы опубликовали новые правила по применению марихуаны на рабочем месте.
Памятку находится здесь:
С наилучшими пожеланиями,
Отдел кадров
Я назвал эту атаку «Запрос хэша». Извините за каламбур, но мне кажется после прочтения письма, сразу же возникает желание скачать и прочитать новые правила компании.
Прежде всего, я выражаю благодарность компании Microsoft, которая сделала по умолчанию использование NLTMv2 (как в Висте) и оставила возможность, для тех, кому это важно, использования LM и NTLM «рукопожатий». Однако я думаю, MS следует добавить настройку на уровень локальной политики безопасности, чтобы администраторы доменов могли использовать ее по мере необходимости.
При внедрении изменений в политику безопасности на предприятиях могут возникнуть проблемы несовместимости, однако хорошая новость в том, что механизмы LM, NTLM и NTLMv2 используются довольно продолжительное время. Ключ реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel позволяет выбрать, какие типы «рукопожатий» разрешены в системе. Для рабочих станций предпочтительнее установить значение 3 или выше. Хотя ситуация может быть не так однозначна, поскольку многие системы под управлением ОС Windows могут быть как рабочими станциями, так и серверами (предоставляя ресурсы $admin, c$ и т. п.). Одни те же настройки могут отличаться по смыслу на разных версиях систем. В отличной статье, написанной Джеспером Йоханссоном, рассказывается про клиентские и серверные системы. Лично я на всех своих системах установил значение 5. Если вы установите значение меньше 5, то, значит, в вашей сети допускается использование NTLM или LM «рукопожатий».
Наименование групповой политики
Допустимые форматы запросов
Запрещенные форматы запросов
Отправлять только LM и NTLM-ответы
LM, NTLM,
NTLMv2 Session Security если необходимо
NTLMv2
Session Security (в системах Windows 2000 ниже SRP1, Windows NT 4.0, и Windows 9x)
Отправлять LM and NTLM—использование NTLMv2 session security если необходимо
LM, NTLM
NTLMv2 Session Security если необходимо
Отправлять только NTLM-ответы
NTLM,
NTLMv2 Session Security если необходимо
Отправлять только NTLMv2-ответы
Только NTLMv2
Session Security
Отправлять только NTLMv2-ответы/запрещать аутентификацию LM
NTLMv2 Session Security
Отправлять только NTLMv2-ответы/запрещать аутентификацию LM и NTLM
NTLMv2,
Session Security
Вы можете спросить: «Какая разница, если мой сервер разрешает LM или NTLM-аутентификацию?» Если не все клиентские машины под контролем, то сервер может быть использован для получения учетной записи клиента с небезопасными настройками.
Напоминание о последствиях «ничегонеделания»
В то время как браузеры выполняют 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 стоит 20$, и мне не хотелось отправлять ошибочные варианты в процессе отладки программы.
Код можно скачать здесь.
Запрос и ответ должны быть шестнадцатеричном формате, а пароль – простой текст.
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
Очень часто встречаю, что люди путают разные типы хэшей и думают, что NTLM и NTLMv1/v2 это одно и тоже, а NTLMv1/v2 и Net-NTLMv1/v2 разные типы. Данная статья заметка предназначена для того, что бы разобраться со всем этим.
Если хочешь побыстрее и кратко, то читай тут
Ловим Net-NTLMv2
Все что нам нужно - запустить Responder или Inveigh и ловить отстуки с хэшами
Responder output
Введение
Когда, полтора десятка лет назад, компания Microsoft начала серьезную работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная, и новая по тем временам задача – реализовать технологии single sign-on, и One user – one password.
One user – one password (один пользователь – один пароль) означает, что у пользователя должен быть только один пароль. Единый пароль используется для доступа ко всем ресурсам и протоколам сети. Single sign-on (единый вход) подразумевает, что этот пароль указывается всего один раз – при входе пользователя в сеть.
Можно много спорить о преимуществах и недостатках такого подхода, но бесспорно одно – этот подход удобен как для пользователей, так и для разработчиков приложений. Пользователь избавлен от необходимости помнить много паролей и вводить их, а разработчику не надо задумываться над тем, как организовать аутентификацию пользователя.
Для этого необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Так родился NTLM и NTLMSSP (NTLM Security Service Provider) – подсистема позволяющая любому клиент-серверному приложению использовать NTLM ничего не зная о его внутренней структуре.
Нельзя сказать, чтобы Microsoft проигнорировал требования безопасности для протокола аутентификации. В общем-то, на тот момент протокол NTLM не был слабее многих уже использовавшихся протоколов, и в чем-то даже лучше. Но сейчас можно с уверенностью сказать, что вместе с протоколом NTLM появилось большое количество проблем связанных с его безопасностью. Часть проблем вызвана тем, что Microsoft должен был сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками дизайна и объясняются новизной решаемой проблемы. Третьи являются исключительно криптографическими, т.к. тогда производители ПО редко имели в штате профессиональных криптоаналитиков.
Проблемы протокола NTLM широко дискутировались начиная с 1995 года и обсуждаются до сих пор. Существует ошибочное мнение, что протокол аутентификации Kerberos v5, используемый в сетях Windows 2000 и Windows 2003, полностью снимает проблему NTLM. Это не так, т.к. поддержка NTLM в существующих сетях Windows является обязательной и любая из сторон, принимающих участие в процессе аутентификации, может инициировать использование этого протокола. По этой причине многие проблемы протокола NTLM остаются актуальными в современных сетях Windows и должны учитываться не только в процессе администрирования сети, но и на этапе ее проектирования.
Мы не будем углубляться в технические детали более, чем это необходимо для понимания проблемы, тем не менее, иногда от читателя потребуются некоторые минимальные представления о процессах аутентификации и авторизации, программировании и криптографии. Чтобы облегчить жизнь читателю, в статье будут встречаться вставки «общеобразовательного» характера.
Процесс аутентификации клиент-серверных приложений в сетях Microsoft
Что происходит после нажатия на Ctrl+Alt+Del? Появляется запрос локальной подсистемы безопасности (Local Security Authority, LSA) на ввод имени пользователя и пароля. После ввода пароль хэшируется (криптографический хэш – одностороннее преобразование делающее невозможным, или по крайней мере сложным восстановление по нему оригинального пароля) и хэш помещается в хранилище LSA. В открытом виде он больше уже нигде не фигурирует (в старых версиях Windows пароль мог храниться в открытом виде или с обратимым шифрованием, т.к. старые версии LanManager использовали аутентификацию в открытом тексте, но не будем вспоминать эти времена). Кроме того, к хранилищу LSA нельзя обратиться напрямую стандартными методами. В хранилище хэши находятся до окончания сеанса работы (а иногда и после, это будет рассмотрено далее).
Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль ни его хэш никогда не передаются «как есть», вместо этого они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP. Данные аутентификации, генерируемые NTLMSSP через специальные функции API (InitializeSecurityContext()/AcceptSecurityContext()) могут быть включены в любой протокол прикладного уровня, упаковка этих данных (называемых security blob – «начинка безопасности») это все, что требуется от приложений с точки зрения NTLMSSP. После успешной проверки подсистема безопасности генерирует токен, который может быть использован серверным приложением с правами локальной системы для имперсонирования пользователя, т.е. при подключении пользователя к серверному приложению серверное приложение может работать от его имени. В таком случае пользователь совершает вход на удаленную систему. Возникает вопрос – а может ли серверное приложение обратиться к другим сетевым ресурсам с использованием NTLM, не запрашивая дополнительной аутентификации? Если в хранилище LSA удаленного компьютера нет хэшей пароля пользователя – то это невозможно. Отсюда, например, невозможность «прозрачного» доступа к сетевому диску из telnet-сеанса или через Web-сервер если доступ через telnet или к Web происходит с NTLM аутентификацией.
Теоретически все получается замечательно и абсолютно безопасно. Даже запустив приложение с правами пользователя, все равно не возможно получить его пароль или даже хэш. И даже перехватив сеанс и подменив сервер, не получится получить доступ к другим сетевым ресурсам.
Давайте посмотрим на все это с точки зрения реализации.
Хэши NTLM
В семействе протоколов NTLM (как мы увидим далее, NTLM-подобных протоколов несколько) могут использоваться 2 типа хэшей: LM (LanManager) хэш, унаследованный от предыдущих реализаций LanManager и NT (New Technology) хэш, созданный для протокола NTLM. Соответственно, при входе пользователя в систему, как правило, от пароля берутся и хранятся оба этих хэша. Первая версия протокола NTLM для совместимости поддерживала оба ключа (NT или LM ключем обычно называют соответствующий хэш пароля). В более поздних реализациях используется только NT ключ, однако по-умолчанию LM хэш все равно создается при входе и помещается в хранилище LSA. Давайте рассмотрим оба алгоритма хэширования.
Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом, т.е. реально каждый 64 бита хэша можно атаковать с целью восстановления пароля. Причем для генерации LM ключа пароль не чувствителен к регистру символов и символы всегда используются в верхнем реестре. Это делает очень эффективной атаку на восстановление пароля методом последовательного перебора (не более 7 символов из очень ограниченного алфавита). Причем длинный пароль может быть легче восстановить чем более короткий. Например, для пароля из 12 символов, сначала за считанные секунды подбираются последние 5 символов, после чего делается предположение о структуре пароля и первые 7 символов пароля подбираются по более ограниченному алфавиту. В настоящее время известны очень быстрые реализации DES с использованием 64-битной арифметики, что делает его абсолютно непригодным для криптографии. В общем случае, восстановление пароля по LM хэшу на современной технике вопрос не более чем нескольких дней. Кроме того, фиксированное магическое слово позволяет использование таблицы заранее посчитанных значений ключей, что делает возможным восстановление пароля по LM хэшу в реальном времени.
NT ключ вычисляется с помощью стандартного алгоритма хэширования MD4. Хэш MD4 берется от пароля записанного в 16-битной кодировке Unicode с последовательностью байт low endian (т.е. первым байтом идет номер символа в странице). Пароль вычисляется с учетом регистра. MD4 имеет несколько криптографических проблем, самой большой из них является маленькое время вычисления хэша, что позволяет перебирать достаточно большое количество комбинаций в единицу времени упрощая, например, атаку по словарю или подбор слабой комбинации символов.
Совет: Можно запретить генерацию LM-ключей в системе путем установки в 1 значения NoLmHash в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Несмотря на то, что будет описано ниже, сделать это настоятельно рекомендуется, хотя бы для очистки совести.
Краткий вывод
LM-хэши и NT-хэши - это хэши паролей для хранения их в Windows. Хранятся в SAM или NTDS.dit. Могут быть крякнуты для получения пароля в открытом виде, а NT хэш еще и использован для атаки Pass-The-Hash.
NTLMv1/v2 - это протоколы, используемые для сетевой аутентификации в средах Windows. Они используют NT-хэш в алгоритме, что означает, что его можно использовать для восстановления пароля с помощью атак методом перебора. Получить их можно, допустим, проведя атаку LLMNR Poisoning, то есть проведя атаку, где потребуется взаимодействие по сети. Стоить уточнить, что их можно релеить, что добавляет нам еще 1 вектор атаки.
Плохие
Хотя проблемы LM-хэшей хорошо задокументированы, позвольте мне кратко описать, как создаются LM-хэши. После этого вы сразу увидите несколько значительных проблем данного алгоритма. Эти проблемы позволяют выявить причины, по которым нам необходимо избавиться от LM-хэшей. Вот как работает алгоритм LM-хэширования (материал с Википедии):
В дизайне алгоритма есть множество изъянов. Позвольте мне кратко описать некоторые из них:
- Факт того, что каждый символ пароля является ASCII-символом (одним из 95 печатных символов), означает, что есть только 95 вариантов для каждого символа пароля. Однако все даже хуже, поскольку каждый символ нижнего регистра заменяется соответствующим символом верхнего регистра, так что на самом деле вариантов для символа всего 69.
- Максимальное количество символов в пароле равно 14. Все пароли меньшей длины дополняются нулевыми байтами. Результирующее 14-байтовое значение затем делится на две равные части. Разделение данного значения на две половины сильно уменьшает область поиска для любой программы взлома паролей. В этом случае ей нужно угадать два значения из 69 7 (~7.5 триллионов) возможных вместо одного из 69 14 возможных (~55 септиллионов). Это меньше примерно на 13 порядков, что значительно облегчает задачу взломщика паролей.
- Наконец, не используется соль. Соль – дополнительный фрагмент данных, который, как правило, зависит от машины и/или от пользователя и добавляется к паролю перед хэшированием так, чтобы получившийся выходе хэш различался для двух пользователей, имеющих одинаковый пароль. Например, если соль не добавляется, а мой и ваш пароль имеют значение "abc123", то хэши наших паролей будут совпадать. Поскольку они одинаковы, возможно предварительно вычислить множество распространенных (и не распространенных) паролей и сохранить их вместе с соответствующими хэшами для быстрого и простого восстановления пароля по хэш-значению.
Данные существенные проблемы приводят к тому, что атаки на LM-хэши с помощью предвычисленных радужных таблиц столь эффективны. Наиболее эффективная реализация атаки на LM-хэши, которую мне приходилось видеть, была указана Чедом Тилбури. Преподавая курс SANS Forensics 408, Чед обратил внимание обучающихся на проект, суть которого в размещении радужных таблиц LM-хэшей на SSD-дисках. Это невероятно быстрое и недорогое решение для взлома очень сложных 14-символьных паролей всего за 5-11 секунд! Что это значит? Это значит, что если ваш LM-хэш (или хэш одного из ваших пользователей) станет известен атакующему, он узнает ваш пароль почти мгновенно.
Дампим NTLM хэши
Есть много способов, как получить ntlm хэши пользователей, один из способов ниже
Дамп в mimikatz
Как я уже упоминал, мы можем произвести атаку Pass-The-Hash.
Pass-The-Has
Заключение
Учитывая эффкетивность использования радужных таблиц LM на современном оборудовании, LM-хэши могут, по сути, считаться эквивалентными паролям, записанным открытым текстом. К сожалению, Microsoft не предоставляет нам механизма для удаления LM-хэшей из памяти. Поэтому, единственный способ защитить аккаунты, используемые вами при интерактивном входе, – убедиться, что соответствующий пароль имеет длину не менее 15 символов. Это сделает алгоритм LM-хэширования неприменимым.
Это довольно простое решение для одноразовых аккаунтов, но все становится гораздо сложнее, когда мы пытаемся защитить тысячи аккаунтов конечных пользователей. Хотя вы возможно встретите ожесточенное сопротивление (а может даже будете подняты на смех), стоит по меньшей мере обсудить в вашей организации реализацию политики 15-символьных паролей или политики парольных фраз. или же надавить на Microsoft, чтобы она предоставила нам лучший вариант решения проблемы.
Это еще не все, следите за новостями!
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
То, что в последние годы проблемы безопасности протокола NTLM обсуждаются реже, чем раньше, выходят новые версии Microsoft Windows и внедряются новые протоколы аутентификации, не означает что проблемы исчезли. Эта статья - попытка собрать в одном месте информацию о различных недостатках NTLM, возможных атаках и о том, как следует учитывать архитектуру NTLM при проектировании и администрировании корпоративных сетей.
NTLMv1/v2 и Net-NTLMv1/v2 одно и то же?
Тут не будет списка различий между Net-NTLMv1/v2 и NTLMv1/v2, ведь это одно и то же! Да, NTLMv1/v2 это всего лишь сокращение для Net-NTLMv1/v2.
Ужасные
Если все это выглядело недостаточно удручающе, давайте перейдем к действительно ужасным вещам. До того, как мы это сделаем, я должен отметить, что 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-шифрованными паролями (о которых я расскажу в следующий раз), так что они не видят смысла рисковать, меняя значительный кусок кода.
NTLM (NT)
NT - немного сложнее и он используется в современных Windows системах. Этот хэш наиболее интересен для хакера пентестера, ведь с этим хэшом можно провести атаку Pass-The-Hash.
Обычно люди называют его NTLM хэшем, что вводит в заблуждение, потому что в одном месте его называют NT, а в другом NTLM хэш. Оба варианта используются в учебных материалах и, обычно, подразумевается одно и тоже, НО правильнее NT.
Алгоритм: Пароль пользователя -> UTF16-LE (LE - Little Endian) -> MD4.
(Net-)NTLMv1/v2
Это протоколы! Они не используется для хранения паролей, это протоколы, используемый для аутентификации клиента/сервера, чтобы избежать отправки хэша пользователя по сети.
Но если нам удается перехватить их, допустим, через атаку LLMNR Poisoning, мы не можем провести атаку Pass-The-Hash (логично, не правда ли?). Мы можем попытаться его сбрутить и попробовать получить пароль в плейн тексте или, например, релеить.
Смотрим подробнее
LM хэши, как и NT хэши пользователей хранятся в SAM или в NTDS.dit на контроллере доменов.
Файл ntds. dit представляет собой базу данных, в которой хранится информация Active Directory, такая как сведения о пользователях, группах и членстве в группах. База также включает хеши паролей для всех пользователей в домене. Source
Если вы сдампите хэши, вы увидите примерно такую картину -: :.
Пример: JohnDoe:503:aad3c435b514a4eeaad3b935b51304fe:c46b9e588fa0d112de6f59fd6d58eae3.
LM - старый алгоритм, который не используется, начиная с Windows Vista/Server 2008. Из за особенностей алгоритма, он не является криптостойким, именно поэтому появился NT.
Приводим пароль к верхнему регистру
Если пароль длинее 14 байтов, то он обрезается до 14 байтов. Если короче, то дополняется нулями.
Получившийся пароль делим на 2 части по 7 байтов.
Конкатенируем полученные значения и получаем LM хэшик
Хорошие
Чтобы продемонстрировать это, я поменяю пароли локального пользователя MIKE и доменного пользователя MSAD2-RESPONDER2 так, чтобы они имели длину более 14 символов:
Теперь после выхода и повторного входа давайте снова проверим эти хэши в памяти:
Фуф! Единственное положительное свойство LM-хэша в том, что мы можем полностью избавиться от него, выбрав достаточно длинный пароль. Здесь есть хороший побочный эффект: устанавливая пароль длиной 15 и более символов, вы также делаете ваш NT-хэш очень устойчивым к атакам на основе предвычисленных значений. Однако, нам все еще нужно защищать NT-хэши от злоупотребления ими в атаках передачи хэша. Как уже говорилось в моей предыдущей статье, этого можно добиться, избегая интерактивных входов в систему под привилегированной учетной записью.
Плохие
Хотя проблемы LM-хэшей хорошо задокументированы, позвольте мне кратко описать, как создаются LM-хэши. После этого вы сразу увидите несколько значительных проблем данного алгоритма. Эти проблемы позволяют выявить причины, по которым нам необходимо избавиться от LM-хэшей. Вот как работает алгоритм LM-хэширования (материал с Википедии):
В дизайне алгоритма есть множество изъянов. Позвольте мне кратко описать некоторые из них:
- Факт того, что каждый символ пароля является ASCII-символом (одним из 95 печатных символов), означает, что есть только 95 вариантов для каждого символа пароля. Однако все даже хуже, поскольку каждый символ нижнего регистра заменяется соответствующим символом верхнего регистра, так что на самом деле вариантов для символа всего 69.
- Максимальное количество символов в пароле равно 14. Все пароли меньшей длины дополняются нулевыми байтами. Результирующее 14-байтовое значение затем делится на две равные части. Разделение данного значения на две половины сильно уменьшает область поиска для любой программы взлома паролей. В этом случае ей нужно угадать два значения из 69 7 (~7.5 триллионов) возможных вместо одного из 69 14 возможных (~55 септиллионов). Это меньше примерно на 13 порядков, что значительно облегчает задачу взломщика паролей.
- Наконец, не используется соль. Соль – дополнительный фрагмент данных, который, как правило, зависит от машины и/или от пользователя и добавляется к паролю перед хэшированием так, чтобы получившийся выходе хэш различался для двух пользователей, имеющих одинаковый пароль. Например, если соль не добавляется, а мой и ваш пароль имеют значение "abc123", то хэши наших паролей будут совпадать. Поскольку они одинаковы, возможно предварительно вычислить множество распространенных (и не распространенных) паролей и сохранить их вместе с соответствующими хэшами для быстрого и простого восстановления пароля по хэш-значению.
Данные существенные проблемы приводят к тому, что атаки на LM-хэши с помощью предвычисленных радужных таблиц столь эффективны. Наиболее эффективная реализация атаки на LM-хэши, которую мне приходилось видеть, была указана Чедом Тилбури. Преподавая курс SANS Forensics 408, Чед обратил внимание обучающихся на проект, суть которого в размещении радужных таблиц LM-хэшей на SSD-дисках. Это невероятно быстрое и недорогое решение для взлома очень сложных 14-символьных паролей всего за 5-11 секунд! Что это значит? Это значит, что если ваш LM-хэш (или хэш одного из ваших пользователей) станет известен атакующему, он узнает ваш пароль почти мгновенно.
Читайте также: