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», вычисляется как:
- 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]:
- Challenge
- Response
- Success
- 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-битной безопасности.
Протокол ослабляет 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