MS-CHAP

Алгоритм работы протокола MS-CHAPv2. Случай успешной аутентификации

Механизм работы протокола 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», вычисляется как: ${\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-пакет.

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

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

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 байт.

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

Форматы пакетов, передаваемых в протоколе MS-CHAPv2. Общий вид, Challenge-пакет, Response-пакет, Success-пакет и Failure-пакет.

• Поле 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 цифр), соответствующего одному из перечисле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> — читаемый человеком текст в соответствующей кодировке.

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

Процедура получения «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 ключей[9]

Алгоритм генерации «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-битной безопасности.

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

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