· Слияние двух строк для создания одного 16-разрядного значения хэш-функции.

Словарные атаки на функцию хэша Lan Manager легко достигают успеха по следующим причинам:

· Большинство людей выбирают легко угадываемые пароли.

· Все символы преобразуются в верхний регистр, что ограничивает и без того небольшое число возможных паролей.

· Нет индивидуальной привязки (salt); два пользователя с одинаковыми паролями всегда будут иметь одинаковые значения хэш-функции. Таким образом, можно заранее составить словарь хэшированных паролей и осуществлять поиск неизвестного пароля в нем. При таком подходе с точки зрения отношения время/память тестирование пароля может выполняться со скоростью дискового ввода/вывода.

Две семибайтовых "половины" пароля хэшируются независимо друг от друга. Таким образом, две половины могут подбираться методом грубого подбора независимо друг от друга, и сложность атаки не превышает сложности атаки против семибайтового пароля. Пароли, длина которых превышает семь символов, не сильнее, чем пароли с длиной семь символов. Кроме того, те пароли, длина которых не превышает семь символов очень просто распознать, поскольку вторая половина хэша будет одной и той же фиксированной константой: шифрование фиксированной константы с помощью ключа из семи нулей.

Функция хэша Windows NT вычисляется следующим образом:

· Преобразование пароля, длиной до 14 символов, с различением регистров в Unicode.

· Хэширование пароля с помощью MD4, получение 16-символьного значения хэш-функции.

Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager - различаются регистры, пароли могут быть длиннее 14 символов, хэширование пароля в целом вместо разбиения его на маленькие части - хотя по-прежнему отсутствует индивидуальность. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэшированные пароли Windows NT. Сравнение файла хэшированных паролей с заранее рассчитанным словарем хэшированных паролей может быть весьма эффективной атакой.

Кроме того, более серьезна проблема реализации существенно облегчает раскрытие паролей. Даже хотя хэш Lan Manager был включен по соображениям совместимости с предыдущими версиями, и не требуется в сетях Windows NT, оба значения хэш-функций всегда передаются вместе. Следовательно, можно выполнить грубый подбор пароля с помощью более слабой хэш-функции Lan Manager и затем выполнить тестирование с учетом регистра для подбора значения хэш-функции Windows NT.

3.2 Криптоанализ MS-CHAP

РРР содержит различные способы обработки аутентификации. Одним из способов является протокол аутентификации вызов-рукопожатие (СНАР). Реализация PPP СНАР компанией Microsoft (MS-CHAP) почти совпадает с методом аутентификации, используемым для аутентификации клиентов в Windows-сетях.

MS-CHAP функционирует следующим образом:

· Клиент запрашивает вызов сетевого имени.

· Сервер возвращает восьмибайтовый случайный вызов.

· Клиент вычисляет хэш-функцию Lan Manager, добавляет пять нулей для создания 21-байтовой строки и делит строку на три семибайтовых ключа. Каждый ключ используется для шифрации вызова, что приводит к появлению 24-разрядного шифрованного значения. Оно возвращается серверу как отклик. Клиент выполняет то же самое с хэш-функцией Windows NT.

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

Сервер может выполнять сравнение по хэш-функции Windows NT или по хэш-функции Lan Manager; результаты должны совпадать. Хэш, используемый сервером, зависит от конкретного флага в пакете. Если флаг установлен, то сервер выполняет тестирование с помощью хэш-функции Windows NT; в противном случае тестирование выполняется с помощью хэш-функции Lan Manager.

Протокол вызова/отклика является стандартным; использование случайного вызова имени делает невозможными словарные атаки на MS-CHAP и файл записанных хэш-функций от паролей. В то же время, поскольку даже в Windows NT-сетях используются оба значения хэш-функции, можно в каждом случае атаковать более слабую хэш-функцию Lan Manager. Поскольку ответ клиента разбит на три части, и каждая часть шифруется независимо от других, можно атаковать сам протокол MS-CHAP.

Последние восемь байт хэш-функции Lan Manager представляют собой константу в том случае, если длина пароля не превышает семи символов. Это верно, несмотря на случайный вызов. Следовательно, последние восемь байт отклика клиента будут представлять собой вызов, зашифрованный с помощью данной константы. Легко проверить, не превышает ли длина пароля семи символов. После того, как атакующий находит значение хэш-функции Lan Manager, он может использовать эту информацию для восстановления хэш-функции Windows NT.

Атака может быть существенно ускорена за счет активного использования предварительных вычислений и тщательного исследования слабостей хэш-функции Lan Manager и протокола MS-CHAP. Далее приводятся подробности оптимизированной атаки:

Р0-Р13 - байты пароля. Н0-Н15 - байты хэш-функции Lan Manager, которая преобразуется в 21-байтовый ключ К0-К20. S- фиксированная константа, используемая в хэш-функции Lan Manager. Вызов С и 24-байтовый отклик Ro-R23. Злоумышленник может знать C и R и хочет найти Р.

1) Можно попробовать все возможные комбинации К14, К15. Правильное значение выделяется, когда С превращается в R16, ..., R23 с ключом К14, К15, 0,0,0,0,0. На это уходит примерно 215 операций.

2) Можно попробовать вероятные значения Р7,...,Р13. Неверные значения можно быстро отбросить путем шифрования S и проверки совпадения последних двух байт полученного значения с К14 и К15. (Так остается только один вариант из каждых 216). Каждый оставшийся вариант Р7,...,Р13 предоставляет значение-кандидат для К8,...,К13. Чтобы проверить значение-кандидат, проверьте все возможные значения К7, чтобы увидеть, есть ли такое, при котором С шифруется в R8,...,R15 при значении-кандидате К8,...,К15. Если есть такое К7, то догадка для Р7,...,Р13 почти наверняка верна. Если нет, то надо выбрать другое значение для Р7,...,Р13. Если существуют N вероятных вариантов Р7,...,Р13, то подбор верного значения можно провести за N тестовых шифрований.
Поскольку в протоколе нет индивидуальной настройки, эта атака может быть существенно ускорена с помощью замены время/память. Если есть N заранее вычисленных тестовых шифрований, то восстановление верного значения Р7,...,Р13 потребует N/216 операций.

После нахождения Р7,...,Р13, восстановление Р0,...,Р6 требует М попыток, где М - число вероятных значений Р0,...,Р6. Опять же, поскольку нет индивидуальной настройки, атака может быть выполнена за N/28 попыток при М предварительно вычисленных значениях.

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

3.3 Криптоанализ МРРЕ

Протокол шифрования в одноранговых сетях (МРРЕ) обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существование секретного ключа, известного обоим участникам соединения, и использует поточный шифр RC4 с 40- либо 128-разрядным ключом. Такой метод установки использования МРРЕ является одной из функций протокола управления сжатием РРР (ССР). После установки режима работы начинается сеанс РРР по передаче пакетов зашифрованных данных. Важно отметить, что шифруются только те пакеты РРР, номера протоколов которых лежат в диапазоне 0x0021-0x00fa. Все остальные пакеты передаются без шифрования, даже если шифрование разрешено. Типы пакетов, шифрование которых осуществляется/не осуществляется, регламентируются документом RFC 1700. Для любых пакетов не обеспечивается аутентификация.

В МРРЕ 40-битовый ключ RC4 определяется следующим образом:

· Генерация определяющего 64-битового ключа из хэш-функции Lan Manager пароля пользователя (известного пользователю и серверу) с помощью SHA.

· Установка старших 24 бит ключа в значение 0xD1269E.

128-битовый ключ RC4 определяется следующим образом:

· Объединение хэша Windows NT и 64-битового случайного значения, выданного сервером при работе по протоколу MS-CHAP. Данное число посылается клиенту по протоколу обмена, потому оно известно и клиенту, и серверу.

· Генерация определяющего 128-битового ключа из результатов предыдущего этапа с помощью SHA.

Результирующий ключ используется для инициализации RC4 обычным способом, а затем для шифрования байт данных. После каждых 256 пакетов - МРРЕ поддерживает счетчик, в котором фиксируется число пакетов - генерируется новый ключ RC4 по следующим правилам:

· Генерация определяющего ключа - 64-битового для 40-битового шифрования и 128-битового для 128-битового шифрования - путем хэширования предыдущего ключа и исходного ключа с помощью SHA.

· Если требуется 40-битовый ключ, то установка старших 24 бит ключа в значение 0xD1269E.

· Длина типичного пакета РРТР составляет 200 байт, включая заголовок.

При потере синхронизации происходит реинициализация RC4 с использованием текущего ключа. Существует также возможность обновления ключа RC4 после каждого пакета; эта возможность снижает эффективность шифрования примерно наполовину, поскольку на выполнение плановых изменений ключа RC4 требуется время.

3.3.1 Восстановление ключа

В МРРЕ степень защиты ключа не превышает степень защиты пароля. Большая часть паролей имеет существенно меньше 40 бит безопасности и раскрываются с помощью словарных атак. Хэш-функция Lan Manager еще боле уязвима: с учетом максимальной длины порции, ограниченного алфавита и отсутствия символов нижнего регистра, невозможно сгенерировать 128-битовый ключ, даже если пользователь хочет это сделать. В документации по МРРЕ описывается флаг для вычисления 40-битового ключа RC4 на основании хэш-функции Windows NT, а не Lan Manager, но эта функция еще не реализована. Нет способов вычисления 128-битового ключа RC4 на основании хэш-функции Windows NT, хотя такой вариант был бы более безопасным (хотя существенно менее безопасным, чем 128-битовый случайный ключ.)

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13