Атака DROWN - Википедия - DROWN attack

ТОНУТЬ
DROWN logo.svg
Сломанный логотип замка, символизирующий атаку DROWN
Идентификатор (ы) CVECVE-2016-0800
Дата открытияМарт 2016 г.; 4 года назад (2016-03)
ПервооткрывательНимрод Авирам, Себастьян Шинцель
Затронутое программное обеспечениеSSL (v2)
Интернет сайтутонуть.com

В ТОНУТЬ (Расшифровка RSA с устаревшим и ослабленным шифрованием) атака кросс-протокол ошибка безопасности атакует серверы, поддерживающие современный SSLv3 /TLS протоколы используя их поддержку устаревших, небезопасных, SSL v2 протокол для усиления атаки на соединения с использованием современных протоколов, которые в противном случае были бы безопасными.[1][2] DROWN может влиять на все типы серверов, которые предлагают услуги, зашифрованные с помощью SSLv3 / TLS, но все же поддерживают SSLv2, при условии, что они используют одни и те же учетные данные открытого ключа для двух протоколов.[3] Кроме того, если такой же сертификат открытого ключа используется на другом сервере, который поддерживает SSLv2, сервер TLS также уязвим из-за утечки информации ключа сервера SSLv2, которая может быть использована против сервера TLS.[3]

Полная информация о DROWN была объявлена ​​в марте 2016 года вместе с патчем, отключающим SSLv2 в OpenSSL; уязвимости был присвоен идентификатор CVE -2016-0800.[4] Одного патча будет недостаточно для предотвращения атаки, если сертификат можно найти на другом хосте SSLv2. Единственная действенная контрмера - отключить SSLv2 на всех серверах.

По оценкам исследователей, 33% всех HTTPS сайты были затронуты этой уязвимостью по состоянию на 1 марта 2016 года.[5]

Подробности

DROWN - это аббревиатура от «Расшифровка RSA с помощью устаревшего и ослабленного электронного шифрования».[6]Он использует уязвимость в сочетании используемых протоколов и конфигурации сервера, а не какую-либо конкретную ошибку реализации. По словам исследователей, уязвимость нельзя исправить путем внесения изменений в клиентское программное обеспечение, такое как веб-браузеры.[3]

Эксплойт включает в себя атака по выбранному зашифрованному тексту с использованием сервера SSLv2 в качестве Блейхенбахер оракул. SSLv2 работал путем непосредственного шифрования главного секрета с помощью RSA, а 40-битные экспортные шифровальные наборы работали, зашифровывая только 40-битный главный секрет и открывая остальные 88 бит в виде открытого текста. 48-байтовый зашифрованный RSA шифротекст SSLv3 / TLS «обрезается» до 40-битных частей и затем используется в сообщении SSLv2 ClientMasterKey, которое сервер обрабатывает как 40-битную часть главного секрета SSLv2 (остальные 88 битов могут быть любое значение, отправленное клиентом в виде открытого текста). Путем перебора 40-битного шифрования сообщение ServerVerify можно использовать в качестве оракула. Атака с подтверждением концепции продемонстрировала, как конфигурации с несколькими GPU и коммерческие облачные вычисления может выполнять часть вычислений взлома кода при стоимости установки графического процессора около 18 000 долларов США и стоимости атаки 400 долларов США для облака. Успешная атака предоставит сеансовый ключ для захваченного рукопожатия TLS.

Следователи, охарактеризовавшие нападение выше как общая атака DROWN также обнаружил конкретную слабость в реализации SSLv2 OpenSSL, которая позволяла то, что они называли специальный УТОН атака. Это значительно снизило усилия, необходимые для взлома шифрования, благодаря чему в реальном времени атаки человек-посередине возможно, для этого потребовались лишь скромные вычислительные ресурсы. Реализация SSLv2 в OpenSSL до 2015 года не проверяла правильность длины открытого и зашифрованного ключей, что позволяло, например, зашифровать только 8-битный главный секрет. До 2015 года OpenSSL также перезаписывал неправильные байты в главном секрете SSLv2 во время попытки контрмеры Блейхенбахера. До 2016 года OpenSSL также успешно согласовывал отключенные наборы шифров SSLv2. В отличие от SSLv3 и более поздних версий, в SSLv2 клиент должен был выбирать из списка шифровальных наборов, предлагаемых сервером, но OpenSSL позволял использовать не указанные в списке шифровальные наборы.

Первыми репортерами ошибки были исследователи безопасности Нимрод Авирам и Себастьян Шинцель.[7]

Смягчение

Для защиты от DROWN операторы серверов должны гарантировать, что их закрытые ключи нигде не используются с серверным программным обеспечением, которое разрешает соединения SSLv2. Сюда входят веб-серверы, серверы SMTP, серверы IMAP и POP, а также любое другое программное обеспечение, поддерживающее SSL / TLS.[8]

В OpenSSL group выпустила рекомендации по безопасности и набор исправлений, предназначенных для уменьшения уязвимости за счет удаления поддержки устаревших протоколов и шифров.[9] Однако, если сертификат сервера используется на других серверах, поддерживающих SSLv2, он по-прежнему уязвим, как и исправленные серверы.

Многие источники рекомендуют операторам сайтов как можно скорее исправить уязвимость.

Рекомендации

  1. ^ Лейден, Джон (1 марта 2016 г.). «Треть всех HTTPS-сайтов открыта для атаки DROWN». Реестр. Получено 2016-03-02.
  2. ^ Гудин, Дэн (1 марта 2016 г.). «Более 11 миллионов веб-сайтов HTTPS подверглись опасности новой атаки дешифрования». Ars Technica. Получено 2016-03-02.
  3. ^ а б c Нимрод Авирам, Себастьян Шинцель, Юрай Соморовский, Надя Хенингер, Майк Данкель, Йенс Штойбе, Люк Валента, Дэвид Адриан, Дж. Алекс Халдерман, Виктор Духовни, Эмилия Кеспер, Шаанан Кохни, Сюзанна Энгельс, Кристоф Паар и Юваль Шавитт. DROWN: нарушение TLS с использованием SSLv2, 2016
  4. ^ "Сводка уязвимостей национальной системы киберпространства для CVE-2016-0800". web.nvd.nist.gov. Получено 2016-03-02.
  5. ^ «Утопленная атака». drownattack.com. Получено 2016-03-24.
  6. ^ «Новая атака расшифровки TLS затрагивает каждый третий сервер из-за поддержки устаревшего SSLv2». PCWorld. Получено 2016-03-02.
  7. ^ «DROWN - Межпротокольная атака на TLS с использованием SSLv2 - CVE-2016-0800 - Портал для клиентов Red Hat». access.redhat.com. Получено 2016-03-02.
  8. ^ «Утопленная атака». 1 марта 2016 г.
  9. ^ «Межпротокольная атака на TLS с использованием SSLv2 (DROWN) (CVE-2016-0800)». OpenSSL. 1 марта 2016 г.

внешняя ссылка