kiev-security.org.ua-Криптография.Криптоанализ туннельного протокола типа точка-точка(PPTP) от Microsoft

1 Введение

Многие организации не являются централизованными. Филиалы, виртуальные корпорации и перемещающиеся сотрудники делают идею создания выделенногоканала к любому требуемому пункту логически невозможной. Концепция виртуальныхсетей обеспечивает решение возникшей проблемы путем туннелирования объединяемогосетевого пространства по другим, промежуточным и небезопасным сетям (например,Интернет), тем самым позвол удаленным пунктам стать локальными. Данноерешение не требует вложений на проведение абонируемых или выделенных линийв любую точку. Такой способ иногда называют "тоннель".

По мере решения виртуальными сетями проблем нецентрализованных машинвозникла другая проблема. Трафик, который раньше находился в пределах компании,теперь открыт для любопытных глаз со всего мира. Для обеспечения не толькоотказоустойчивости, но и безопасности информации необходимо использоватьмеханизмы аутентификации и шифрования. В результате виртуальные сетевыесоединения объединили с криптографической защитой, и конечный продукт назвалиВиртуальные Приватные Сети (VPN).

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

Протокол PPTP (туннельный протокол типа точка-точка) был предназначендля решения задачи создания и управления VPN по общественной сети TCP/IPс использованием стандартного протокола РРР. Хотя протокол резервируетпространство для всех возможных типов шифрования и аутентификации, в большинствекоммерческих продуктов используется версия данного протокола для WindowsNT. Именно эта реализация и подвергнута анализу в данной статье.

Мы обнаружили, что протокол аутентификации Microsoft слаб и уязвимпутем атаки по словарю; большинство паролей можно вскрыть в течение несколькихчасов. Мы обнаружили, что способы шифрования с использованием 40- и 128-разрядныхключей одинаково слабы и открыли ряд заложенных в реализацию неразумныхидей, которые позволяют осуществлять другие атаки на данный шифр. Мы можетоткрывать соединения через firewall, нарушая правила переговоров РРTР,и можем проводить различные атаки отказа в обслуживании на тех, кто используетMicrosoft PPTP.

Оставшаяся часть работы разделена следующим образом: В параграфе 2рассматривается РРТР, как стандарт протокола, так и реализация Microsoft.В параграфе 3 рассматриваются две функции хэширования паролей в MicrosoftPPTP и способы атаки на них. В параграфе 4 проводится криптоанализ протоколааутентификации Microsoft, а в параграфе 5 - криптоанализ протокола шифрованияMicrosoft. Другие атаки на Microsoft РРТР рассмотрены в параграфе 6. Наконец,в параграфе 7 делаются некоторые выводы.

2 Туннельный протокол типа точка-точка

РРТР - протокол, который позволяет выполнять туннелирование РРР-соединенийпо IP-сети путем создания VPN. Таким образом, удаленный компьютер в сетиХ может туннелировать трафик на шлюз в сети У и имитировать подключение,с внутренним IP-адресом, к сети У. Шлюз получает трафик для внутреннегоIP-адреса и передает его удаленной машине в сети Х. Существуют два основныхспособа использования РРТР: по Интернет и по коммутируемым соединениям.Настояща статья ориентирована на использовании РРТР как VPN при непосредственномподключении клиента к Интернет.

Функционирование РРТР заключается в инкапсулировании пакетов виртуальнойсети в пакеты РРР, которые в свою очередь, инкапсулируются в пакеты GRE(Generic Routing Incapsulation), передаваемые по IP от клиента к шлюзу- серверу РРР и обратно. Совместно с каналом инкапсулированных данных существуетуправляющий сеанс на базе TCP. Пакеты управляющего сеанса позволяют запроситьстатус и сопровождать сигнальную информацию между клиентом и сервером.Канал управления инициируется клиентом на сервере на ТСР-порте 1723. Вбольшинстве случаев это двунаправленный канал, по которому сервер посылаетзапросы на сервер и наоборот.

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

2.1 РРТР от Microsoft

Microsoft РРТР является частью ОС Windows NT Server, данное программноеобеспечение можно бесплатно получить с Web-сайта Microsoft. Подключениеосуществляется с помощью панели управления и редактора реестра. Даннаяреализация РРТР широко используется в коммерческих применениях VPN, напримерAventail и Freegate именно потому, что входит в состав ОС Microsoft.

Сервер Microsoft РРТР может существовать только для Windows NT, хотяклиентское программное обеспечение существует для Windows NT, некоторыхверсий Windows и Windows 98. Реализация Microsoft поддерживает три вариантааутентификации:

Текстовый пароль: Клиент передает серверу пароль в открытом виде.
Хэшированный пароль: Клиент передает серверу хэш пароля (см. параграф3).
Вызов/Отклик: Аутентификация сервера и клиента с использованием протоколаMS-CHAP (вызов/отклик), что описано в параграфе 4.

Третий вариант называется в документации для пользователей "АутентификациMicrosoft", для шифрования пакетов РРТР его надо разрешить. При выборелюбого из двух других вариантов шифрование неосуществимо. Кроме того, возможностьшифрования (40- или 128-разрядное) гарантируется только в том случае, есликлиент использует Windows NT. Некоторые клиенты Windows 95 не могут поддерживатьзашифрованные сеансы¹.

3. Криптоанализ функций хэширования паролей WindowsNT

В ОС Microsoft Windows NT для защиты паролей используются две однонаправленныехэш-функции: хэш Lan Manager и хэш Windows NT. Функция хэша Lan Managerбыла разработана Microsoft для операционной системы IBM OS/2, она былаинтегрирована в Windows for Workgroups и частично в Windows 3.1. Даннаяфункция используется в некоторых протоколах аутентификации перед WindowsNT. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT.Функция хэша Lan Manager основана на алгоритме DES; Функция хэша WindowsNT основана на односторонней хэш-функции MD4. Обе эти функции используютсяво многих протоколах аутентификации Windows NT, а не только в РРТР.

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

Превращение пароля в 14-символьную строку путем либо отсечки болеедлинных паролей, либо дополнения коротких паролей нулевыми элементами.

Замена всех символов нижнего регистра на символы верхнего регистра.Цифры и специальные символы остаются без изменений.
Разбиение 14-байтовой строки на две семибайтовых половины.
Использование каждой половины строки в роли ключа DES, шифрование фиксированнойконстанты с помощью каждого ключа, получение двух 8-байтовых строк.
Слияние двух строк для создания одного 16-разрядного значения хэш-функции.

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

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

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

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

Преобразование пароля, длиной до 14 символов, с различением регистровв Unicode.
Хэширование пароля с помощью MD4, получение 16-символьного значенияхэш-функции.

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

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

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. Далее приводятся подробности оптимизированнойатаки:

Р₀-Р₁₃ - байты пароля. Н₀-Н₁₅- байты хэш-функции Lan Manager, которая преобразуется в 21-байтовый ключК₀-К₂₀. S- фиксированная константа, используемаяв хэш-функции Lan Manager. Вызов С и 24-байтовый отклик R_o-R₂3.Злоумышленник может знать C и R и хочет найти Р.

Попробуйте все возможные комбинации К₁₄, К₁₅.Правильное значение выделяется, когда С превращается в R₁₆,..., R₂₃ с ключом К₁₄, К₁₅, 0,0,0,0,0.На это уходит примерно 2¹⁵ операций.
Попробуйте вероятные значения Р₇,...,Р₁₃. Неверныезначения можно быстро отбросить путем шифрования S и проверки совпаденияпоследних двух байт полученного значения с К₁₄ и К₁₅.(Так отбрасываются все биты 1 в 2¹⁶ неверных вариантах). Каждыйоставшийся вариант Р₇,...,Р₁₃ предоставляет значение-кандидатдля К₈,...,К₁₃. Чтобы проверить значение-кандидат,проверьте все возможные значения К₇, чтобы увидеть, есть литакое, при котором С шифруется в R₈,...,R₁₅ при значении-кандидатеК₈,...,К₁₅. Если есть такое К₇, то догадкадля Р₇,...,Р₁₃ почти наверняка верна. Если нет, тонадо выбрать другое значение для Р₇,...,Р₁₃. Еслисуществуют N вероятных вариантов Р₇,...,Р₁₃, то подборверного значения можно провести за N тестовых шифрований.
Обратите внимание, что поскольку в протоколе нет индивидуальной настройки,эта атака может быть существенно ускорена с помощью замены время/память.Если есть N заранее вычисленных тестовых шифрований, то восстановлениеверного значения Р₇,...,Р₁₃ потребует N/2¹⁶операций.
После нахождения Р₇,...,Р₁₃, восстановление Р₀,...,Р₆требует М попыток, где М - число вероятных значений Р₀,...,Р₆.Опять же, поскольку нет индивидуальной настройки, атака может быть выполненаза N/2⁸ попыток при М предварительно вычисленных значениях.

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

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.

7 Выводы

Реализация РРТР от Microsoft уязвима с точки зрения реализации, и обладаетсерьезными недостатками с точки зрения протокола. Протокол аутентификацииимеет известные уязвимости, на которые указывалось не только здесь, нои в группах, например, L0pht. Шифрование выполнено неверно, в данной реализациииспользуется поточный шифр с обратной связью по выходу, хотя более уместенбыл бы блоковый шифр "шифр-блок-цепочка" (CBC). Чтобы связатьслабую аутентификацию с плохим шифрованием Microsoft задал ключ шифрованиякак функцию от пароля пользователя вместо использования сильного алгоритмаобмена ключами типа Диффи-Хеллмана или ЕКЕ. Наконец, канал управления неаутентифицируется и не сильно защищен.

Мы не потратили много времени на изучение механизмов обеспечения локальныхIP-адресов клиентов и того, как Microsoft пытался и смог ли он учесть уязвимостьпредставления клиента с двумя адресами. Тем не менее, мы обнаружили проблемыс нестандартными масками подсети и внутренним трафиком туннеля, отправленногоот РРТР сервера. Разработчики, будьте внимательны!

Наконец, хочется подчеркнуть, что криптоанализ не подвергал сомнениюпротокол РРТР (?), но лишь реализацию протокола от Microsoft. Хотя Microsoftиспользует свои собственные расширения (MS-CHAP, МРРЕ, МРРС) в РРР секцииРРТР, стандарт РРТР не требует этого. Производители могут включить расширенияMicrosoft в свои продукты по соображениям совместимости, но они не обязаныограничиватьс их использованием и, наверное, реализуют более безопасныерешения. Конечно, новые расширения для корректной работы должны поддерживатьсякак клиентом, так и сервером.

В ходе экспериментов выяснилось,что некоторые клиенты Windows 95 поддерживают аутентификацию Microsoft,а некоторые - нет. Мы не смогли оценить различия или определить способы,позволяющие понять, поддерживает ли данная система Windows 95 аутентификациюMicrosoft. Если протокол не поддерживается, то пункт в диалоговом окненедоступен. Это ограничение соответствует заявлению Microsoft, что Windows95 не обеспечивает безопасность, и что те пользователи, которым она нужна,должны перейти на NT. Тем не менее, Microsoft заявлял, что Windows 95 необрабатывает хэш Windows NT, а использует хэш Lan Manager. Однако клиентыWindows 95 передают обе хэш-функции. Из нашего анализа кода Windows 95неясно, почему шифрование нельзя реализовать в клиентах Windows 95.

В документации Microsoftсказано, что длина паролей Windows NT может достигать 128 символов, и хэш-функцияWindows NT принимает пароли такой длины. Однако, диспетчер пользователейограничивает длину паролей до 14 символов. В документации MS-СНАР такжеупоминается это ограничение, которое подтвердилось в ходе экспериментов.

Известное средство хакеров,L0pthcrack, автоматизирует процесс подбора пароля по его хэш-значению.На Pentium Pro 200, L0phtcrack 2.0 может проверить файл с 200 паролямиза минуту с использованием 8 мегабaйтного словаря паролей.

Мы не исследовали ни самгенератор псевдослучайных чисел, ни его криптографическую стойкость.

8. БлагодарностиМы хотели бы поблагодарить Mark Chen, Chris Hall, Brad Kemp, Paul Jones,Ben McCann, Mark Seiden, Inderpreet Singh, David Wagner и Wray West за ихценные замечания.

Литература

[Ave98] Aventail Corp., 1998. http://www.aventail.com.

[BV98] L. Blunk and J. Vollbrecht, ``PPP Extensible Authentication Protocol(EAP),'' Network Working Group, RFC 2284, Mar 1998. ftp://ftp.isi.edu/in-notes/rfc2284.txt.

[CK78] T.M. Cover and R.C. King, ``A Convergent Gambling Estimate ofEntropy,'' IEEE Transactions on Information Theory, v. IT-24, n. 4, Jul1978, pp. 413--421.

[Fre98] FreeGate Corp., 1998. http://www.freegate.com.

[HLFT94] S. Hanks, T. Li, D. Farinacci, and P. Traina, ``Generic RoutingEncapsulation (GRE),'' Network Working Group, RFC 1701, Oct. 1994. ftp://ftp.isi.edu/in-notes/rfc1701.txt.

[Hob97] Hobbit, ``CIFS: Common Insecurities Fail Scrutiny,'' Avian Research,Jan 1997. http://www.avian.org.

[HPV+97] K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, and W.A. Little,``Point-to-Point Tunneling Protocol,'' Internet Draft, IETF, Jul 1997.http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-02.txt.

[KSWH98] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, ``CryptanalyticAttacks on Pseudorandom Number Generators,'' Fast Software Encryption:5th International Workshop, Springer-Verlag,1998, pp. 168-188

[Kle90] D.V. Klein, ``Foiling the Cracker: A Security of, and Implicationsto, Password Security,'' Proceedings of the USENIX UNIX Security Workshop,Aug 1990, pp. 5--14.

[Kli98] S. Klinger, ``Microsoft PPTP and RRAS for Windows NT Server4.0,'' LAN Times, Feb ??, 1998. http://www.lantimes.com/98/98feb/802b065b.html.

[L97a] L0pht Heavy Industries Inc, L0phtcrack, 1997. http://www.L0pht.com/L0phtcrack/.

[L97b] L0pht Heavy Industries Inc, ``A L0phtCrack Technical Rant,''Jul 1997. http://www.l0pht.com/l0phtcrack/rant.html.

[LS92] B. Lloyd and W. Simpson, ``PPP Authentication Protocols,'' NetworkWorking Group, RFC 1334, Oct 1992. ftp://ftp.isi.edu/in-notes/rfc1334.txt.

[Mey96] G. Meyer, ``The PPP Encryption Control Protocol (ECP),'' NetworkWorking Group, RFC 1968, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1968.txt.

[Mic96a] Microsoft Corpotation, Advanced Windows NT Concepts, New RidersPublishing, 1996. Relevent chapter at http://www.microsoft.com/communications/nrpptp.htm.

[Mic96b] Microsoft Corporation, ``Pont-to-Point Tunneling Protocol (PPTP)Frequently Asked Questions,'' Jul 1996. http://premium.microsoft.com/sdn/library/bkgrnd/html/pptpfax.htm.

[Mic97] Microsoft Corporation, ``Response to Security Issues Raisedby the L0phtcrack Tool,'' Apr 1997, http://www.microsoft.com/security/l0phtcrack.htm.

[Mic98] Microsoft Corporation, ``Clarification on the L0phtcrack 2.0Tool.'' Mar 1998.

http://www.microsoft.com.security/l0pht20.htm.

[MB97] P. Mudge and Y. Benjamin, ``Deja Vu All Over Again,'' Byte, Nov1997.

http://www.byte.com/art/9711/sec6/art3.htm.

[NBS77] National Bureau of Standards, NBS FIPS PUB 46, ``Data EncryptionStandard,'' National Bureau of Standards, U.S. Department of Commerce,Jan 1977.

[NIST93] National Institute of Standards and Technology, ``Secure HashStandard,'' U.S. Department of Commerce, May 93.

[Pal96a] G.S. Pall, ``Microsoft Point-to-Point Compression (MPPC) Protocol,''Network Working Group Internet Draft, Jul 1996.

[Pal96b] G.S. Pall, ``Microsoft Point-to-Point Encryption (MPPE) Protocol,''Network Working Group Internet Draft, Jul 1996.

[PZ98] G.S. Pall and G. Zorn, ``Microsoft Point-to-Point Encryption(MPPE) Protocol,'' Network Working Group, Internet Draft, IETF, Mar 1998.http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-00.txt.

[Ran96] D. Rand, ``The PPP Compression Control Protocol (CCP),'' NetworkWorking Group, RFC 1962, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1962.txt.

[RP94] J. Reynolds and J. Postel, ``Assigned Numbers,'' Networking Group,Std 2, RFC 1700, Oct 1994. ftp://ftp.isi.edu/in-notes/rfc1700.txt.

[Riv91] R.L. Rivest, ``The MD4 Message Digest Algorithm,'' Advancesin Cryptology --- CRYPTO '90 Proceedings, Springer-Verlag, 1991, pp. 303--311.

[Sch96] B. Schneier Applied Cryptography, 2nd Edition, John Wiley &Sons, 1996.

[Sim94] W. Simpson, ``The Point-to-Point Protocol (PPP),'' Network WorkingGroup, STD 51, RFC 1661,, Jul 1994. ftp://ftp.isi.edu/in-notes/rfc1661.txt.

[Sim96] W. Simpson, ``PPP Challenge Handshake Authentication Protocol(CHAP)'' Network Working Group, RFC 1334, Aug 1996. ftp://ftp.isi.edu/in-notes/rfc1994.txt.

[ZC98] G. Zorn and S. Cobb, ``Microsoft PPP CHAP Extensions,'' NetworkWorking Group Internet Draft, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-00.txt.

Криптоанализ туннельного протокола типа точка-точка(PPTP) от Microsoft (Bruce Schneier,Peter Mudge)