DHCP Option 121 та вразливість TunnelVision: захист маршрутизації VPN

На панелі завдань операційної системи відображається активне зашифроване з'єднання віртуальної приватної мережі (VPN). Віртуальний адаптер успішно передає пакети, криптографічні сесії WireGuard функціонують у штатному режимі, а вбудований перемикач блокування (Kill Switch) сигналізує про повну готовність до захисту. Проте під час роботи у відкритій мережі Wi-Fi кожен HTTP-запит, DNS-виклик та конфіденційні дані непомітно спрямовуються безпосередньо до шлюзу зловмисника у вигляді звичайних відкритих Ethernet-кадрів.

Ця техніка викриття мережевого трафіку зареєстрована як вразливість CVE-2024-3661 і отримала назву TunnelVision. Дослідники з Leviathan Security Group з'ясували, що TunnelVision не спирається на помилки переповнення буфера чи недоліки математичного шифрування. Атака експлуатує стандартну функцію керування протоколу динамічного налаштування вузла (DHCP), стандартизовану ще 2002 року: опцію DHCP Option 121 (специфікація RFC 3442, The Classless Static Route Option).

Впроваджуючи спеціальні записи статичної маршрутизації під час отримання локальної IP-адреси, зловмисник у межах тієї самої локальної мережі (LAN) маніпулює таблицею маршрутизації ядра операційної системи, виводячи трафік за межі зашифрованого тунелю без розриву самого з'єднання VPN.

[Програма користувача / Браузер]
                  │
                  ▼
   [Таблиця маршрутизації ядра ОС]
   ┌─────────────────────────────┐
   │ Оцінка правил за префіксом  │
   └─────────────┬───────────────┘
                 │
   ┌─────────────┴───────────────────────────────┐
   │                                             │
[Маршрут за замовчуванням VPN]    [Впроваджені маршрути Option 121]
  Префікс: 0.0.0.0/0 (Метрика 1)    Префікс: 0.0.0.0/1 + 128.0.0.0/1
  Інтерфейс: tun0 (Зашифровано)     Інтерфейс: wlan0 (Відкритий фізичний)
   │                                             │
   │ (Ігнорується: коротший префікс)             │ (Обирається: довший префікс!)
   │                                             ▼
   ▼                                [Фальшивий шлюз перехоплення даних]
[Надійний сервер VPN]                 (Читання відкритого трафіку жертви)

Механізм TunnelVision: дія правила Longest Prefix Match

Щоб зрозуміти, чому TunnelVision нівелює захист стандартних клієнтів VPN, слід звернутися до фундаментального алгоритму передавання IP-пакетів: правила вибору найдовшого префікса (Longest Prefix Match — LPM).

Коли мережевий стек ядра ОС визначає маршрут для вихідного пакета, він зіставляє IP-адресу призначення з усіма правилами таблиці маршрутизації. Якщо адресі відповідають кілька записів, система зобов'язана обрати правило з найбільш специфічною маскою підмережі (найбільшою кількістю бітів префікса), не беручи до уваги показники метрики чи віртуальний статус інтерфейсу.

Більшість програм VPN перехоплюють вихідні дані шляхом встановлення маршруту за замовчуванням (Default Route):

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        0.0.0.0         UG    50     0        0 tun0

Маршрут 0.0.0.0/0 охоплює весь простір адрес глобальної мережі, однак довжина його префікса становить 0 бітів (/0), що робить його найменш специфічним у таблиці.

Під час підключення до ненадійної точки Wi-Fi пристрій надсилає широкомовний пакет DHCP Discover. Фальшивий DHCP-сервер зловмисника надсилає відповідь DHCP Offer із доданою опцією Option 121. За стандартом RFC 3442, це дає змогу серверу передати клієнтові безкласові статичні маршрути безпосередньо в системну таблицю.

Атакувальний вузол призначає два маршрути, які разом охоплюють увесь адресний простір IPv4:

0.0.0.0/1 через локальний шлюз 192.168.1.1 (діапазон від 0.0.0.0 до 127.255.255.255)
128.0.0.0/1 через локальний шлюз 192.168.1.1 (діапазон від 128.0.0.0 до 255.255.255.255)

Оскільки префікс /1 довший за префікс /0, ядро операційної системи беззастережно скеровує вихідні пакети через фізичний бездротовий інтерфейс wlan0. Трафік залишає пристрій у відкритому вигляді, даючи змогу стороннім особам фіксувати передані дані.

+--------------------------+-----------------+--------------------+------------------------+
| Запис маршрутизації      | Довжина префікса| Інтерфейс виходу   | Пріоритет застосування |
+--------------------------+-----------------+--------------------+------------------------+
| Маршрут за замовчуванням | /0 (Загальний)  | tun0 (Шифрований)  | Перекривається маскою/1|
| Option 121 (0.0.0.0/1)   | /1 (Детальний)  | wlan0 (Відкритий)  | Обирається (1-ша част.)|
| Option 121 (128.0.0.0/1) | /1 (Детальний)  | wlan0 (Відкритий)  | Обирається (2-га част.)|
| Точний хост (/32)        | /32 (Абсолютний)| wlan0 (Відкритий)  | Найвищий пріоритет     |
+--------------------------+-----------------+--------------------+------------------------+

Чому класичні механізми Kill Switch виявляються безпорадними

Багато користувачів сподіваються, що аварійний вимикач мережі (Kill Switch) гарантує захист від будь-яких витоків. Проте більшість таких рішень проєктувалися для реагування на розрив зв'язку, а не на підміну таблиць маршрутизації:

Перевірка стану тунельного драйвера: Традиційний Kill Switch лише стежить за працездатністю віртуального адаптера (tun0). Під час атаки TunnelVision сесія VPN не переривається, пакети перевірки доступності надходять регулярно, і захисний вимикач не спрацьовує.
Винятки для локального сегмента мережі: Щоб зберегти доступ до локальних принтерів чи мережевих сховищ NAS, системні брандмауери зазвичай дозволяють передавання даних усередині локальної мережі. Опція 121 маскує звернення до Інтернету під локальні маршрути, тому брандмауер без перешкод випускає відкриті пакети.
Стандартні налаштування операційних систем: Windows та багато дистрибутивів Linux за замовчуванням автоматично застосовують маршрути з опції DHCP 121 без сповіщення користувача, створюючи умови для прихованого перенаправлення трафіку.

Системні рівні захисту від витоків маршрутизації

Для нейтралізації загрози TunnelVision необхідно застосовувати структурну ізоляцію мережевих потоків на рівні операційної системи.

[Користувацькі програми (Браузер, Пошта, Термінал)]
                        │
                        ▼
       [Простір імен мережі (Network Namespace)] <── (Повна ізоляція)
                        │
                        ▼
             [Інтерфейс tun0 / wg0]
                        │ (Зашифрований потік WireGuard)
                        ▼
 [Фізичний простір: wlan0] ──> [Вихід лише для зашифрованих пакетів]

1. Мережеві простори імен (Network Namespaces)

У середовищі Linux використання просторів імен створює надійне розмежування. Запускаючи клієнтські програми у відокремленому просторі імен, що містить виключно віртуальний інтерфейс VPN (wg0 або tun0), система повністю приховує фізичний адаптер wlan0. Навіть якщо шкідливий DHCP-сервер додасть статичні маршрути до головної таблиці ОС, ізольовані програми не зможуть скористатися цими шляхами.

2. Маршрутизація на основі політик (PBR) та мітки брандмауера

Сучасні інструменти WireGuard (wg-quick) застосовують маркування пакетів через механізм брандмауера (fwmark):

# Перенаправлення немаркованого трафіку до окремої таблиці 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

Параметр suppress_prefixlength 0 не дозволяє основній таблиці маршрутизації перехоплювати пакети за допомогою детальніших правил, примусово скеровуючи трафік через тунель.

3. Блокування обробки Option 121 у налаштуваннях DHCP

На робочих станціях можна вимкнути автоматичний прийом маршрутів у конфігурації клієнта DHCP (/etc/dhcp/dhclient.conf), видаливши запит параметра rfc3442-classless-static-routes.

4. Апаратне та драйверне блокування у RiceGuard

Протокол RiceGuard платформи VPNRice розв'язує проблему підміни маршрутів безпосередньо на рівні драйвера ядра. Завдяки правилам фільтрації nftables/eBPF система негайно відкидає будь-які незашифровані пакети, адресовані зовнішнім вузлам, якщо вони намагаються вийти через фізичний інтерфейс повз встановлений тунель.