4. Криптоанализ 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, онможет использовать эту информацию для восстановления хэш-функции WindowsNT.

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

Р0-Р13 - байты пароля. Н0-Н15- байты хэш-функции Lan Manager, которая преобразуется в 21-байтовый ключК0-К20. S- фиксированная константа, используемаяв хэш-функции Lan Manager. Вызов С и 24-байтовый отклик Ro-R23.Злоумышленник может знать C и R и хочет найти Р.
Попробуйте все возможные комбинации К14, К15.Правильное значение выделяется, когда С превращается в R16,..., R23 с ключом К14, К15, 0,0,0,0,0.На это уходит примерно 215 операций.
Попробуйте вероятные значения Р7,...,Р13. Неверныезначения можно быстро отбросить путем шифрования S и проверки совпаденияпоследних двух байт полученного значения с К14 и К15.(Так отбрасываются все биты 1 в 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 попыток при М предварительно вычисленных значениях.

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

5. Криптоанализ МРРЕ5.1 Описание МРРЕ

Протокол шифрования в одноранговых сетях (МРРЕ)обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существованиесекретного ключа, известного обоим участникам соединения, и используетпоточный шифр 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 требуетсявремя.

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

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

В любом случае, общая степень защиты составляет не 40 или 128 бит,а количество бит энтропии пароля. На основании экспериментальных данныхполучено, что английскому языку свойственна энтропия 1,3 бита на символ.Изменения регистра, цифры и специальные символы существенно повышают этозначение. Любая атака, которая использует словарь слабых паролей, можетбыть способна прочитать зашифрованный МРРРЕ трафик. Кроме того, стилизованныезаголовки в пакете РРР облегчают сбор известных текстов и базы для проверкиугаданного ключа.

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

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

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

5.3 Атаки переворота битов

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

5.4. Атака путем ресинхронизации

Если в процессе передачи теряется пакет, либо приходит пакет с невернымномером в заголовке МРРЕ, то происходит ресинхронизация ключа. Сторона,принявшая неверный пакет, посылает отправителю запрос на ресинхронизацию.По принятию данного запроса, отправитель реинициализирует таблицы RC4 иустанавливает бит "сброшен" (flushed) в заголовке МРРЕ. Еслисистема обнаруживает в пакете установленный бит "сброшен", онареинициализирует свои таблицы RC4 и устанавливает счетчик пакетов в соответствиис полученным значением.

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

6 Другие атаки на MS-PPTP

Несмотря на то, что атаки на протоколы MS-CHAP и МРРЕ приводят к полномуотрицанию полезности и безопасности MS PPTP, необходимо упомянуть о несколькихинтересных атаках.

6.1 Пассивный мониторинг

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

Путем установки стандартных средств просмотра и расшифровки общественныхлиний связи от серверов Microsoft PPTP была получена следующая информация:
IP-адрес клиента
IP-адрес сервера
Количество доступных на сервере виртуальных каналов РРТР
Версия RAS клиента
Имя клиента NetBIOS
Идентификация производителя клиента
Идентификация производителя сервера
IP-адрес клиента во внутреннем виртуальном туннеле
Внутренние DNS-сервера, обслуживающие клиента
Имя пользователя на клиенте
Достаточно информации для получения значений хэш-функций паролей пользователей
Достаточно информации для получения начального значения МРРЕ
Текущее значение шифрованного пакета для клиента перед реинициализациейRC4
Текущее значение шифрованного пакета для сервера перед реинициализациейRC4

В любом случае, когда канал связи шифруется и пользователь предполагаетнекоторый уровень конфиденциальности, перечисленная выше информация недолжна быть доступна так легко. Для Microsoft PPTP нет легкого способазашифровать эту информацию, поскольку утечки происходят вне канала, контролируемогоМРРЕ. В некоторых случаях, эти пакеты представляют собой конфигурационныеи установочные пакеты для шифрования в рамках МРРЕ, и они должны передаватьсдо начала шифрования. Единственным решением является шифрование каналауправления или резкое уменьшение количества передаваемой по нему информации.

6.2 Перехват переговоров РРР

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

Подмена конфигурационного пакета, описывающего DNS-сервер, позволяетнаправить всю систему распознавания имен на ложный сервер имен.

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

6.3 Канал управления и отказ в обслуживании на сервере

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

Другой причиной была реализация Microsoft канала управления. Мы быстрообнаружили, что просто нарушить работоспособность машины Windows NT с серверомРРТР, иногда это приводило к появлению "голубого экрана". Насамом деле, трудно провести тестирование канала управления и не нарушитьработу сервера РРТР. Настолько трудно, что большая часть атак, предпринимавшихсдля изучения теоретических проблем безопасности канала управления, приводилак нарушению работы сервера раньше, чем атаки могли сработать. Далее описанамалая часть тестов, приводивших к нарушению работы Windows NT Server сустановленным Service Pack 3:
Цикл по пакетам PPTP_CLEAR_CALL_REQUEST с тем, чтобы пройти 16-разрядноепространство идентификаторов вызова.
Перебор всех возможных и невозможных значений, которые могут содержатьсяв поле Тип пакета заголовка пакета РРТР.
Передача недопустимых значений в заголовке пакета управления РРТР.

Все вышеуказанные пакеты могут отправляться на сервер РРТР из-за файрвола,без всякой аутентификации. Предполагается, что нет конфигурации файрвола,позволяющей передавать РРТР на сервер РРТР с определенных IP-адресов илисетей. Однако, если у пользователей есть возможность обращаться к серверуРРТР из любой точки мира, то атакующий тоже должен иметь возможность послатьзапрос из любой точки мира.

6.4. Потенциальные утечки информации на клиенте.

Клиент Windows 95 не выполняет требуемую очистку буферов, и потому допускаетсяутечка информации в сообщениях протокола. Хотя в документации РРТР сказано,что в пакете PPTP_START_SESSION_REQUEST символы после имени компьютераи производителя должны быть сброшены в 0х00, Windows 95 этого не делает.

080: 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000 ..local...>.....

096: 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00 ........?.......

112: 0000 2e00 0000 9c1b 02c1 0000 0000 0000 ................

128: 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00 ....:. &...I....

144: 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e ..9x..(........

160: 02c1 0e00 0000 121e 02c1 2e00 0000 2e00 ................

176: 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b .....t.:..S....

192: 02c1 041e 02c1 0e00 0000 121e 02c1 2e00 ................

208: 0000 ..

Выше показаны символы, содержащиеся после имени компьютера и строки производителя.В байтах 82-86 содержится имя компьютера, которое для клиента Windows 95всегда равняется "local". Байт 113 - то место, где должна содержатьсстрока производителя. При просмотре аналогичного пакета Windows NT обнаружено,что все символы "мусора" сброшены в 0х00.

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