Оглавление

1. Видимость и хранение паролей
2. Анализ безопасности PAP
3. Хранение паролей при CHAP и MS-CHAP
4. Состоянии передачи (in transit): User-Password против CHAP-Password
5. 8.7.4. Выводы: PAP против CHAP 
6. MS-CHAP

Видимость и хранение паролей
Секретные или чувствительные данные (Sensitive data), например, пароли, могут находится в трех состояниях - в состоянии хранения (at rest), состоянии передачи (in transit) и в обработке (in work). Примеры: в состоянии хранения - в базе данных, в состоянии передачи - передача по сети, в обработке - в оперативной памяти в приложении.

Атакующий может сосредоточиться на взломе базы данных, в которой хранятся учетные данные пользователей, такие как имена учетных записей и пароли. На момент написания статьи некоторые источники заявляют о наличии записей более чем по двенадцати миллиардам скомпрометированных учетных записей. Базы пользователей, следовательно, являются крайне привлекательными целями.

Атака, обсуждаемая в этом разделе, зависит от уязвимостей в базе учетных данных и не предполагает, что атакующий может видеть или модифицировать трафик RADIUS. В результате поднятые здесь вопросы в равной степени применимы при использовании TTLS, PEAP или RADIUS/TLS. Успех атаки зависит только от того, как учетные данные хранятся в базе. Поскольку выбор метода аутентификации влияет на способ хранения учетных данных в базе, безопасность этой зависимости необходимо обсудить и объяснить.

Некоторые организации могут захотеть повысить безопасность своей сети, избегая PAP и используя вместо него CHAP или MS-CHAP. Эти попытки ошибочны. Если необходимо применять простые методы на основе пароля, то почти во всех ситуациях безопасность сети в целом повышается при использовании PAP вместо CHAP или MS-CHAP. Причина ясна из простого анализа рисков, который более подробно приведен ниже.

Анализ безопасности PAP
Когда используется PAP, сервер RADIUS видит пароль пользователя в открытом виде и сравнивает его с учетными данными, сохраненными в базе пользователей. Учетные данные в базе обычно захешированы. Сервер RADIUS берет открытый пароль пользователя, применяет ту же хеш-функцию и затем сравнивает два хеша от паролей.

Любое компрометирование сервера RADIUS приведет к утечке этого открытого пароля. Однако в большинстве случаев открытый пароль доступен только в памяти приложения сервера RADIUS (то есть в состоянии обработки, а не в состоянии хранения или передачи) и лишь в течение короткого времени. Атакующему, желающему получить пароли всех пользователей, пришлось бы ждать, пока все пользователи войдут в систему, что может занять значительное время. За это время администратор может обнаружить утечку и устранить проблему.

При использовании PAP учетные данные в базе надежно хранятся «at rest», при условии, что администратор сохраняет только хешированные учетные данные. Любое компрометирование базы приводит к раскрытию минимального объема информации для атакующего. То есть атакующий не может легко получить открытые пароли из скомпрометированной базы.

В результате пароли пользователей видны в открытом виде лишь непродолжительное время и только на сервере RADIUS. Безопасность этой системы, например, не так хороша, как у EAP-PWD [RFC5931], но и не катастрофическая.

Хотя метод обфускации, используемый для атрибута User-Password, и не признан небезопасным, также не было доказано, что он безопасный. Обфускация зависит от вычисления MD5(secret + Request Authenticator), что дает атакующему несколько полезных свойств. Стоимость перебора коротких общих секретов невелика. Даже для более длинных секретов, сгенерированных человеком, внутреннее состояние MD5 для хеширования секрета может быть предвычислено и сохранено на диске. Этот процесс относительно недорог, даже для миллиардов возможных общих секретов. Затем к каждому предвычисленному состоянию может быть добавлен Request Authenticator методом перебора и результат сравнен с обфусцированными данными User-Password.

Дайджест MD5 имеет длину 16 октетов, и многие пароли короче этого. Это означает, что конечные октеты дайджеста помещаются в атрибут User-Password без изменений. В результате атаке перебором не нужно декодировать User-Password и проверять, «выглядит ли» декодированный пароль разумно. Вместо этого атакующему достаточно сравнить последние октеты вычисленного дайджеста с последними октетами атрибута User-Password. Это дает сигнал, который с высокой вероятностью указывает на правильность угаданного секрета.

Единственная защита от этой атаки — обеспечить, чтобы общий секрет был длинным и получен из криптографически стойкого генератора псевдослучайных чисел.

Хранение паролей при CHAP и MS-CHAP
В отличие от PAP, при использовании CHAP или MS-CHAP эти методы не раскрывают серверу RADIUS пароль в открытом виде, а передают его хеш-преобразование. Теоретически такой хеш безопасен, даже если атакующий может его наблюдать. Хотя CHAP по-прежнему считается безопасным, MS-CHAP — нет, как отмечено в разделе [MS-CHAP]. В рамках этого раздела мы сосредоточимся на конструкции «хешированных паролей» и проигнорируем любые атаки, специфичные для MS-CHAP. Отметим также, что EAP-MD5 [RFC3748], раздел 5.4, по сути то же, что CHAP, и имеет тот же анализ безопасности.

Хеш-преобразования для CHAP и MS-CHAP зависят от случайного вызова. Намерение состояло в повышении безопасности, однако их конструкция накладывает строгие требования на форму, в которой хранятся пользовательские учетные данные.

Процесс выполнения CHAP и MS-CHAP инвертирован относительно процесса в PAP. Используя схожую терминологию для иллюстрации, «хешированные» пароли передаются в методе CHAP и отправляются на сервер. Сервер должен получить из базы данных пароль в открытом виде (или NT-хешированный) и затем выполнить хеш-операцию над паролем из базы. Затем два хешированных значения сравниваются, как это делается в PAP. Такая инверсия процесса существенно снижает безопасность системы.

При использовании CHAP или MS-CHAP все учетные данные всё время хранятся в базе в открытом виде (или в эквиваленте открытого вида). Даже если содержимое базы зашифровано, ключи расшифрования неизбежно доступны приложению, которое читает эту базу. Любое компрометирование приложения означает, что вся база может быть немедленно прочитана и целиком доступна. Атакующий получает полный доступ ко всем идентификаторам пользователей и ко всем связанным с ними паролям в открытом виде.

Очевидно, что получение атакующим всех паролей в открытом виде — гораздо хуже, чем получение тех же паролей в хешированном-виде. Аналогично, безопаснее, когда сервер RADIUS имеет доступ к некоторым паролям в открытом виде лишь время от времени, чем когда он постоянно имеет доступ ко всем паролям в открытом виде.

Состоянии передачи (in transit): User-Password против CHAP-Password
Существует еще один миф о безопасности PAP по сравнению с CHAP. Распространено мнение, что CHAP безопаснее, потому что при PAP пароли отправляются «в открытом виде» через атрибут User-Password. Это неверно.

Атрибут User-Password маскируется (обфусцируется), когда он отправляется в пакете Access-Request, с использованием MD5 с ключом и общего секрета, как определено в [RFC2865], раздел 5.2. На момент написания не найдено атаки лучше перебора, которая позволяла бы атакующему обратить эту обфускацию.

Иногда заявляют, что предпочтительнее использовать CHAP-Password, поскольку он «не отправляет пароль в открытом виде». Это предпочтение основано на неправильном понимании того, как рассчитываются атрибуты CHAP-Password и User-Password.

Атрибут CHAP-Password зависит от хеша видимого Request Authenticator (или CHAP-Challenge) и пароля пользователя. Обфусцированный User-Password зависит от того же Request Authenticator и общего секрета RADIUS. С точки зрения атакующего разница между двумя вычислениями минимальна. Обе конструкции атакуются с сопоставимыми усилиями, поскольку используют схожие принципы. Поэтому любой анализ безопасности, утверждающий, что «User-Password небезопасен, потому что использует MD5», игнорирует тот факт, что атрибут CHAP-Password построен примерно тем же методом.

Атакующий, который может наблюдать CHAP-Password и CHAP-Challenge, также может проводить офлайн-атаку по словарю над наблюдаемыми значениями. Сложность взлома CHAP-Password сопоставима со взломом пакетов RADIUS. Разница между двумя атаками состоит в том, что общие секреты, как правило, надежнее, чем пароли конечных пользователей.

Атакующий, взломавший пароль одного пользователя, может получить сетевой доступ от имени этого пользователя или даже административный доступ к сетевым устройствам. В то время как атакующий, взломавший общий секрет, может получить сетевой доступ от имени любого пользователя и выполнять любую авторизацию. В итоге взламывать общие секреты ценнее, даже если базовый процесс атаки по сути одинаков.

8.7.4. Выводы: PAP против CHAP
Тщательный анализ безопасности показывает, что для всех PAP, CHAP и MS-CHAP сервер RADIUS в какой-то момент должен иметь доступ к версии пароля в открытом виде. В результате при компрометации сервера RADIUS существует минимальная разница в уровне риска между различными методами аутентификации.

Однако при использовании PAP учетные данные пользователей могут безопасно храниться «at rest» в базе данных, тогда как такое безопасное хранение невозможно с CHAP и MS-CHAP. Следовательно, существует существенная разница в уровне риска между методами аутентификации, при этом PAP обеспечивает значительно более высокую безопасность благодаря возможности безопасного хранения паролей «at rest» в хешированном формате.

Напротив, CHAP крайне небезопасен, так как любая компрометация базы приводит к немедленному раскрытию паролей в открытом виде для всех пользователей. Безопасность MS-CHAP лучше всего охарактеризовать как близкую к нулю, независимо от компрометации базы. Это делает MS-CHAP худшим из всех возможных вариантов.

Эта разница в безопасности проявляется также в атаках на системы RADIUS [EXPLOIT], где атакующие выявили уязвимую систему RADIUS, а затем:

• использовали SQL-команды для выгрузки учетных данных [T1555], включавших как пароли в открытом виде, так и хешированные пароли для пользовательских и административных аккаунтов.
  

Затем атака использовала эти пароли для получения больших привилегий:

• «Получив учетные данные с сервера RADIUS, киберакторы применяли эти учетные данные с помощью собственных автоматизированных скриптов для аутентификации на маршрутизаторе по Secure Shell (SSH), выполнения команд маршрутизатора и сохранения вывода».

Эта атака возможна только тогда, когда системы хранят пароли в открытом виде.

В результате, если рассматривать систему в целом, риск компрометации паролей существенно ниже при использовании PAP, чем при использовании CHAP или MS-CHAP. Поэтому РЕКОМЕНДУЕТСЯ, чтобы администраторы предпочитали PAP вместо CHAP или MS-CHAP. Также РЕКОМЕНДУЕТСЯ, чтобы администраторы хранили пароли «at rest» в защищенной форме (с солью, захешированными).

Тем не менее, другие методы аутентификации, такие как EAP-TLS [RFC9190] и EAP-PWD [RFC5931], не раскрывают пароли в открытом виде ни серверу RADIUS, ни любому промежуточному прокси. Эти методы еще больше снижают риск раскрытия пароля, чем использование PAP. РЕКОМЕНДУЕТСЯ, чтобы администраторы по возможности избегали методов аутентификации на основе паролей.

MS-CHAP
Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure
Deprecating NTLM

MS-CHAP (v1 в [RFC2433] и v2 в [RFC2759]) имеет серьёзные недостатки проектирования и не следует использоваться вне защищённого туннеля. Поскольку MS-CHAPv1 обычно не используется, обсуждение в этом разделе сосредоточено на MS-CHAPv2.

Недавние разработки показывают, насколько легко атаковать обмены MS-CHAPv2 и получить «NT-хэш» пароля. Атака опирается на уязвимость в конструкции протокола, описанную в разделе 8.4 [RFC2759].

В этом разделе ответ на вызов MS-CHAP вычисляется посредством трёх операций DES, основанных на 16-октетной форме NT-хэша пароля. Однако операция DES требует 7-октетные ключи, поэтому 16-октетный NT-хэш нельзя ровно разделить на 21 октет ключей, необходимых для операции DES.

Решение в разделе 8.4 [RFC2759] состоит в использовании первых 7 октетов NT-хэша для первого ключа DES, следующих 7 октетов — для второго ключа DES, что оставляет лишь 2 октета для последнего ключа DES. Последний ключ DES дополняется нулями. Такая конструкция означает, что атакующему, который может наблюдать обмен MS-CHAP2, достаточно выполнить 2^16 операций DES, чтобы определить последние 2 октета исходного NT-хэша.

Если у атакующего есть база данных, сопоставляющая известные пароли с NT-хэшами, то эти два октета можно использовать как индекс в этой базе, которая вернёт подмножество кандидатных хэшей. Затем эти хэши проверяются методом полного перебора, чтобы выяснить, соответствуют ли они исходным данным MS-CHAPv2.

Этот процесс снижает сложность взлома MS-CHAP почти на пять порядков по сравнению с атакой полным перебором. Атака была продемонстрирована на базах данных, содержащих от десятков до сотен миллионов паролей. На обычном компьютере время, необходимое для успешной атаки, составляет порядка десятков миллисекунд.

Хотя для этой атаки требуется база известных паролей, такие базы легко найти в Интернете или создать локально с помощью функций-генераторов. Пароли, создаваемые людьми вручную, известны своей предсказуемостью и с высокой вероятностью окажутся в базе известных паролей. Если используются сильные пароли, то их не будет в базе, и атакующему всё равно придётся выполнять полный перебор по словарю.

В результате безопасность MS-CHAP значительно ниже, чем у PAP. Когда данные MS-CHAP не защищены протоколом TLS, они видны всем, кто может наблюдать за трафиком RADIUS. Таким образом, злоумышленники, которые могут видеть трафик MS-CHAP, могут получить базовый NT-хэш практически без усилий по сравнению со взломом общего секрета RADIUS. Напротив, атрибут User-Password (случай PAP протокола) обфусцируется данными, полученными из Request Authenticator и общего секрета, кроме того, этот метод (шифрование User-Password в PAP) еще не был успешно атакован.

Есть одна ситуация, в которой MS-CHAP значительно хуже PAP: когда данные MS-CHAP передаются по сети в открытом виде. Когда данные MS-CHAP не защищены TLS, они видны каждому, кто может наблюдать трафик RADIUS. Следовательно, злоумышленники, видящие трафик MS-CHAP, могут получить базовый NT-хэш практически без усилий по сравнению со взломом общего секрета RADIUS.

Поэтому данные аутентификации MS-CHAP, передаваемые в RADIUS, НЕ ДОЛЖНЫ передаваться в ситуациях, когда данные MS-CHAP видимы для наблюдателя. То есть аутентификация MS-CHAP НЕ ДОЛЖНА передаваться поверх RADIUS/UDP или RADIUS/TCP.

Согласно разработчику FreeRADIUS - в существующих реализациях RADIUS-клиентов не рекомендуется использовать MS-CHAPv1 и MS-CHAPv2. Клиентам СЛЕДУЕТ запретить в новых конфигурациях включать аутентификацию с использованием MS-CHAP. Новые клиенты RADIUS НЕ ДОЛЖНЫ использовать атрибуты, используемые для аутентификации MS-CHAPv1 и MS-CHAPv2 (MS-CHAP-Challenge и MS-CHAP-Response).