PROFILBARU.COM

MS-CHAP (англ. Microsoft Challenge Handshake Authentication Protocol) — протокол проверки подлинности соединений между сервером и клиентом без передачи пароля последнего, использующий механизм «вызов-ответ». MS-CHAP является реализацией протокола CHAP, в которой предусмотрены механизм возврата сообщений об ошибках аутентификации и возможность изменения пароля пользователя.^[1]^[2] Кроме того MS-CHAP обеспечивает создание ключей шифрования для протокола MPPE, совместно с которым применяется в Microsoft PPTP^[2]^[3].

История

MS-CHAP является версией протокола CHAP, разработанной компанией Microsoft в 1997 году для Windows 3.1 и Windows 95. Затем MS-CHAP был переименован в MS-CHAPv1 и заменён MS-CHAPv2 из-за недостатков безопасности протокола, основным из которых была отправка клиентом ответа, содержащего две величины: «LAN Manager Challenge Responce» и «NT Challenge Responce», — что делалось для поддержания хранимых на сервере учётных записей пользователей, созданных до появления Windows NT хеша и ещё не обновлённых.^[1] Оба значения вычислялись по одному механизму, но с использованием разных хешей: LAN Manager и NT LAN Manager, — где первый хеш был значительно слабее второго и не обеспечивал достаточного уровня безопасности. MS-CHAPv2 был представлен в 1998 году вместе с выпуском Windows 98 и Windows NT4.0 SP4. В 1999 году Брюс Шнайер , Дэвид Вагнер и Пейтер Затко опубликовали исследование безопасности протокола MS-CHAPv2^[3], в котором указали уязвимости протокола и методы атаки. Microsoft исключила протокол MS-CHAPv1 из использования в Windows Vista в 2007 году.^[4] C 2012 года компания Microsoft предупреждает, что использование комбинации протоколов PPTP и MS-CHAPv2 в качестве основного механизма аутентификации для VPN является небезопасным, и рекомендует использовать механизм аутентификации PEAP-MS-CHAPv2 либо использовать VPN-туннели L2TP, IKEv2, SSTP в связке с протоколами MS-CHAPv2 или EAP-MS-CHAPv2.^[5]

MS-CHAP v1

MS-CHAPv1 представляет собой механизм аутентификации, похожий на CHAP, но имеющий важное отличие: в CHAP сервер должен хранить в обратимо-зашифрованном виде пароль клиента, который расшифровывается при каждой проверке подлинности клиента, а в MS-CHAP v1 серверу для этого требуется только MD4-хеш пароля.^[6]

Механизм MS-CHAPv1 состоит из следующих этапов^[6]^[3]:

Клиент отправляет серверу запрос на вход.
Сервер в ответ отправляет 8-байтовый случайный отклик(Challenge).
Клиент использует LAN Manager хеш своего пароля, добавляет к 16-байтовому результату пять нулевых байт и делит полученную 21-байтовую строку на три части по 7 байт, чтобы получить три ключа для DES. Каждый из этих ключей используется для шифрования Challenge, присланного сервером. Все три результирующих шифрованных блока объединяются в 24-байтовый LMChallengeResponse. Также клиент создаёт второй 24-байтовый NTChallengeResponse, используя Windows NT хеш и ту же процедуру. Затем оба значения, LMChallengeResponse и NTChallengeResponse, а также флаг «Использовать NTChallengeResponse» размером в 1 байт отправляются серверу.
Сервер использует для расшифровки полученного ответа соответствующий флагу хеш клиентского пароля, который хранится в базе данных. Если расшифрованные блоки соответствуют значению Challenge, аутентификация завершается, и клиенту отсылается Success-пакет.

MS-CHAP v2

MS-CHAP v2 устраняет некоторые недостатки MS-CHAP v1, как показано в следующей таблице.^[7]

Проблема протокола MS-CHAP версии 1	Решение протокола MS-CHAP версии 2
Шифрование ответа LAN Manager, применяемое для обратной совместимости со старыми клиентами удаленного доступа Microsoft, криптографически уязвимо.	MS-CHAP v2 больше не разрешает использовать шифрованные ответы LAN Manager, поскольку LAN Manager хеш является гораздо более слабой хеш-функцией и может быть взломан, а затем использован для взлома Windows NT хеша. Таким образом, исключив LAN Manager хеш в MS-CHAPv2, Microsoft сделала невозможной атаку методом «разделяй и властвуй» ^[3].
Шифрование изменения пароля LAN Manager криптографически уязвимо.	MS-CHAP v2 больше не разрешает использовать шифрованные изменения пароля LAN Manager.
Возможна только односторонняя проверка подлинности. Клиент удаленного доступа не может проверить, подключается ли он к серверу удаленного доступа своей организации или к маскирующемуся серверу.	MS-CHAP v2 обеспечивает двустороннюю проверку подлинности, называемую также взаимной проверкой подлинности. Клиент удаленного доступа получает подтверждение, что сервер удаленного доступа, к которому он пытается подключиться, имеет доступ к паролю пользователя.
При использовании 40-битного шифрования ключ шифрования основан на пароле пользователя. Всякий раз, когда пользователь подключается с одним и тем же паролем, создается один и тот же ключ шифрования.	В MS-CHAP v2 ключ шифрования всегда основан на пароле пользователя и произвольной строке запроса. Каждый раз, когда пользователь подключается с одним и тем же паролем, создаются разные ключи шифрования.
Для данных, пересылаемых по подключению в обоих направлениях, используется единый ключ шифрования.	При использовании протокола MS-CHAP v2 создаются отдельные ключи шифрования для приёма и передачи данных.

Алгоритм аутентификации

Механизм работы протокола MS-CHAPv2^[2]^[3]:

1. Клиент отправляет серверу запрос на аутентификацию, открыто передавая свой логин.
2. Сервер отправляет обратно 16-байтовый случайный отклик «Authenticator Challenge».
3а. Клиент создаёт 16-байтовое случайное число, называемое «Peer Authenticator Challenge».
3b. Клиент конкатенирует «Peer Authenticator Challenge» с «Authenticator Challenge», полученным от сервера, и с «UserName» клиента, а затем хеширует результат с помощью SHA-1. Первые восемь байт этого хеша называются «Challenge Hash».
3c. 16-байтовый NT-хеш пароля клиента дополняется до 21 байта присоединением пяти нулевых байт. Пусть X, Y, Z будут тремя последовательными 7-байтовыми блоками этого 21-байтового значения, и пусть значение СH равно «Challenge Hash». Ответ CR длиной 24 байта, называемый «Challenge Response», вычисляется как: $CR=DES_{x}\left(CH\right)||DES_{y}\left(CH\right)||DES_{z}\left(CH\right)$
3d. Клиент отправляет на сервер «Challenge Response», «Peer Authenticator Challenge» и «UserName».
4а. Сервер, получив ответ клиента, расшифровывает «Challenge Response» и сравнивает полученный NT-хеш клиента со своим. Если значения совпадают, то подлинность клиента подтверждается. Затем сервер хеширует 16-байтовый NT-хеш пароля, чтобы получить хеш-хеша пароля. (Сервер хранит пароль клиентов хешированным с помощью MD4; это и является NT- хешем пароля)
4b. Сервер конкатенирует хеш-хеша пароля, 24-байтовый «Challenge Response» и символьную строку «Magic server to client constant», а потом хеширует результат с помощью SHA-1.
4c. Сервер конкатенирует 20-байтовый выход SHA-1 со стадии (4b), начальные 8 байт сгенерированного клиентом «Peer Authenticator Challenge» и символьную строку «Pad to make it do more than one iteration», а затем хеширует результат с помощью SHA-1.
4d. Полученные на стадии 20 байт являются «Authenticator Response» и отправляются клиенту в Success-пакете.
5. Клиент также вычисляет «Authenticator Response» и сверяет с «Authenticator Response», полученным от сервера. Если значения совпадают, то подлинность сервера подтверждается и клиент отправляет серверу Success-пакет.

Получение ключей для MPPE

MS-CHAPv2 является протоколом аутентификации в протоколе Microsoft PPTP, в котором протоколом шифрования служит MPPE. MPPE требует использования ключей шифрования длиной 40 бит или 128 бит, генерируемых процессе проверки подлинности в MS-CHAPv2.

Получение ключей MPPE из учётных данных MS-CHAPv2 работает следующим образом^[3]:

С помощью SHA-1 хешируется 16-байтовый NT-хеш пароля, 24-байтовый «Challenge Response» из обмена MSCHAPv2, а также 27-байтовая строка «This is the MPPE Master Key». Затем результат обрезается, чтобы получить 16-байтовый мастер-ключ.
Используя детерминированный процесс, мастер-ключ конвертируется в пару сеансовых ключей.

Для 40-битных сеансовых ключей в пункте (2) выполняется следующее:

С помощью SHA-1 хешируются мастер-ключ, 40 байт 0x00, 84-байтовая «магическая» константа и 40 байт 0xF2. Результат обрезается до 8 байт.
Старшие 24 бита устанавливаются в значение 0xD1269E, в результате чего получается 40-битный ключ (с 24-битным префиксом, то есть на самом деле RC4, используемый в MPPE, получает 64-битный ключ)

Для 128-битных сеансовых ключей процесс в пункте (2) выглядит следующим образом:

С помощью SHA-1 хешируются мастер-ключ, 40 байт 0x00, 84-байтовая «магическая» константа и 40 байт 0xF2. Результат обрезается до 16 байт.

«Магические» константы различны в зависимости от того, в каком направлении используется ключ — для шифрования трафика от клиента к серверу или от сервера к клиенту.

Формат пакетов

Поле Code, имеющее размер 1 байт, идентифицирует тип пакета^[8]:
1. Challenge
2. Response
3. Success
4. Failure

Поле Identifier размером в 1 байт служит для согласования запросов и ответов.
Поле Length — это два байта, указывающих длину MS-CHAP пакета, включая Code, Identifier, Length и Data.
Поле Data состоит из нуля или более октетов. Формат поля данных определяется полем Code.

Challenge-пакет PPP CHAP^[2]

Поле Identifier должно изменяться каждый раз, когда посылается Challenge-пакет.
Value-Size — 1 байт, указывающий длину поля Value.
Value в содержит 16-байтовый «Authenticator Challenge».
Поле Name пусто.

Response-пакет ^[2]

Response-пакет имеет ту же структуру, что и Challenge-пакет.

Identifier в Response-пакете должен быть скопирован из поля Identifier Challenge-пакета, вызвавшего этот Response.
Поле Value в Response-пакете MS-CHAP-V2 содержит:
- 16 байт: «Peer Authenticator Challenge»
- 8 байт: зарезервированы и должны быть нулями
- 24 байта: «Challenge Response»
- 1 байт : не используется и должен быть нулём
Поле Name является строкой из 0-256 чувствительных к регистру ASCII символов, содержащей «UserName» клиента.

Success-пакет ^[2]

Поле Message содержит строку 42-байтового ответа. Формат поля Message: S=<auth_string> M=<message>

Величина <auth_string> является 20-байтовым «Authenticator Response» закодированным в ASCII как 40 шестнадцатеричных цифр. Шестнадцатеричные цифры A-F (если имеются) должны быть в верхнем регистре.
Величина <message> — читаемый человеком текст в соответствующей кодировке.

Failure-пакет ^[2]

Failure-пакет имеет ту же структуру, что и Success-пакет. Однако, в поле Message хранится форматированный текст, который, вопреки стандартным правилам CHAP, влияет на работу протокола. Формат поля Message: E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<msg>

Строка «eeeeeeeeee» является ASCII-представлением десятичного кода ошибки (не обязательно должно быть 10 цифр), соответствующего одному из перечисленных ниже:
- 646 ERROR_RESTRICTED_LOGON_HOURS
- 647 ERROR_ACCT_DISABLED
- 648 ERROR_PASSWD_EXPIRED
- 649 ERROR_NO_DIALIN_PERMISSION
- 691 ERROR_AUTHENTICATION_FAILURE
- 709 ERROR_CHANGING_PASSWORD

Величина «r» является ASCII флагом равным 1, если повторная попытка разрешена, и 0, если нет.

Величина «cccccccccccccccccccccccccccccccc» является ASCII-представлением шестнадцатеричного значения вызова. Это поле должно присутствовать и должно иметь длину ровно 32 байта.
Величина «vvvvvvvvvv» является ASCII-представлением десятичной версии кода (не обязательно должно быть 10 цифр), указывающей версию протокола смены пароля, поддерживаемого на сервере. Для MS-CHAPv2, это значение всегда должно быть 3.
Величина <msg> — читаемый человеком текст в соответствующей кодировке.

Криптоанализ и атаки

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

Анализ генерации «Challenge Response»

Атака перебором по словарю ^[3]

Процедура получения «Challenge Response» создает серьезную слабость в протоколах MS-CHAP: она позволяет атакующему ускорить перебор по словарю на коэффициент $2^{16}$ , что имеет довольно внушительный эффект с учётом относительно низкой энтропии большинства паролей пользователей.

«Authenticator Challenge», «Peer Authenticator Challenge» и «UserName» предоставляются в открытом виде и их можно подслушать, а значит «Challenge Hash» может быть легко получен из общедоступной информации. Велика вероятность восстановить пароль, основываясь на том, что многие пароли образованы из слов словаря или иным образом легко угадываемы. Величина Z (определённая на стадии (3с)) может быть легко восстановлена. Поскольку существует только $2^{16}$ возможных вариантов Z (так как для каждого из первых двух байт в Z существует $2^{8}$ вариантов значений), и известна пара открытый текст («Challenge Hash») — шифротекст (DESz(«Challenge Hash»)), то возможно перебрать каждый из вариантов для Z, что раскроет последние два байта NT-хеша пароля.

Для перебора по словарю выполняется предвычисление: хешируется каждый вероятный пароль. Результаты хеширования сортируются по двум последним байтам, а затем, когда виден обмен MS-CHAP и можно восстановить последние два байта NT-хеша (с использованием описанного выше метода), отбираются все подходящие записи из списка хешей. Это предоставляет атакующему набор вероятных паролей, которые дают нужное значение для последних двух байтов их NT-хеша. Далее каждый из этих вариантов проверяется методом грубой силы: вычисляется его «Challenge Response» и сверяется с подслушанным значением.

Таким образом, предложенная выше оптимизированная атака работает около $2^{16}$ раз быстрее, чем стандартная атака перебора по словарю, где проверяются все пароли. Она применима как к MS-CHAPv1 так и к MS-CHAPv2. Тем не менее, такая уязвимость гораздо важнее для MS-CHAPv2, потому что в случае MSCHAPv1 легче атаковать LanManager-хеш, чем NT-хеш.

Атака полным перебором DES ключей^[9]

Алгоритм генерации «Challenge Response» является слабым звеном, даже когда пароли содержат достаточную энтропию. NT-хеш может быть восстановлен с помощью подбора двух байт третьего DES ключа, что требует $2^{16}$ вычислений, и двух полных переборов для первого и второго DES ключей. Каждый DES ключ имеет 56 бит, но чтобы не перебирать $2^{56}+2^{56}=2^{57}$ вариантов для первых двух ключей, можно использовать факт, что обе DES-операции шифруют один и тот же «Challenge Hash» разными ключами. Поэтому достаточно проделать лишь $2^{56}$ операции шифрования:

desKeyX = null;
desKeyY = null;
for (long i=0; i<2^56; i++) {
	result = DES(key[i], plaintext);

	if (result == ciphertext1) {
		desKeyX = result;
	} else if (result == ciphertext2) {
		desKeyY = result;
	}
}

После того, как NT-хеш восстанавливается, все шифрованные сеансы могут быть прочитаны и схема аутентификации может быть взломана без каких-либо усилий. Это показывает, что даже при использовании 128-битных ключей RC4 для MPPE, протокол MS-CHAP обеспечивает лишь эквивалент 56-битной безопасности.

Анализ генерации ключей для MPPE^[3]

Протокол ослабляет 40-битные MPPE ключи, устанавливая в старшие 24 бита 64-битного RC4 ключа значение 0xD1269E. Известно, что, если кто-либо имеет право выбирать старшие биты ключа RC4, то он может навязать пользователю слабый класс ключей для RC4. Поэтому, если разработчики MS-CHAP хотели встроить лазейку в протоколе, они могли использовать наличие префикса для ослабления RC4.

В статистических испытаниях было обнаружено, что для ключей, которые начинаются с 0xD1269E, первый и второй байты на выходе RC4 принимают значения 0x09 и 0x00 с вероятностью 0,0054 и 0,0060 соответственно, что заметно больше, чем вероятность 1/256 = 0,0039, которую можно ожидать от хорошего шифра.

См. также

Примечания

Источники

MS-CHAP v1 (англ.).

MS-CHAP v2 (англ.).
Moxie Marlinspike. Cracking MS-CHAPv2 with a 100% success rate (англ.). — 2012-06-29. Архивировано 16 марта 2016 года.
RFC 2433 (англ.). — 1998.
RFC 2759 (англ.). — 2000.
PPP Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1996.
Cryptanalysis of Microsoft’s PPTP Authentication Extensions (англ.). — 1999.
The MS-CHAP version 1 authentication protocol has been deprecated in Windows Vista (англ.). — 2007.
Советы по безопасности (Microsoft) 2743314 (рус.). — 2012.
Разделяй и властвуй: гарантированный взлом MS-CHAPv2

[_0c53e5318dbd6887-1] ¹ ² RFC 2433, 1998.

[_72fcbe412363475d-2] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ RFC 2759, 2000.

[_81b6b7a0b983d34f-3] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ Cryptanalysis of MS-CHAP, 1999.

[_83b335227ea3abe9-4] Deprecated MS-CHAPv1, 2007.

[_0db7393488a792e4-5] Советы по безопасности Microsoft, 2012.

[_d16ede708dcab16b-6] ¹ ² MS-CHAP v1.

[_dcfdef7e7fa61916-7] MS-CHAP v2.

[_ecc60740889e445c-8] PPP CHAP, 1996.

[_6ba4216d843d0312-9] Moxie Marlinspike, 2012-06-29.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

MS-CHAP