Уязвимость TLS Logjam — FREAK с DH

    image

    Исследователи из CNRS, Inria Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, Johns Hopkins University, University of Michigan и University of Pennsylvania обнаружили новую уязвимость в TLS, схожую с FREAK, но более опасную и применимую в реальной жизни — Logjam. В случае с Logjam, атака производится на сессионные ключи, которые устанавливаются во время обмена про протоколу Диффи-Хеллмана, с целью понижения их криптостойкости до 512-битных. Такие ключи, как показали исследователи FREAK, можно взломать в течение нескольких часов, однако здесь ситуация несколько иная: из-за того, что многое (устаревшее) ПО использует общедоступные статичные DH-группы и одни и те же предопределенные начальные простые числа, существует возможность предварительного выполнения дискретного логарифмирования методом решета числового поля до определенного состояния, которое позволяет быстро, в течение 2 минут, взломать сессионный ключ той DH-группы, для которой было сделано такое вычисление.

    Ученые произвели предварительный расчет для двух популярных экспортных DH-групп: первая группа используется в Apache в версиях 2.1.5-2.4.7 и встречается на 7% сайтов из TOP 1M по версии Alexa, а вторая зашита в OpenSSL, еще когда он назывался SSLeay, в 1995 году. Расчет занял неделю для каждой группы, и проводился он с использованием модифицированной версии CADO-NFS.
    По заявлению исследователей, предварительный расчет этих двух групп позволяет взламывать до 80% зашифрованных соединений на серверах, которые поддерживают экспортные DH-ключи. Были предложены и продемонстрированы на видео три способа проведения атаки:
    • Оффлайн-дешифрование слабых подключений для серверов, использующих 512-битные DH-ключи по умолчанию, при пассивном прослушивании трафика
    • Понижение стойкости ключей до 512-битных с использованием TLS False Start, путем MiTM-подмены отправляемых на сервер данных о типе DH
    • Понижение стойкости ключей до 512-битных путем MiTM-подмены отправляемых на сервер данных о типе DH, и приостановления соединения до момента взлома ключей

    Рассмотрим каждый из способов подробней. Первый способ применим только для тех серверов, которые используют 512-битные DH-группы по умолчанию. Таких серверов совсем немного, но для них не требуется выполнять атаку типа «человек посередине», а достаточно пассивно записывать трафик. После взлома ключа, трафик может быть расшифрован.

    Второй способ эксплуатирует особенность TLS False Start — специального механизма ускорения TLS-хендшейка, при котом клиент отправляет данные еще до момента завершения хендшейка (отправки Server Finished). Выполняя атаку типа «человек посередине», злоумышленник может подменить запрос клиента на использование DHE_EXPORT вместо DHE, сервер отдаст параметры для 512-битной DH-группы и открытый DH-ключ сервера (g^b), злоумышленник вернет клиенту ответ сервера с этими данными и записью, что это — DHE, как он и запрашивал. Из-за того, что стандарт не запрещает использовать 512-ключи в не экспортном варианте, клиент не видит подмены до момента отправки данных запроса (хеш не сойдется только в тот момент, когда сервер отправит Server Finished, но запрос клиента к тому времени уже отправился).

    image

    Третий тип атаки основан на приостановлении TLS-хендшейка на то время, которое потребуется на взлом сессионного ключа (по сообщению исследователей, до 10 минут с предварительным расчетом). Он также требует выполнения MiTM и подмены DHE на DHE_EXPORT и обратно, но не требует поддержки TLS Fast Start. Вот как это происходит:

    image

    1. Клиент соединяется с сайтом www.tcl.tk и предлагает хотя бы один набор шифров, который включает DHE, но не включает DHE_EXPORT.
    2. Злоумышленник перехватывает запрос и модифицирует, отправляя на сервер набор шифров, состоящий только из DHE_EXPORT
    3. Сервер выбирает DHE_EXPORT
    4. Атакующий модифицирует ответ сервера, подменяя DHE_EXPORT на один из не-экспортных вариантов DHE, предложенных клиентом
    5. Сервер отправляет параметры ключа с 512-битным основанием
    6. Хакер начинает взламывать ключ — вычислять дискретный логарифм, и разрывает соединение с сервером
    7. Клиент ждет, пока хакер взломает ключ и отправит ему подтверждение сервера
    8. Как только злоумышленник взламывает ключ, он получает master secret — ключ симметричного шифрования, и посылает подтверждение клиенту
    9. Клиент подтверждает данные от сервера и отправляет запрос. Злоумышленник может отвечать на запросы клиента.

    Исследователи обращают внимание, что злоумышленники с большим количеством мощного оборудования в состоянии восстановить 768-битные ключи, а спецслужбы могут восстанавливать и 1024-битные, которые часто применяются в IPsec IKEv1.

    Уязвимость имеется во всех популярных браузерах и почти во всем популярном серверном ПО. На сайте, посвященном уязвимости, описывается процесс генерации более стойких групп Диффи-Хеллмана, а также необходимые настройки TLS для Apache httpd, nginx, Microsoft IIS, Lighttpd, Apache Tomcat, Postfix, Sendmail, Dovecot и HAProxy. На этой же странице доступен чекер конфигурации серверов.

    Ученые сообщают, что уязвимости подвержено 8.4% сайтов из миллионного топа Alexa, а 1024-битные ключи используют 17.9% сайтов. Уязвимость также можно применить и на почтовых серверах в протоколах IMAPS (8.4%), POP3S (8.9%) и STARTTLS (14.8%). Кроме того, уязвимость можно эксплуатировать в не самых последних версиях OpenSSH.

    Сайт уязвимости
    PDF с подробным описанием уязвимости
    Конфигурация серверов и проверка корректной настройки
    Описание уязвимости от CloudFlare
    Прояснение ситуации с IPsec от разработчика Libreswan
    • +23
    • 14,2k
    • 4

    Digital Security

    124,00

    Безопасность как искусство

    Поделиться публикацией
    Комментарии 4
      0
      Получается, что при запрете EXPORT ciphersuites (что давно уже пора сделать всем) и использовании своих dhparams 2048 сервер этой атаке не подвержен.
        0
        Да, именно так и предлагают настраивать ПО авторы.
          0
          Пугает то, что про FREAK известно давно, а у огромного количества народа EXP до сих пор не запрещён и/или используются вшитые публично известные dhparams
        +3
        Вот у меня на сайтах параметры 4096-битные.
        В начале января уведомлял crypto.cat, что они используют дефолтные 1024-битные, и это при 4096-битном RSA. Спустя 2 месяца сообщение осталось без ответа, написал снова, и уже тогда исправили с комментарием, что я якобы считаю проблему серьёзнее, чем она есть на самом деле.
        А о том, что Chrome подвержен этой уязвимости, я сообщал в Google буквально за 3 дня до её публикации, демонстрировал на 768-битных параметрах. В мае 2015 года ВНЕЗАПНО выясняется, что использование параметров слабее 2048 бит небезопасно. Как будто о запрете 1024-битного RSA не слышали, или не додумали, что к DH это так же применимо. Новость из разряда «учёный изнасиловал журналиста» :(.
        Понижение стойкости ключей до 512-битных с использованием TLS False Start, путем MiTM-подмены отправляемых на сервер данных о типе DH
        Это гугловское уродство когда-нибудь умрёт? Наоптимизировали во вред совместимости и безопасности. Кстати, в начале января выяснилось, что этот же механизм уязвим к даунгрейду эфемерного ECDH до статического.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое