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

История

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 хеша и ещё не обновлённых. Оба значения вычислялись по одному механизму, но с использованием разных хешей: LAN Manager и NT LAN Manager , — где первый хеш был значительно слабее второго и не обеспечивал достаточного уровня безопасности. MS-CHAPv2 был представлен в 1998 году вместе с выпуском Windows 98 и Windows NT 4.0 SP4. В 1999 году Брюс Шнайер , и опубликовали исследование безопасности протокола MS-CHAPv2 , в котором указали уязвимости протокола и методы атаки. Microsoft исключила протокол MS-CHAPv1 из использования в Windows Vista в 2007 году. C 2012 года компания Microsoft предупреждает, что использование комбинации протоколов PPTP и MS-CHAPv2 в качестве основного механизма аутентификации для VPN является небезопасным, и рекомендует использовать механизм аутентификации PEAP -MS-CHAPv2 либо использовать VPN-туннели L2TP , IKEv2 , в связке с протоколами MS-CHAPv2 или EAP -MS-CHAPv2.

MS-CHAP v1

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

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

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

MS-CHAP v2

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

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

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

• 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», вычисляется как: ${\displaystyle 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 работает следующим образом :

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

Для 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 байт, идентифицирует тип пакета :
  1. Challenge
  2. Response
  3. Success
  4. Failure

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

Challenge-пакет PPP CHAP

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

Response-пакет

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-пакет

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

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

Failure-пакет

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

• Строка «eeeeeeeeee» является ASCII-представлением десятичного кода ошибки (не обязательно должно быть 10 цифр), соответствующего одному из перечислеyных ниже:
  • 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»

Атака перебором по словарю

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

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

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

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

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

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

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

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

См. также

• CHAP
• PAP
• NTLMv2
• MPPE

Примечания

Источники

• (англ.) .

• (англ.) .
• Moxie Marlinspike. (англ.) . — 2012-06-29. 16 марта 2016 года.
• (англ.) . — 1998.
• (англ.) . — 2000.
• (англ.) . — 1996.
• (англ.) . — 1999.
• (англ.) . — 2007.
• (рус.) . — 2012.