MS-CHAP

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

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

  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 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. Случай успешной аутентификации

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

  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 цифр), соответствующего одному из перечисленных ниже:
    • 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: она позволяет атакующему ускорить перебор по словарю на коэффициент  , что имеет довольно внушительный эффект с учётом относительно низкой энтропии большинства паролей пользователей.

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

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

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

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

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

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, которую можно ожидать от хорошего шифра.

См. также

править

Примечания

править

Источники

править