Новая техника атаки на SSL/TLS, которой подвержены 33% HTTPS-сайтов
1 марта 2016 года
В выпущенных сегодня обновлениях библиотеки OpenSSL 1.0.1s и 1.0.2g устранена опасная уязвимость (CVE-2016-0800), позволяющая совершить новый вид атаки на HTTPS - DROWN. Уязвимость не специфична для OpenSSL и затрагивает непосредственно протокол SSLv2, который в 2011 году переведён в разряд устаревших и уже практически не используется. Тем не менее проблема остаётся актуальной, применима к защищённым сеансам TLS и затрагивает приблизительно 33% всех сайтов, доступных по HTTPS, или 25% из миллиона крупнейших сайтов в Сети (например, уязвим даже yahoo.com).
Атака позволяет вклиниться в шифрованный канал связи, если предварительно атакующим удалось получить контроль над промежуточным шлюзом или вынудить пользователя подключиться к подконтрольному атакующим серверу доступа (MITM). Завладев промежуточным шлюзом атакующий может притвориться HTTPS-сервером или почтовым сервером к которому обращается пользователь и получить полный контроль над шифрованным трафиком, принимая запросы от клиента и транслируя их к реальному серверу, организовав таким образом скрытое прослушивание и при необходимости внося изменения в трафик. Пользователь при этом не заметит подвоха и будет уверен в успешности установки защищённого соединения.
Суть уязвимости сводится к возможности расшифровки шифротекста RSA без знания закрытого ключа RSA. Проблеме подвержены серверы, в которых присутствует поддержка SSLv2, а также серверы на которых применяются закрытые ключи RSA, используемые совместно с сервером, поддерживающим SSLv2 (например, web-сервер можно атаковать, даже если он не поддерживает SSLv2, но использует один ключ с почтовым сервером, на котором доступен SSLv2). Уязвимость может применяться для организации кросс-протокольной атаки, нацеленной на расшифровку сеансов, в которых используются современные протоколы шифрования (TLSv 1.0 - 1.2), пользуясь тем, что обычно в TLS и в SSLv2 совместно используется один и тот же ключ RSA.
Атака достаточно сложна в реализации и требует стечения определённых факторов. Для восстановления одного сеансового ключа атакующему необходимо выполнить примерно 2^50 вычислительных операций (8 часов вычислений в облаке Amazon EC2, стоимостью $440) и инициировать несколько десятков тысяч соединений с целевым сервером. Подбор существенно упрощается и занимает около минуты в случае использования на сервере устаревших версий OpenSSL 1.0.2a, 1.0.1m, 1.0.0r и 0.9.8zf, для ускорения атаки на которые можно задействовать ранее исправленную уязвимость CVE-2016-0703.
Для защиты серверов достаточно полностью отключить протокол SSLv2 или все специфичные для SSLv2 наборы шифров (только в версиях OpenSSL новее 1.0.1r и 1.0.2f, в более ранних выпусках отключения шифров недостаточно, так как атакующий всё равно может воспользоваться ими в составе экспортного набора). В представленных сегодня релизах OpenSSL 1.0.2g и 1.0.1s поддержка SSLv2 полностью отключена на этапе сборки, а уязвимые наборы шифров удалены из поставки. LibreSSL, GnuTLS и NSS атаке не подвержены, так как собираются без поддержки SSLv2. Проверить свой сервер на наличие уязвимости можно на сайте test.drownattack.com (Архивная копия от 16 июня 2016 на Wayback Machine).
В новых выпусках OpenSSL также устранено несколько заслуживающих внимания узявимостей:
- Уязвимость (CVE-2016-0799) в реализации функций BIO_*printf, которая отнесена разработчиками OpenSSL к категории неопасных, но выявившие проблему исследователи не столь оптимистичны и не исключают теоретическую возможность инициирования выполнения кода атакующего при обработке в BIO_printf очень большого блока данных, полученного из не заслуживающего доверия источника (например, при выводе через BIO_printf данных, введённых пользователем). Функции BIO_*printf достаточно популярны и, например, используются в PHP и Apache httpd.
- Подверженность новой атаке по сторонним каналам (side-channel) CacheBleed (Архивная копия от 21 июля 2016 на Wayback Machine) (CVE-2016-0702), позволяющей восстановить содержимое 2048- или 4096-разрядного RSA-ключа, используя особенности обработки конфликтов в банках кэша процессоров на базе микроархитектуры Intel Sandy-Bridge. Для успешного восстановления ключа атакующий должен иметь локальный доступ к системе и добиться выполнения своего кода тем же ядром процессора (hyper-threaded), которое в текущий момент выполняет операцию дешифровки.
В процессе атаки моделируется содержимое кэша на основе измерения отклонения времени доступа к данным (при совпадении данные отдаются быстрее). Метод CacheBleed позволяет получить около 60% содержимого ключа 4096 RSA. На восстановление оставшихся данных требуется около двух часов процессорного времени (3 минуты вычислений на современном высокопроизводительном сервере). Уязвимость также присутствует в LibreSSL и в NSS.
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.