На конференциях Black Hat и DEF CON ИБ-специалист Ахамат Нафииз (Ahamed Nafeez) рассказал о проблеме VORACLE, которая при определенных условиях позволяет восстановить HTTP-трафик, переданный через VPN-подключение.

В сущности, VORACLE – это не новая атака, а новая вариация на тему уже известных криптографических проблем CRIMETIME и BREACH. Напомню, что тогда специалисты обнаружили, что могут восстановить данные, переданные посредством TLS-соединения, если скомпрометировать их до шифрования. Патчи для этих уязвимостей были опубликованы в 2012 и 2013 годах, и после этого HTTPS-соединения от подобных проблем не страдали.

Однако теперь Нафииз утверждает, что подобная атака по-прежнему может являться грозным оружием, есть обратить ее против некоторых типов VPN-трафика. Так, по словам эксперта, уязвимыми являются VPN клиенты и сервисы, которые сжимают трафик HTTP, перед тем как его зашифровать.

Исследователь объясняет, что атака VORACLE эффективна против VPN клиентов и сервисов, построенных на базе OpenVPN. Она позволяет расшифровать секреты HTTP-трафика, переданного посредством VPN. Основной целью такой атаки будет поиск чего-либо интересного, будь то cookie, страницы с приватной информацией или что-то иное.

Проблема заключается в том, что по умолчанию опенсорсный OpenVPN сжимает данные перед шифрованием TLS и затем пересылает через VPN-тоннель. Что отвечает условиям, необходимым для реализации атаки, подобной CRIME, TIME и BREACH.

По словам Нафииза, преступнику нужно только заманить свою жертву на HTTP-сайт. Такой ресурс может как принадлежать самому злоумышленнику, так и быть легитимным, однако атакующий в любом случае должен иметь возможность выполнить на сайте вредоносный код (к примеру, посредством зараженной рекламы). В результате успешной эксплуатации VORACLE, злоумышленник сможет перехватить и расшифровать секреты для данного ресурса, и с их помощью развить атаку далее, например, войдя на сайт от лица самого пользователя.

Защититься от атак VORACLE не так уж сложно. Так, достаточно не использовать протокол OpenVPN и держаться подальше от HTTP-сайтов, так как трафик HTTPS данная проблема не затрагивает. Более того, браузеры на базе Chromium тоже находятся вне опасности, так как они разделяют HTTP-запросы на несколько частей (header и body). Таким образом, атака опасна для пользователей Firefox, а пользователи Chrome могут работать с OpenVPN и заходить на HTTP-ресурсы, но все равно будут в безопасности.

Ахамат Нафииз уже уведомил о своей неприятной находке разработчиков OpenVPN  и некоторых VPN-провайдеров, а также обнародовал эксплоит для VORACLE на GitHub.

К сожалению, разработчики OpenVPN решили лишь изменить официальную документацию, прописав в ней более строгие предупреждения, относительно использования сжатия данных перед шифрованием. Но они не стали менять настройки по умолчанию для сжатия данных перед шифрованием, так как текущая схема имеет серьезное преимущество в вопросе производительности.

Провайдеры отнеслись к предупреждению эксперта серьезнее. Так, представители TunnelBear сообщили, что отключили поддержку сжатия на OpenVPN-серверах, а сотрудники Private Internet Access поблагодарили специалиста, но заметили, что и так не используют предварительное сжатие с 2014 года.

3 комментария

  1. ELForcer

    24.08.2018 at 07:37

    Я тоже отключил сжатие в OpenVPN, только по другой причине: из за сжатия сильно скачет пинг и иногда могут провалы. Без сжатия пинг более-менее ровный и провалов нет.

  2. Dronga

    27.08.2018 at 12:55

    Очень сомнительная публикация, больше похожая на сборник вредных советов. 1. Реклама Chrome (незаметно так соскочили с Chromium). 2. Антиреклама FireFox. 3. Антиреклама OpenVPN.
    По делу: Протокол HTTP в принципе предполагает Header и Body — в чем тут уникальность Chromium не понятно. Такова природа протокола. Сжатый HTTP-трафик естественно еще сложнее поддается анализу, особенно если в трафике есть еще что-то кроме HTTP в тех же направлениях и портах. Про то, что сжатие даёт серьезную фору в производительности — это уже совсем бред, понятный любому, кто хотя бы раз настраивал и использовал серверы PPTP/L2TP со сжатием. Всё это сжатие ложится на серверные и клиентские CPU, в трафике это давало примерно 2-3% меньший объем переданных данных, о какой производительности речь? Если ресурсы CPU явно не бесконечные, особенно на сервере (где еще тот же openvpnd крутится должен), то вот сетевая карточка со своими отдельными чипами прекрасно справится с несжатыми объемами. Правильно пишут про увеличивающийся пинг и подобные проблемы. Едем дальше — атакующий должен заманить жертву на страницу, на которой должен быть специальный вредоносный код.. То есть атака непосредственно на сжатый трафик не самодостаточна, то есть в сжатии как таковом уязвимости нет. Ну и вишенкой на торте — страница 404 на странице обнародованного эксплоита.

    Отдельное замечание про термины в статье — я не смог понять, что значит «секреты HTTP-трафика». Возможно имелись ввиду чувствительные данные в HTTP-трафике или что-то подобное. Пока это видится как крайне неудачный перевод крайне сомнительной публикации.

  3. Dronga

    27.08.2018 at 13:12

    Почитал оригинальный доклад — действительно перевод вышел совсем невнятный.

Оставить мнение