 |
Содержание:
2 Туннельный протокол типа точка-точка
3. Криптоанализ функций хэширования паролей Windows NT
5.4. Атака путем ресинхронизации
Стандартный симметричный алгоритм DES (Data Encryption Standard)
Многие организации не являются централизованными. Филиалы, виртуальные корпорации и перемещающиеся сотрудники делают идею создания выделенного канала к любому требуемому пункту логически невозможной. Концепция виртуальных сетей обеспечивает решение возникшей проблемы путем туннелирования объединяемого сетевого пространства по другим, промежуточным и небезопасным сетям (например, Интернет), тем самым позволяют удаленным пунктам стать локальными. Данное решение не требует вложений на проведение абонируемых или выделенных линий в любую точку. Такой способ иногда называют "тоннель".
По
мере решения виртуальными сетями проблем
нецентрализованных машин возникла другая
проблема. Трафик, который раньше находился
в пределах компании, теперь открыт для
любопытных глаз со всего мира. Для
обеспечения не только отказоустойчивости,
но и безопасности информации необходимо
использовать механизмы аутентификации и
шифрования. В результате виртуальные
сетевые соединения объединили с
криптографической защитой, и конечный
продукт назвали Виртуальные Приватные Сети
(VPN).
Безопасность
VPN основывается на безопасности протоколов
аутентификации и шифрования. Если
криптография VPN слаба, то степень защиты не
выше, чем в любой другой неприватной сети
передачи информации по Интернет. Поскольку
компании надеются, что VPN расширит периметр
внутренней безопасности до удаленного
офиса, прорыв системы защиты туннеля
соответствует уничтожению всех систем
защиты внутреннего периметра. Прорыв в VPN
означает практически то же самое, что и
прорыв за firewall.
Протокол
PPTP (туннельный протокол типа точка-точка)
был предназначен для решения задачи
создания и управления VPN по общественной
сети TCP/IP с использованием стандартного
протокола РРР. Хотя протокол резервирует
пространство для всех возможных типов
шифрования и аутентификации, в большинстве
коммерческих продуктов используется
версия данного протокола для Windows NT.
Анали
показывает, что протокол аутентификации
Microsoft слаб и уязвим путем атаки по словарю;
большинство паролей можно вскрыть в
течение нескольких часов.
РРТР - протокол, который
позволяет выполнять туннелирование
РРР-соединений по IP-сети путем создания VPN.
Таким образом, удаленный компьютер в сети Х
может туннелировать трафик на шлюз в сети У
и имитировать подключение, с внутренним IP-адресом,
к сети У. Шлюз получает трафик для
внутреннего IP-адреса и передает его
удаленной машине в сети Х. Существуют два
основных способа использования РРТР: по
Интернет и по коммутируемым соединениям.
Функционирование
РРТР заключается в инкапсулировании
пакетов виртуальной сети в пакеты РРР,
которые в свою очередь, инкапсулируются в
пакеты GRE (Generic Routing Incapsulation), передаваемые по
IP от клиента к шлюзу - серверу РРР и обратно.
Совместно с каналом инкапсулированных
данных существует управляющий сеанс на
базе TCP. Пакеты управляющего сеанса
позволяют запросить статус и сопровождать
сигнальную информацию между клиентом и
сервером. Канал управления инициируется
клиентом на сервере на ТСР-порте 1723. В
большинстве случаев это двунаправленный
канал, по которому сервер посылает запросы
на сервер и наоборот.
РРТР
не оговаривает конкретных алгоритмов
аутентификации и протоколов; вместо этого
он обеспечивает основу для обсуждения
конкретных алгоритмов. Переговоры не
присущи только РРТР, они относятся к
существующим вариантам переговоров РРР,
содержащихся в ССР, СНАР и других
расширениях и усовершенствованиях РРР.
Microsoft РРТР является частью ОС Windows NT Server, данное программное обеспечение можно бесплатно получить с Web-сайта Microsoft. Подключение осуществляется с помощью панели управления и редактора реестра. Данная реализация РРТР широко используется в коммерческих применениях VPN, например Aventail и Freegate именно потому, что входит в состав ОС Microsoft.
Сервер
Microsoft РРТР может существовать только для
Windows NT, хотя клиентское программное
обеспечение существует для Windows NT,
некоторых версий Windows и Windows 98. Реализация
Microsoft поддерживает три варианта
аутентификации:
1.
Текстовый
пароль: Клиент передает серверу пароль в
открытом виде.
2.
Хэшированный
пароль: Клиент передает серверу хэш пароля (см.
параграф 3).
3.
Вызов/Отклик:
Аутентификация сервера и клиента с
использованием протокола MS-CHAP (вызов/отклик),
что описано в параграфе 4.
Третий
вариант называется в документации для
пользователей "Аутентификаци Microsoft",
для шифрования пакетов РРТР его надо
разрешить. При выборе любого из двух других
вариантов шифрование неосуществимо. Кроме
того, возможность шифрования (40- или 128-разрядное)
гарантируется только в том случае, если
клиент использует Windows NT. Некоторые клиенты
Windows 95 не могут поддерживать зашифрованные
сеансы.
В ОС Microsoft Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager и хэш Windows NT. Функция хэша Lan Manager была разработана Microsoft для операционной системы IBM OS/2, она была интегрирована в Windows for Workgroups и частично в Windows 3.1. Данная функция используется в некоторых протоколах аутентификации перед Windows NT. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT. Функция хэша Lan Manager основана на алгоритме DES; Функция хэша Windows NT основана на односторонней хэш-функции MD4. Обе эти функции используются во многих протоколах аутентификации Windows NT, а не только в РРТР.
Функция
хэша Lan Manager вычисляется следующим образом:
Превращение
пароля в 14-символьную строку путем либо
отсечки более длинных паролей, либо
дополнения коротких паролей нулевыми
элементами.
1.
Замена всех символов нижнего регистра
на символы верхнего регистра. Цифры и
специальные символы остаются без изменений.
2.
Разбиение 14-байтовой строки на две
семибайтовых половины.
3.
Использование каждой половины строки в
роли ключа DES, шифрование фиксированной
константы с помощью каждого ключа,
получение двух 8-байтовых строк.
4.
Слияние двух строк для создания одного
16-разрядного значения хэш-функции.
Словарные атаки на функцию хэша Lan Manager легко достигают успеха по следующим причинам:
Функция
хэша Windows NT вычисляется следующим образом:
1.
Преобразование пароля, длиной до 14
символов, с различением регистров в Unicode.
2.
Хэширование пароля с помощью MD4,
получение 16-символьного значения хэш-функции.
Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager - различаются регистры, пароли могут быть длиннее 14 символов, хэширование пароля в целом вместо разбиения его на маленькие части - хотя по-прежнему отсутствует индивидуальность. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэшированные пароли Windows NT. Сравнение файла хэшированных паролей с заранее рассчитанным словарем хэшированных паролей может быть весьма эффективной атакой.
Кроме
того, более серьезная проблема реализации
существенно облегчает раскрытие паролей.
Даже хотя хэш Lan Manager был включен по
соображениям совместимости с предыдущими
версиями, и не требуется в сетях Windows NT, оба
значения хэш-функций всегда передаются
вместе. Следовательно, можно выполнить
грубый подбор пароля с помощью более слабой
хэш-функции Lan Manager и затем выполнить
тестирование с учетом регистра для подбора
значения хэш-функции Windows NT.
РРР содержит различные способы обработки аутентификации. Одним из способов является протокол аутентификации вызов-рукопожатие (СНАР). Реализация PPP СНАР компанией Microsoft (MS-CHAP) почти совпадает с методом аутентификации, используемым для аутентификации клиентов в Windows-сетях.
MS-CHAP
функционирует следующим образом:
1.
Клиент
запрашивает вызов сетевого имени.
2.
Сервер
возвращает восьмибитовый случайный вызов.
3.
Клиент вычисляет хэш-функцию Lan Manager,
добавляет пять нулей для создания 21-байтовой
строки и делит строку на три семибайтовых
ключа. Каждый ключ используется для
шифрации вызова, что приводит к появлению 24-разрядного
шифрованного значения. Оно возвращается
серверу как отклик. Клиент выполняет то же
самое с хэш-функцией Windows NT.
4.
Сервер ищет значение хэш-функции в
своей базе данных, шифрует запрос с помощью
хэш-функции и сравнивает его с полученными
шифрованными значениями. Если они
совпадают, аутентификация заканчивается.
Сервер
может выполнять сравнение по хэш-функции
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.
Кроме того, данный протокол позволяет выполнить аутентификацию только клиента. Атакующий, выполняющий подмену соединения, может тривиально замаскироваться под сервер. Если шифрование разрешено, атакующий не сможет посылать и принимать сообщения (пока не взломает шифр), однако используя старое значение вызова он сможет получить две сессии текста, зашифрованные одним ключом.
Протокол шифрования в одноранговых сетях (МРРЕ) обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существование секретного ключа, известного обоим участникам соединения, и использует поточный шифр RC4 с 40- либо 128-разрядным ключом. Такой метод установки использования МРРЕ является одной из функций протокола управления сжатием РРР (ССР) и описан в приложении С. После установки режима работы начинается сеанс РРР по передаче пакетов зашифрованных данных.
В
МРРЕ 40-битовый ключ RC4 определяется
следующим образом:
1.
Генерация определяющего 64-битового
ключа из хэш-функции Lan Manager пароля
пользователя (известного пользователю и
серверу) с помощью SHA.
2.
Установка
старших 24 бит ключа в значение 0xD1269E.
128-битовый ключ RC4
определяется следующим образом:
1.
Объединение хэша Windows NT и 64-битового
случайного значения, выданного сервером
при работе по протоколу MS-CHAP. Данное число
посылается клиенту по протоколу обмена,
потому оно известно и клиенту, и серверу.
2.
Генерация определяющего 128-битового
ключа из результатов предыдущего этапа с
помощью SHA.
Результирующий ключ используется для инициализации RC4 обычным способом, а затем для шифрования байт данных. После каждых 256 пакетов - МРРЕ поддерживает счетчик, в котором фиксируется число пакетов - генерируется новый ключ RC4 по следующим правилам:
1.
Генерация определяющего ключа - 64-битового
для 40-битового шифрования и 128-битового для
128-битового шифрования - путем хэширования
предыдущего ключа и исходного ключа с
помощью SHA.
2.
Если требуется 40-битовый ключ, то
установка старших 24 бит ключа в значение
0xD1269E.
Длина
типичного пакета РРТР составляет 200 байт,
включая заголовок.
При
потере синхронизации происходит
реинициализация RC4 с использованием
текущего ключа. Существует также
возможность обновления ключа RC4 после
каждого пакета; эта возможность снижает
эффективность шифрования примерно
наполовину, поскольку на выполнение
плановых изменений ключа RC4 требуется время.
В МРРЕ степень защиты ключа не превышает степень защиты пароля. Большая часть паролей имеет существенно меньше 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, хотя для шифрования текста в обоих
направлениях будет использован один и тот
же ключ.
RC4 - способ поточного шифрования с обратной связью по выходу, при этом не обеспечивается аутентификация потока шифрованного текста. Поскольку в МРРРЕ не предусмотрено другого способа аутентификации, атакующий может незаметно менять значения бит в шифре. Если протокол нижнего уровня чувствителен к изменению значения конкретных бит - разрешение/запрещение каких-либо функций, выбор вариантов, сброс параметров - эта атака может быть достаточно эффективна. Обратите внимание, для проведения этой атаки атакующему не надо знать ключ шифрования или пароль клиента. Конечно, такие атаки могут обнаруживаться или предотвращаться протоколами верхнего уровня.
Если в процессе передачи теряется пакет, либо приходит пакет с неверным номером в заголовке МРРЕ, то происходит ресинхронизация ключа. Сторона, принявшая неверный пакет, посылает отправителю запрос на ресинхронизацию. По принятию данного запроса, отправитель реинициализирует таблицы RC4 и устанавливает бит "сброшен" (flushed) в заголовке МРРЕ. Если система обнаруживает в пакете установленный бит "сброшен", она реинициализирует свои таблицы RC4 и устанавливает счетчик пакетов в соответствии с полученным значением.
Так
создается проблема, когда атакующий может
либо подавать запросы на ресинхронизацию,
либо вбрасывать пакеты МРРЕ с неверными
значениями счетчика пакетов. Если
выполнять это постоянно перед обменом 256-м
пактом, когда происходит смена сеансового
ключа, то атакующий может добиться успеха -
сеансовый ключ не будет изменен.
Несмотря на то, что атаки на протоколы MS-CHAP и МРРЕ приводят к полному отрицанию полезности и безопасности MS PPTP, необходимо упомянуть о нескольких интересных атаках.
Потрясающее количество информации можно получить, если просто наблюдать за трафиком сеанса РРТР, передаваемым по сети. Такая информация бесценна для анализа трафика, ее следует защищать. Тем не менее, сервер выдает всем желающим такие сведения, как максимальное количество доступных каналов. Эту информацию можно использовать для установки соответствующего размера сервера РРТР и контроля его нагрузки. Если атакующий регулярно передает пакеты PPTP_START_SESSION_REQUEST, то он может наблюдать создание новых соединений и закрытие существующих соединений. Таким способом атакующий может собрать информацию о системе и шаблонах ее использования, при этом ему не нужно быть рядом.
Путем
установки стандартных средств просмотра и
расшифровки общественных линий связи от
серверов Microsoft PPTP была получена следующая
информация:
В любом случае, когда канал связи шифруется и пользователь предполагает некоторый уровень конфиденциальности, перечисленная выше информация не должна быть доступна так легко. Для Microsoft PPTP нет легкого способа зашифровать эту информацию, поскольку утечки происходят вне канала, контролируемого МРРЕ. В некоторых случаях, эти пакеты представляют собой конфигурационные и установочные пакеты для шифрования в рамках МРРЕ, и они должны передаватьс до начала шифрования. Единственным решением является шифрование канала управления или резкое уменьшение количества передаваемой по нему информации.
Пакеты переговоров РРР передаются до начала шифрования и после его окончания. Поскольку метод ресинхронизации ключей осуществляется с использованием пакетов РРР ССР, эти каналы связи не могут шифроваться таким же образом. Добавим, что реальная аутентификация данных пакетов не выполняется. Этап конфигурации полностью открыт для атаки.
Подмена
конфигурационного пакета, описывающего DNS-сервер,
позволяет направить всю систему
распознавания имен на ложный сервер имен.
Точно
так же, подмена пакета, содержащего
внутренний туннельный IP-адрес, позволяет
обойти файрволы, осуществляющие фильтрацию
пакетов по правилам, поскольку клиент будет
подключаться к внешним машинам из
внутренней защищенной сети.
Реализация РРТР от Microsoft уязвима с точки зрения реализации, и обладает серьезными недостатками с точки зрения протокола. Протокол аутентификации имеет известные уязвимости, на которые указывалось не только здесь, но и в группах, например, L0pht. Шифрование выполнено неверно, в данной реализации используется поточный шифр с обратной связью по выходу, хотя более уместен был бы блоковый шифр "шифр-блок-цепочка" (CBC). Чтобы связать слабую аутентификацию с плохим шифрованием Microsoft задал ключ шифрования как функцию от пароля пользователя вместо использования сильного алгоритма обмена ключами типа Диффи-Хеллмана или ЕКЕ. Наконец, канал управления не аутентифицируется и не сильно защищен.
Хочется
подчеркнуть, что криптоанализ не подвергал
сомнению протокол РРТР, но лишь реализацию
протокола от Microsoft. Хотя Microsoft использует
свои собственные расширения (MS-CHAP, МРРЕ,
МРРС) в РРР секции РРТР, стандарт РРТР не
требует этого. Производители могут
включить расширения Microsoft в свои продукты
по соображениям совместимости, но они не
обязаны ограничиваться их использованием и,
наверное, реализуют более безопасные
решения. Конечно, новые расширения для
корректной работы должны поддерживаться
как клиентом, так и сервером.
Суть этого алгоритма заключается в следующем:
Данные преобразуются в цифровую форму путем замены символов значениями двоичных чисел таблицы ASCII и шифруются поблочно, размер блока (В) – 64 бита, он делится пополам на левую (L) и правую (R) части по 32 бита, на место левой части результирующего блока помещается правая часть исходного блока. Правая часть блока (Р) вычисляется как:
После этого блок (S) состоящий из R и P шифруется путем побитных замен и перестановок с помощью двоичной последовательности (ключа) длинной 64 бита, из которых 56 случайны, а 8 предназначены для контроля ключа.
Для повышения безопасности зашифрованного сообщения с помощью алгоритма DES, применяют его усиленный вариант, называемый "тройным DES", при этом длина ключа увеличивается с 56 бит до 168 бит, а значит, криптостойкость алгоритма повышается [1]. Но это приводит к снижению производительности, т. к. для шифрования требуется в три раза больше времени.
Метод шифрования с открытыми ключами RSA (Rivest, Shamir, Adieman) полностью отвечает всем принципам несимметричного алгоритма шифрования Диффи-Хеллмана и состоит в следующем:
-
Случайно
выбираются два очень больших простых числа
р и q.
-
Вычисляются
n
= р • q
m
= (р-1) • (q-1).
-
Выбирается
случайное целое число Е, не имеющее общих
сомножителей с m.
-
Находится
D такое, что
.
-
Исходный
текст, X, разбивается на блоки
0<Х<n.
-
Для
шифрования сообщения необходимо вычислить
.
-
Для
дешифрирования вычисляется
.
Сообщение
шифруется открытым ключом (Е, n), а
дешифрируется — закрытым (D, n).
Зная открытый ключ можно вычислить значение закрытого, но необходимо разложить на простые множители очень большое число n, а на это требуется очень много времени, например, для того чтобы найти разложение 200-значного числа, понадобится 4 миллиарда лет работы компьютера с быстродействием миллион операций в секунду.