Защита информации виртуальных частных сетей

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

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

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

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

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

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

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

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

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

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

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

Путем установки стандартных средств просмотра и расшифровки общественных линий связи от серверов Microsoft PPTP была получена следующая информация:

IP-адрес клиента

IP-адрес сервера

Количество доступных на сервере виртуальных каналов РРТР

Версия RAS клиента

Имя клиента NetBIOS

Идентификация производителя клиента

Идентификация производителя сервера

IP-адрес клиента во внутреннем виртуальном туннеле

Внутренние DNS-сервера, обслуживающие клиента

Имя пользователя на клиенте

Достаточно информации для получения значений хэш-функций паролей пользователей

Достаточно информации для получения начального значения МРРЕ

Текущее значение шифрованного пакета для клиента перед реинициализацией RC4

Текущее значение шифрованного пакета для сервера перед реинициализацией RC4

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

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

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

 Скачать реферат