Атака TunnelVision, позволяющая перенаправить VPN-трафик через манипуляции с DHCP

Вниманию публики предложен метод атаки TunnelVision, позволяющий при наличии доступа к локальной сети или контроля над беспроводной сетью, осуществить перенаправление на свой хост трафика жертвы в обход VPN (вместо отправки через VPN, трафик будет отправлен в открытом виде без туннелирования на систему атакующего). Проблеме подвержены любые VPN-клиенты, не использующие изолированные пространства имён сетевой подсистемы (network namespace) при направлении трафика в туннель или не выставляющие при настройке туннеля правила пакетного фильтра, запрещающие маршрутизацию VPN-трафика через имеющиеся физические сетевые интерфейсы.

Суть атаки в том, что атакующий может запустить свой DHCP-сервер и использовать его для передачи клиенту информации для изменения маршрутизации. В частности, атакующий может воспользоваться предоставляемой в протоколе DHCP опцией 121 (RFC-3442, принят в 2002 году), предназначенной для передачи сведений о статических маршрутах, для внесения изменений в таблицу маршрутизации на машине жертвы и направления трафика в обход VPN. Перенаправление осуществляется через выставления серии маршрутов для подсетей с префиксом /1, которые имеют более высокий приоритет, чем применяемый по умолчанию маршрут с префиксом /0 (0.0.0.0/0), соответственно трафик вместо выставленного для VPN виртуального сетевого интерфейса, будет направлен через физический сетевой интерфейс на хост атакующего в локальной сети.

Атака может быть осуществлена в любых операционных системах, поддерживающих 121 опцию DHCP, включая Linux, Windows, iOS и macOS, независимо от используемого протокола VPN (Wireguard, OpenVPN, IPsec) и набора шифров. Платформа Android атаке не подвержена, так как не обрабатывает опцию 121 в DHCP. При этом атака позволяет получить доступ к трафику, но не даёт возможность вклиниться в соединения и определить содержимое, передаваемое с использованием защищённых протоколов уровня приложений, таких как TLS и SSH, например, атакующий не может определить содержимое запросов по HTTPS, но может понять к каким серверам они отправляются.

Для защиты от атаки можно запретить на уровне пакетного фильтра отправку пакетов, адресованных в VPN-интерфейс, через другие сетевые интерфейсы; блокировать DHCP-пакеты с опцией 121; использовать VPN внутри отдельной виртуальной машины (или контейнера), изолированной от внешней сети, или применять специальные режимы настройки туннелей, использующие пространства имён в Linux (network namespace). Для экспериментов с проведением атаки опубликован набор скриптов.

Можно отметить, что идея локального изменения маршрутизации не нова и ранее обычно использовалась в атаках, нацеленных на подмену DNS-сервера. В похожей атаке TunnelCrack, в которой перенаправление трафика осуществлялось через замену шлюза по умолчанию, проблема затрагивала все проверенные VPN-клиенты для iOS, в 87.5% VPN-клиентов для macOS, 66.7% для Windows, 35.7% для Linux и 21.4% для Android. В контексте VPN и DHCP метод также упоминался ранее, например, ему посвящён один из докладов на прошлогодней конференции USENIX 2023 (исследование показало, что 64.6% из 195 протестированных VPN-клиентов подвержены атаке).

Для подстановки маршрутов ранее также предлагалось использовать специально оформленный USB-брелок, симулирующий работу сетевого адаптера, который при подключении к компьютеру при помощи DHCP объявляет себя в качестве шлюза. Кроме того, при наличии контроля за шлюзом (например, при подключении жертвы к контролируемой атакующим беспроводной сети) была разработана техника подстановки пакетов в туннель, воспринимаемых в контексте сетевого интерфейса VPN.

Потоки данных при использовании VPN:

Потоки данных после совершения атаки:

Источник: opennet.ru