DROWN: атака на TLS как следствие уязвимости SSLv2 (CVE-2016-0800)

Центр безопасности Red Hat предупреждает об уязвимости протокола SSLv2, которой было присвоено название DROWN (Decrypting RSA using Obsolete Weakened eNcryption) и назначен код CVE-2016-0800.

Обзор

Группой исследователей в области информационной безопасности была обнаружена уязвимость протокола SSLv2 (Secure Sockets Layer 2.0) перед разновидностью атаки Блейбенбахера, направленной на интерпретацию шифротекста RSA без доступа к закрытому ключу RSA. Это достигается путем многократной передачи серверу поддельных данных, которые он будет расшифровывать с помощью имеющегося у него закрытого ключа, и отслеживания его ответа. Исследователи также продемонстрировали кросс-протокольную модификацию атаки, являющуюся прямым следствием уязвимости в SSLv2, в ходе которой были расшифрованы данные сеанса SSL/TLS, использующего и более современные протоколы — SSLv3 и текущие версии TLS 1.0 - 1.2. Главной причиной является уязвимость в SSLv2, которой оказались подвержены все реализации протокола. В ходе изучения эта атака была классифицирована как общая.

Помимо этого, были идентифицированы другие недостатки в реализации SSLv2 в библиотеке OpenSSL, что позволило смоделировать более изощренную вариацию DROWN, которую классифицировали как специализированную. Обе версии DROWN получили идентификаторы CVE-2016-0703 и CVE-2016-0704 и были устранены в рамках CVE-2015-0293.

Дальнейшую информацию можно найти в исследовательском докладе DROWN: Breaking TLS using SSLv2.

Описание

О небезопасности протокола SSLv2 было известно давно, что еще в 1996 году послужило основанием для его замены версией SSLv3. Протокол SSLv2 был официально переведен в разряд устаревших в 2011 году в соответствии с RFC 6176, и на сегодняшний день его применение ограничено, так как современные клиенты SSL/TLS либо окончательно отказались от его поддержки, либо предпочитают более новые версии. Тем не менее многие серверы SSL/TLS продолжают его поддерживать, что позволяет им принимать соединения даже от очень старых реализаций клиентов, но оставляет место для уязвимости. До обнаружения DROWN в отключении SSLv2 прямой необходимости не было, так как это не представляло угрозы для информационной безопасности.

Уязвимые конфигурации

Сервер является уязвимым, если он использует криптосистему RSA и поддерживает протокол SSLv2 в дополнение к SSLv3 и TLSv1.x. Сервер, на котором SSLv2 отключен, также может оказаться косвенно уязвимым, если он допускает совместное использование своего закрытого ключа RSA с другим сервером или сервисом, поддерживающим уязвимый SSLv2. Так, например, вектор атаки DROWN может быть направлен на расшифровку HTTPS-трафика, даже если на веб-сервере SSLv2 отключен, но используется один RSA-ключ на двоих с IMAP-сервером, который работает на том же узле, но поддерживает SSLv2.

Соединения SSL/TLS, использующие другие алгоритмы криптографии — Диффи-Хеллмана или Диффи-Хеллмана на эллиптических кривых — не подвержены опасности.

Описание

атаки и оценка последствий

В ходе изучения потенциальных методов эксплуатации уязвимости было выделено несколько этапов атаки DROWN:

• Нарушитель отслеживает определенное число сеансов связи SSL/TLS между клиентом и сервером, использующих наборы шифров RSA и любую версию протокола. Практика показала, что порядка 1000 сеансов оказалось достаточно для того, чтобы в конце концов удалось расшифровать один из них.

• Далее нарушитель многократно инициирует соединение SSLv2 с сервером. В некоторых случаях ему придется прибегнуть к методу прямого перебора для взлома 40-битного (экспортного) или 56-битного (по алгоритму DES) ключа сеанса. Исследователи оценили, что для его восстановления потребовалось инициировать около 40 тысяч соединений.

• После этого нарушитель сможет расшифровать предварительный код PreMasterSecret из одного из ранее записанных рукопожатий — это все, что необходимо для генерации симметричных ключей и полной расшифровки обмена данными соответствующего сеанса SSL/TLS, в ходе которого дополнительно могут быть извлечены конфиденциальные данные, в том числе данные аутентификации или файлы cookie.

По утверждению исследователей, при установке соединения TLS 1.2 с сервером им удалось полностью восстановить RSA-ключ длиной 2048 бит после отслеживания 1000 рукопожатий, 40 000 соединений SSLv2 и 2⁵⁰ вычислительных операций в автономном режиме. На проведение успешной атаки ушло меньше 8 часов с использованием ресурсов публичного облачного провайдера со стоимостью аренды в 440 у.е.

Также было обнаружено, что специализированная атака DROWN способна снизить необходимое количество соединений SSLv2 до 14 000 и может быть успешно реализована на обычной рабочей станции менее чем за 3 минуты. Такой результат значительно увеличивает риск активного MITM-перехвата данных атакующей стороной, после чего она сможет себя выдавать за TLS-сервер.

Библиотеки SSL и TLS с поддержкой SSLv2

Продукты Red Hat включают компоненты, поддерживающие протокол SSLv2. Активация поддержки SSLv2 может происходить исходя из особенностей взаимодействия приложений с библиотеками SSL/TLS.

SSLv2 в OpenSSL

Для того чтобы сообщить OpenSSL версию SSL/TLS, с которой будут работать приложения, необходимо явно выбрать метод соединения. OpenSSL позволяет выбрать как отдельную версию протокола, так и специальный метод SSLv23, допускающий использование любых поддерживаемых версий протокола — в том числе и SSLv2. Второй вариант наиболее распространен, поэтому для обеспечения защиты приложений необходимо запретить понижение версии протокола, установив опцию SSL_OP_NO_SSLv2 для соответствующих объектов SSL_CTX и SSL. Некоторые приложения по умолчанию именно так и делают, в то время как другие принимают стандартный выбор, тем самым активируя уязвимый SSLv2. Принимая это во внимание, можно предположить, что большинство приложений, использующих OpenSSL, работают с активной поддержкой SSLv2 и подвержены риску.

В целях обеспечения необходимого уровня защиты продуктов Red Hat библиотека OpenSSL подверглась следующим изменениям:

• Протокол SSLv2 больше не активируется при выборе SSLv23.
• Были исключены наборы шифров SSLv2, использующие 40-битные (EXPORT) и 56-битные (DES) ключи симметричного шифрования:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• Все версии пакета openssl для Red Hat Enterprise Linux 4 и 5 проверяют состояние переменной окружения OPENSSL_ENABLE_SSL2, так как она именно она разрешает использование SSLv2 при выборе метода соединения SSLv23.

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

Также следует отметить, что несмотря на то, что наборы шифров SSLv2 были исключены из списка шифров DEFAULT для OpenSSL в Red Hat Enterprise Linux 6 и 7, это не запрещает серверу принимать соединения SSLv2 от клиентов. Этот дефект был отдельно идентифицирован как CVE-2015-3197 и исправлен в обновлениях, закрывающих уязвимость DROWN.

SSLv2 в NSS (Network Security Services)

Криптографическая библиотека NSS поддерживает протокол SSLv2, но включает его только по запросу приложений. Более того, версии NSS, входящие в дистрибутив Red Hat Enterprise Linux 7, полностью запрещают применение SSLv2, поэтому, скорее всего, приложения, работающие с библиотекой NSS, не будут поддерживать SSLv2.

Так как в NSS поддержка SSLv2 по умолчанию отключена, срочный выпуск исправлений для NSS не планируется. В будущих выпусках Red Hat Enterprise Linux 6 протокол SSLv2 будет отключен аналогично тому, как это сделано в Red Hat Enterprise Linux 7.

Библиотеки SSL и TLS без поддержки SSLv2

Ниже перечислены продукты Red Hat, содержащие компоненты с той или иной реализацией TLS или SSL, но исключающие поддержку SSLv2. И хотя сами по себе они не являются уязвимыми, взаимодействующие с ними приложения все же могут быть подвержены опасности — если они используют один RSA-ключ совместно с приложениями, которые обращаются к библиотеке SSL/TLS, поддерживающей уязвимый протокол SSLv2.

• GnuTLS
• OpenJDK (java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Решение

Red Hat рекомендует своим пользователям провести анализ и приоритизацию рисков для находящихся в их распоряжении систем и принять немедленные меры предосторожности, установив доступные исправления. Перезагрузка компьютера является наиболее надежным способом применения изменений, гарантирующим, что каждый сервис будет использовать обновленную библиотеку OpenSSL. Если же полная перезагрузка системы не представляется возможной, после установки обновлений надо будет перезапустить все службы, так или иначе взаимодействующие с OpenSSL.

Благодарности

Red Hat благодарит проект OpenSSL за предоставление информации об этой уязвимости, который, в свою очередь, отмечает вклад Нимрода Авирама (Nimrod Aviram) и Себастьяна Шинцеля (Sebastian Schinzel), которые первыми ее обнаружили.

Вопросы и ответы

Как отключить SSLv2 в приложении X?

Обратитесь к статье Securing Application 'X' in RHEL 'Y' ? за информацией об изменении настроек SSL/TLS, в том числе об управлении версиями протокола в приложениях Red Hat Enterprise Linux.

Означает ли это необходимость в генерации новых ключей и сертификатов сервера?

Нет. Вектор атаки DROWN направлен на перехват индивидуальных ключей сеансов, генерируемых на этапе переговоров TLS/SSL, что позволяет расшифровать отдельные сеансы TLS/SSL, но не может напрямую скомпрометировать RSA-ключи. Даже если ваши сервисы подверглись атаке, в генерации новых закрытых ключей и сертификатов необходимости нет.

А что насчет поддержки SSLv2 веб-сервером Apache httpd, входящим в состав дистрибутивов Red Hat?

Apache httpd может использовать один из двух модулей для обслуживания HTTPS:

• mod_ssl — использует криптографическую библиотеку OpenSSL и входит в комплект веб-сервера Apache httpd.
• mod_nss — использует криптографическую библиотеку NSS и распространяется независимо от Apache httpd.

Оба модуля представлены в продуктах Red Hat.

Стандартные настройки httpd с mod_ssl:

• Версии httpd, предлагаемые в Red Hat Enterprise Linux 7, в коллекцииhttpd24 из Red Hat Software Collections, а также в Red Hat JBoss Web Server 3, построены на основе httpd 2.4 и не поддерживают SSLv2.

• Версии httpd, предлагаемые в составе дистрибутивов Red Hat Enterprise Linux 5 и 6, Red Hat JBoss Web Server 1 и 2, а также Red Hat JBoss Enterprise Application Platform 6 , построены на основе httpd 2.2. Эта версия хоть и не запрещает использование протокола SSLv2, но по умолчанию его отключает, о чем свидетельствует наличие директивы в файле /etc/httpd/conf.d/ssl.conf:

SSLProtocol all -SSLv2

• Версии httpd, предлагаемые в составе Red Hat Enterprise Linux 4, построены на основе httpd 2.0. Эта версия по умолчанию разрешает использовать протокол SSLv2, однако его можно отключить, добавив вышеуказанную директиву SSLProtocol в /etc/httpd/conf.d/ssl.conf и перезапустив httpd.

Стандартные настройки httpd с mod_nss:

• Версии mod_nss, предлагаемые в составе дистрибутивов Red Hat Enterprise Linux 5, 6, и 7, по умолчанию отключают SSLv2. В зависимости от установленной версии пакета mod_nss, в файле конфигурации будет присутствовать одна из указанных далее директив, разрешающих использование SSLv3 или TLSv1.0 и их более поздних версий:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

ПРИМЕЧАНИЕ. В силу известных проблем с протоколом SSLv3 мы также рекомендуем его отключить. Подробную информацию можно найти в статье POODLE: уязвимость SSLv3 (CVE-2014-3566).

Поддерживается ли SSLv2 почтовыми серверами SMTP в Red Hat Enterprise Linux?

Стандартная конфигурация серверов Postfix и Sendmail в Red Hat Enterprise Linux 5, 6 и 7 по умолчанию запрещает шифрование SSL/TLS.

Если же администратор предпочел активировать SSL/TLS для Postfix, это разрешит поддержку SSLv2 для оппортунистического шифрования, но запретит для обязательного шифрования. В Red Hat Enterprise Linux 6 и 7 выбор SSLv2 для оппортунистического метода шифрования можно запретить, установив опцию smtpd_tls_protocols.

Включая SSL/TLS для Sendmail, администратор автоматически разрешает использование SSLv2. В Red Hat Enterprise Linux 5, 6 и 7 поддержку SSLv2 можно отключить с помощью опции ServerSSLOptions.

В приведенной выше секции Как отключить SSLv2 в приложении X? приведены ссылки на ресурсы, где управление конфигурацией SSL/TLS для Postfix и Sendmail обсуждается более подробно.

Нужно ли обновлять существующую установку EAP 6.4?
Для EAP может быть настроен как нативный провайдер безопасности APR/OpenSS, так и Java-провайдер JSSE. Если в вашем окружении используется APR/OpenSSL, необходимо принять меры предосторожности:

• Red Hat Enterprise Linux
  Обновите OpenSSL.
• Windows и Solaris
  Обновленные библиотеки openssl будут доступны на сервисной платформе клиента. Обновления затрагивают библиотеки libssl, libeay и само приложение openssl.

Результаты тестирования EAP 6.4 на Windows с APR/OpenSSL показали, что несмотря на то, что библиотека OpenSSL уязвима и требует обновления, EAP 6.4 по умолчанию использует TLSv1 и отклоняет запросы обслуживания SSLv2 и SSLv3, вследствие чего можно утверждать, что в настоящее время EAP не подвергается опасности.

Нужно ли обновлять существующую установку EAP 5.2?
Для EAP может быть настроен как нативный провайдер безопасности APR/OpenSS, так и Java-провайдер JSSE. Если в вашем окружении используется APR/OpenSSL, необходимо принять меры предосторожности:

• Red Hat Enterprise Linux
  Обновите OpenSSL.
• Windows и Solaris
  Обновленные библиотеки openssl будут доступны на сервисной платформе клиента. Обновления затрагивают библиотеки libssl, libeay и само приложение openssl.

В настоящее время EAP 5.2 проходит тестирование на Windows с целью оценки рисков.

Нужно ли обновлять существующую установку EWS 2.1?
Эта уязвимость затрагивает те установки Windows и Solaris, для которых в качестве провайдера безопасности настроен APR/OpenSSL. В настоящее время EWS 2.1 поддерживает и SSLv2, и SSLv3.
При наличии провайдера Apr/OpenSSL необходимо выполнить следующее:

• Red Hat Enterprise Linux
  Обновите OpenSSL.
• Windows и Solaris
  Обновленные библиотеки openssl будут доступны на сервисной платформе клиента. Обновления затрагивают библиотеки libssl, libeay и само приложение openssl.

A: Да. EWS 2.1 является уязвимым, поэтому для него необходимо установить последние обновления. Эта уязвимость затрагивает только те установки Windows и Solaris, для которых в качестве провайдера безопасности настроен APR/OpenSSL. Стандартная конфигурация JSSE не подвержена риску. Обновления будут доступны на сервисном портале.

Нужно ли обновлять существующую установку EWS 3.0.2?
Эта уязвимость затрагивает те установки Windows и Solaris, для которых в качестве провайдера безопасности настроен APR/OpenSSL. В настоящее время EWS 3.0.2 поддерживает SSLv2 и SSLv3. Поддержка этих протоколов будет исключена из следующей версии EWS 3.0.3.

При наличии провайдера Apr/OpenSSL необходимо выполнить следующее:

• Red Hat Enterprise Linux
  Обновите OpenSSL.
• Windows и Solaris
  Обновленные библиотеки openssl будут доступны на сервисной платформе клиента. Обновления затрагивают библиотеки libssl, libeay и само приложение openssl.

Каков статус пакета tomcat-native?

Tomcat-native использует системные библиотеки OpenSSL и сам по себе не является уязвимым.