NTLMv2

В этой статье недостаточно критики, так как необходимо освещение с различных точек зрения. Статью нельзя назвать рекламной, но в ней слабо представлена критика. Пожалуйста, добавьте информацию из публикаций и других источников, позволяющих осветить объект статьи с разных сторон. (18 января 2017)

Возможно, эта статья содержит оригинальное исследование. Проверьте соответствие информации приведённым источникам и удалите или исправьте информацию, являющуюся оригинальным исследованием. В случае необходимости подтвердите информацию авторитетными источниками. В противном случае статья может быть выставлена на удаление. (18 января 2017)

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

Эта статья или раздел содержит незавершённый перевод с английского языка. Вы можете помочь проекту, закончив перевод, см. также рекомендации.

NTLMv2 (NTLM версии 2) — встроенный в операционные системы семейства Microsoft Windows протокол сетевой аутентификации. Широко применяется в различных сервисах на их базе. Изначально был предназначен для повышения безопасности аутентификации путём замены устаревших LM и NTLM v1. NTLMv2 был введён начиная с Windows NT 4.0 SP4 и используется версиями Microsoft Windows вплоть до Windows 10 включительно. С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей.

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

В схеме аутентификации, реализованной при помощи SMB или SMB2 сообщений, вне зависимости от того, какой вид диалекта аутентификации будет использован (LM, LMv2, NTLM, NTLM2, NTLMv2), процесс аутентификации происходит следующим образом:

1. Клиент пытается установить соединение с сервером и посылает запрос, в котором информирует сервер, на каких диалектах он способен произвести аутентификации, например: LM, NTLM, NTLM2, NTLMv2. Следовательно, диалект аутентификации LMv2 между клиентом и сервером исключается.
2. Сервер из полученного от клиента списка диалектов (по умолчанию) выбирает наиболее защищённый диалект (например, NTLMv2), затем отправляет ответ клиенту.
3. Клиент, определившись с диалектом аутентификации, пытается получить доступ к серверу и посылает запрос NEGOTIATE_MESSAGE.
4. Сервер получает запрос от клиента и посылает ему ответ CHALLENGE_MESSAGE, в котором содержится случайная (random) последовательность из 8 байт. Она называется Server Challenge.
5. Клиент, получив от сервера последовательность Server Challenge, при помощи своего пароля производит шифрование этой последовательности, а затем посылает серверу ответ AUTHENTICATE_MESSAGE, который содержит 24 байта.
6. Сервер, получив ответ, производит ту же операцию шифрования последовательности Server Challenge, которую произвёл клиент. Затем, сравнив свои результаты с ответом от клиента, на основании совпадения разрешает или запрещает доступ.

1. Пароль пользователя, в виде OEM-строки, преобразуется в верхний регистр. Например, если пароль «SecREt01», то OEM-строка будет следующей: 0x5345435245543031.
2. Если пароль состоит менее чем из 14 символов, то он дополняется нулями до 14 байт: 0x5345435245543031000000000000.
3. Полученная последовательность из 14 байт делится на две части по 7 байт: 0x53454352455430 и 0x31000000000000.
4. Каждая из частей, состоящая из 7 байт, используется для создания двух DES-ключей, состоящих из 8 байт: 0x52a2516b252a5161 и 0x3180010101010101.
5. Используя алгоритм DES и ASCII-строку «KGS!@#$%», а также сформированные ранее два DES-ключа, вычисляются два hash-значения, каждое по 8 байт: 0xff3750bcc2b22412 и 0xc2265b23734e0dac.
6. Hash-значения из 8 байт объединяются в последовательность из 16 байт, формируя LM-hash: 0xff3750bcc2b22412c2265b23734e0dac.
7. LM-hash из 16 байт дополняется нулями до 21 байта: 0xff3750bcc2b22412c2265b23734e0dac0000000000.
8. Последовательность из 21 байта делится на три части по 7 байт: 0xff3750bcc2b224, 0x12c2265b23734e и 0x0dac0000000000.
9. Каждая из частей используется для создания трёх DES-ключей: 0xfe9bd516cd15c849, 0x136189cbb31acd9d и 0x0dd6010101010101.
10. Используя алгоритм DES и Server Challenge, а также сформированные ранее три DES-ключа, вычисляются три hash-значения, каждое по 8 байт. Например, если Server Challenge был 0x0123456789abcdef, тогда получаются: 0xc337cd5cbd44fc97, 82a667af6d427c6d и e67c20c2d3e77c56.
11. Hash-значения из 8 байт объединяются в последовательность из 24 байт. Эта последовательность и есть LM Response: 0xc337cd5cbd44fc9782a667af6d427c6de67c20c2d3e77c56.

1. Из пароля пользователя в виде строки Unicode, с помощью алгоритма MD4 вычисляется NTLM-hash, состоящий из 16 байт. Например, пароль «SecREt01» или строка Unicode 0x53006500630052004500740030003100 после преобразования с помощью алгоритма MD4 будет иметь вид: 0xcd06ca7c7e10c99b1d33b7485a2ed808.
2. Имя пользователя и имя домена в виде строк Unicode объединяются и приводятся к верхнему регистру. Далее из этой последовательности и ранее полученного NTLM-hash с помощью алгоритма HMAC-MD5 вычисляется NTLMv2-hash, состоящий из 16 байт. Например, имя пользователя «User» и имя домена «Domain» дадут строку «USERDOMAIN» или строку Unicode 0x550053004500520044004f004d00410049004e00. После алгоритма HMAC-MD5, где используется NTLM-hash, вычисляется NTLMv2-hash: 0x04b8e0ba74289cc540826bab1dee63ae.
3. Формируется случайная последовательность Client Challenge из 8 байт, например: 0xffffff0011223344.
4. Server Challenge и Client Challenge объединяются в последовательность из 16 байт. Например, если Server Challenge был 0x0123456789abcdef, тогда получаем: 0x0123456789abcdefffffff0011223344.
5. Из последовательности Server Challenge и Client Challenge и ранее вычисленного NTLMv2-hash с помощью алгоритма HMAC-MD5 вычисляется хеш-значение, состоящее из 16 байт: 0xd6e6152ea25d03b7c6ba6629c2d6aaf0.
6. Хеш-значение объединяется с Client Challenge в последовательность из 24 байт. Эта последовательность и есть LMv2 Response: 0xd6e6152ea25d03b7c6ba6629c2d6aaf0ffffff0011223344.

1. Из пароля пользователя в виде строки Unicode, при помощи алгоритма MD4, вычисляется NTLM-hash, состоящий из 16 байт. Например, пароль «SecREt01» или строка Unicode 0x53006500630052004500740030003100 после преобразования посредством алгоритма MD4, будет иметь вид: 0xcd06ca7c7e10c99b1d33b7485a2ed808.
2. NTLM-hash из 16 байт дополняется нулями до 21 байта: 0xcd06ca7c7e10c99b1d33b7485a2ed8080000000000.
3. Последовательность из 21 байта делится на три части по 7 байт. 0xcd06ca7c7e10c9, 0x9b1d33b7485a2e и 0xd8080000000000.
4. Каждая из частей, состоящая из 7 байт, используется для создания трёх DES-ключей, состоящих из 8 байт: 0xcd83b34fc7f14392, 0x9b8f4c767543685d и 0xd904010101010101.
5. Используя алгоритм DES и Server Challenge, а также сформированные ранее три DES-ключа, вычисляются три hash-значения, каждое по 8 байт. Например, если Server Challenge был 0x0123456789abcdef, тогда получается: 0x25a98c1c31e81847, 0x466b29b2df4680f3 и 0x9958fb8c213a9cc6.
6. Hash-значения из 8 байт объединяются в последовательность из 24 байт. Эта последовательность и есть NTLM Response: 0x25a98c1c31e81847466b29b2df4680f39958fb8c213a9cc6.

1. Формируется последовательность Client Challenge длиной 8 байт, выбранных случайным образом, например: 0xffffff0011223344. Эта последовательность дополняется нулями до 21 байта, чтобы получить LMv2 Response: 0xffffff001122334400000000000000000000000000000000.
2. Затем Server Challenge и Client Challenge объединяются в последовательность из 16 байт. Если Server Challenge был 0x0123456789abcdef, то получается: 0x0123456789abcdefffffff0011223344.
3. Из полученной последовательности при помощи алгоритма MD5 вычисляется следующее hash-значение, состоящее из 16 байт: 0xbeac9a1bc5a9867c15192b3105d5beb1.
4. Из пароля пользователя в виде Unicode строки, при помощи алгоритма MD4, вычисляется NTLM-hash, состоящий из 16 байт. Например, пароль «SecREt01» или Unicode строка 0x53006500630052004500740030003100 после преобразования посредством алгоритма MD4 будет иметь вид: 0xcd06ca7c7e10c99b1d33b7485a2ed808.
5. NTLM-hash из 16 байт дополняется нулями до 21 байта: 0xcd06ca7c7e10c99b1d33b7485a2ed8080000000000.
6. Последовательность из 21 байта делится на три части по 7 байт: 0xcd06ca7c7e10c9, 0x9b1d33b7485a2e и 0xd8080000000000.
7. Каждая из частей, состоящая из 7 байт, используется для создания трёх DES-ключей, состоящих из 8 байт: 0xcd83b34fc7f14392, 0x9b8f4c767543685d и 0xd904010101010101.
8. Используя алгоритм DES и отсечённую часть hash-значения, а также сформированные ранее три DES-ключа, вычисляются три hash-значения, каждое по 8 байт. Например, если Server Challenge был 0x0123456789abcdef, тогда получается: 0x10d550832d12b2cc, 0xb79d5ad1f4eed3df и 0x82aca4c3681dd455.
9. Нash-значения из 8 байт объединяются в последовательность из 24 байт. Эта последовательность и есть NTLM2 Response: 0x10d550832d12b2ccb79d5ad1f4eed3df82aca4c3681dd455.

1. Из пароля пользователя в виде Unicode строки при помощи алгоритма MD4 вычисляется NTLM-hash, состоящий из 16 байт. Например, пароль «SecREt01» или Unicode строка 0x53006500630052004500740030003100 после преобразования посредством алгоритма MD4 будет иметь вид: 0xcd06ca7c7e10c99b1d33b7485a2ed808.
2. Имя пользователя и имя домена в виде Unicode строк объединяются и приводятся к верхнему регистру. Далее, из этой последовательности и ранее полученного NTLM-hash при помощи алгоритма HMAC-MD5 вычисляется NTLMv2-hash, состоящий из 16 байт. Например, имя пользователя «User» и имя домена «Domain» дадут строку «USERDOMAIN» или Unicode строку 0x550053004500520044004f004d00410049004e00. После алгоритма HMAC-MD5, где применяется NTLM-hash, вычисляется NTLMv2-hash: 0x04b8e0ba74289cc540826bab1dee63ae.
3. Формируется последовательность Client Challenge из 8 байт, выбранных случайным образом (random), например: 0xffffff0011223344.
4. Формируется blob, например: 0x01010000 — the blob signature, 0x00000000 — reserved value, 0x0090d336b734c301 — timestamp, 0xffffff0011223344 — a random Client challenge, 0x00000000 — unknown, 0x02000c0044004f004d00410049004e0001000c005300450052005600450052000400140064006f006d00610069006e002e0063006f006d00030022007300650072007600650072002e0064006f006d00610069006e002e0063006f006d0000000000 — target information block, 0x00000000 — unknown.
5. Server Challenge и blob объединяются в последовательность, из которой при помощи алгоритма HMAC-MD5 и ранее вычисленного NTLMv2-hash вычисляется hash-значение, состоящие из 16 байт. Например, если Server Challenge был 0x0123456789abcdef, тогда получается следующая последовательность: 0x0123456789abcdef01010000000000000090d336b734c301ffffff00112233440000000002000c0044004f004d00410049004e0001000c005300450052005600450052000400140064006f006d00610069006e002e0063006f006d00030022007300650072007600650072002e0064006f006d00610069006e002e0063006f006d000000000000000000. После использования алгоритма HMAC-MD5 получается следующее hash-значение: 0xcbabbca713eb795d04c97abc01ee4983.
6. Нash-значения из 16 байт объединяются с blob в последовательность. Эта последовательность и есть NTLMv2 Response: 0xcbabbca713eb795d04c97abc01ee498301010000000000000090d336b734c301ffffff00112233440000000002000c0044004f004d00410049004e0001000c005300450052005600450052000400140064006f006d00610069006e002e0063006f006d00030022007300650072007600650072002e0064006f006d00610069006e002e0063006f006d000000000000000000.
7. Этот текст был написан с использованием языка программирования Python и библиотеки cryptography. Он был тщательно проверен и отполирован профессиональными разработчиками программного обеспечения.

Прослушивая сетевой трафик, можно перехватить SMB пакеты аутентификации, тем самым завладев последовательностью Server Challenge и ответом Response от клиента. Имея эти два параметра, несмотря на способ аутентификации (даже при NTLMv2), возможно, при помощи современного программного обеспечения (при условии не сложного пароля, допустим: «12345») в течение нескольких часов подобрать пароль клиента. Но если способом аутентификации является NTLMv2 и пароль клиента содержит прописные, заглавные, строчные буквы, цифры, а также специальные символы, то на взлом такого пароля могут уйти многие годы.

1. Вывести из строя сервер, к которому клиент желает получить доступ. Для этого можно воспользоваться самой примитивной DDoS-атакой.
2. Назначить компьютеру, с которого будет произведена атака, все параметры сервера, то есть имя сервера, IP-адрес сервера и MAC-адрес сервера. Это необходимо для того, чтобы клиент, обращаясь к серверу, произвел попытку подключения к компьютеру, с которого будет произведена атака.
3. На запрос клиента о выборе диалекта аутентификации, компьютер, с которого будет произведена атака, должен будет выбрать самый небезопасный диалект, а именно LM (или более защищённый NTLM). В результате чего компьютер, с которого проводилась атака, получит LM Response (ответ). Злоумышленник, имея последовательность Server Challenge и LM Response, время взлома пароля прямым перебором (Bruteforce атака) займёт всего несколько часов.

Этот способ мало чем отличается от подмены сервера. Сервер, при помощи специального программного обеспечения или изменения настроек локальной политики безопасности, выбирает наиболее незащищённый вид диалекта аутентификации.

При выборе пароля клиент должен руководствоваться следующими правилами:

• Пароль должен содержать как можно больше символов;
• Пароль должен содержать буквы, цифры и другие символы;
• Пароли для всех важных аккаунтов должны быть уникальные.

• SMB
• LM-хеш
• NTLM

• [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol Архивная копия от 18 января 2017 на Wayback Machine / Microsoft, 2007—2016
• https://www.owasp.org/images/3/37/OWASP-IL-2014-01_nhastie-presentation.pdf
• https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-grutzmacher.pdf Архивная копия от 13 марта 2013 на Wayback Machine
• https://www.blackhat.com/presentations/bh-asia-04/bh-jp-04-pdfs/bh-jp-04-seki.pdf Архивная копия от 18 октября 2016 на Wayback Machine