Багато користувачів вважають, що увімкнення захищеного тунелю віртуальної приватної мережі автоматично убезпечує всі дані завдяки стійким алгоритмам шифрування. Сучасні криптографічні примітиви, зокрема ChaCha20-Poly1305 та AES-256-GCM, забезпечують математично доведений захист корисної інформації від перехоплення у фізичному середовищі. Проте криптографія ніколи не вирішує, куди саме спрямовувати пакети. Це рішення ухвалює виключно таблиця маршрутизації ядра операційної системи.

У 2023 році група фахівців із безпеки у складі Маті Ванхуфа, Нянь Сюе, Яшасві Малла, Цзихана Сяо та Крістіни Ніта-Ротару оприлюднила дослідження критичного архітектурного недоліку, що отримав назву TunnelCrack. Зареєстровані під кодами CVE-2023-36664 та CVE-2023-35838, ці сценарії демонструють, як ненадійна локальна мережа або підроблена точка доступу Wi-Fi може маніпулювати правилами маршрутизації, змушуючи цільовий трафік проходити повз зашифрований тунель у відкритому вигляді.

Для повного розуміння механізмів TunnelCrack слід детально проаналізувати два головні вектори: атаку LocalNet та атаку ServerIP.

+-----------------------------------------------------------------------------+
|                     СХЕМА ВИТОКУ МАРШРУТИЗАЦІЇ LOCALNET                     |
|                                                                             |
|  [Пристрій користувача]                                                     |
|         │                                                                   |
|         ├── Призначення: Публічна IP-адреса (наприклад, 142.250.190.46)     |
|         │                                                                   |
|         ▼                                                                   |
|  [Рішення таблиці маршрутизації ядра]                                       |
|         │                                                                   |
|         ├─► Маршрут А: Стандартний тунель VPN (0.0.0.0/1 через utun0)       |
|         │                                                                   |
|         └─► Маршрут Б: Локальна підмережа LocalNet (142.250.0.0/16 wlan0)   |
|                    (Пріоритет за найдовшим збігом префікса LPM)             |
|                                                                             |
|         ▼                                                                   |
|  [Фізичний адаптер: wlan0] ─────────────────► [Маршрутизатор Wi-Fi атаки]   |
|  (Нешифровані кадри Ethernet виходять назовні)(Перехоплення відкритих даних)|
+-----------------------------------------------------------------------------+

Атака LocalNet (CVE-2023-36664): зловживання винятками локальної мережі

Вразливість LocalNet виникає через функцію спільного доступу до ресурсів локальної мережі, присутню в багатьох клієнтських додатках. Працюючи вдома або в офісі, користувачі часто мають потребу друкувати на мережевих принтерах, звертатися до файлових сховищ NAS або транслювати медіа на смарт-пристрої. Щоб забезпечити таку взаємодію, операційні системи зберігають прямі маршрути канального рівня для локальної підмережі.

Під час підключення до бездротової мережі сервер DHCP передає мережеву конфігурацію: призначену IP-адресу, маску підмережі та шлюз. За стандартних умов використовується приватний діапазон RFC 1918, наприклад 192.168.1.0/24. Ядро автоматично додає запис:

192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

Завдяки параметру scope link ядро розуміє, що трафік для 192.168.1.0/24 надсилається локально без залучення зовнішнього шлюзу. Клієнтське програмне забезпечення залишає цей маршрут активним або додає його до таблиці винятків.

Зловмисник, який керує фальшивою точкою доступу, маніпулює цією поведінкою, оголошуючи довільний публічний діапазон адрес локальною мережею. Наприклад, скомпрометований сервер DHCP призначає пристрою адресу з блоку 142.250.0.0/16 із маскою 255.255.0.0:

# Ядро встановлює прямий локальний маршрут для публічного блоку на карті Wi-Fi
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45

Коли користувач відкриває веббраузер або фонові сервіси звертаються до сервера з цього діапазону, ядро звіряє базу даних пересилання (FIB). За правилами стандартної маршрутизації IP:

  1. Віртуальний інтерфейс тунелю зазвичай налаштовує спарені маршрути за замовчуванням із префіксом /1 (0.0.0.0/1 та 128.0.0.0/1).
  2. Впроваджений локальний маршрут має префікс /16, який є значно точнішим за префікс /1.
  3. За правилом найдовшого збігу префікса (Longest Prefix Match) перевага надається маршруту /16.

Як наслідок, ядро надсилає відкритий IP-пакет через фізичний інтерфейс wlan0. Захищений тунель не використовується для цього сеансу, що дає змогу зловмиснику вільно перехоплювати відкритий трафік та запити DNS.

Атака ServerIP (CVE-2023-35838): маніпуляція системними маршрутами шлюзу

Якщо LocalNet використовує підміну масок підмереж, то ServerIP експлуатує фундаментальну вимогу ініціалізації самого протоколу захищеного зв'язку.

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

Щоб запобігти цьому замкненому колу, клієнти додають явний маршрут вузла (/32 для IPv4 або /128 для IPv6) до фізичного шлюзу перед увімкненням віртуального інтерфейсу:

# Прямий маршрут до віддаленого сервера через локальний фізичний роутер
198.51.100.50/32 via 192.168.1.1 dev wlan0

Вразливість ServerIP виникає, коли ім'я сервера резолвиться через ненадійні сервери DNS, отримані від локальної мережі під час встановлення з'єднання:

  1. На старті з'єднання додаток робить DNS-запит для отримання IP-адреси сервера.
  2. Фальшивий DNS-сервер у публічній мережі повертає IP-адресу цільового сервісу, трафік якого зловмисник хоче дослідити.
  3. Додаток приймає цю відповідь і прописує маршрут /32 для цієї цільової адреси через адаптер wlan0.
  4. Хоча встановлення сесії з цим фальшивим сервером зазнає невдачі, маршрут хоста залишається діяти, і весь подальший трафік пристрою до вказаного сервісу передається відкрито через фізичну мережу.

Навіть при використанні статичних IP-адрес серверів нападник може підробити відповіді DNS для популярних ресурсів, зіставивши їх з IP-адресою сервера, що спричинить вихід даних поза зашифрований тунель.

+-----------------------------------------------------------------------------+
|                      ПОРІВНЯННЯ АТАК LOCALNET ТА SERVERIP                   |
+------------------------+----------------------------------------------------+
| Тип атаки              | Головний механізм експлуатації                     |
+------------------------+----------------------------------------------------+
| LocalNet               | Великі публічні маски підмереж через DHCP          |
| (CVE-2023-36664)       | Довший префікс скасовує дію маршрутів /1 туннелю   |
|                        | Експлуатація дозволу доступу до локальної мережі   |
+------------------------+----------------------------------------------------+
| ServerIP               | Підміна відповідей DNS під час старту сесії        |
| (CVE-2023-35838)       | Маршрут вузла /32 направляє трафік у відкритий світ|
|                        | Використання механізму запобігання зацикленню      |
+------------------------+----------------------------------------------------+

TunnelCrack і TunnelVision: ключові технічні відмінності

Важливо чітко розрізняти загрози TunnelCrack та TunnelVision (CVE-2024-3661). Хоча обидві техніки використовують таблиці маршрутизації, точки входу істотно різняться:

  • TunnelVision повністю залежить від опції DHCP Option 121 (RFC 3442, безкласова статична маршрутизація). Системи, що не підтримують опцію 121 за замовчуванням (як-от стандартний Android), захищені від неї на рівні архітектури.
  • TunnelCrack не потребує спеціальних розширень DHCP. Варіант LocalNet спирається на базове поле маски підмережі, стандартизоване в RFC 2132 ще з 1997 року. Оскільки обробка масок є обов'язковою для будь-якого пристрою, загроза торкнулася iOS, macOS, Windows, Linux та Android.

Ядро системи керується виключно довжиною маски, не беручи до уваги криптографічний контекст. Коли пакет збігається з точнішим маршрутом на фізичній карті, він передається відкрито.

Ієрархія пріоритетів у таблиці маршрутизації ядра:
┌────────────────────────────────────────────────────────┐
│  Маршрут вузла (/32): Точна адреса цілі (ServerIP)    │  ◄── Найвищий пріоритет
├────────────────────────────────────────────────────────┤
│  Локальна підмережа (/16, /24): LocalNet               │  ◄── Перекриває тунель
├────────────────────────────────────────────────────────┤
│  Розділений маршрут тунелю (/1): 0.0.0.0/1             │  ◄── Звичайний тунель
├────────────────────────────────────────────────────────┤
│  Шлюз за замовчуванням (/0): 0.0.0.0/0                 │  ◄── Найнижчий пріоритет
└────────────────────────────────────────────────────────┘

Архітектурні рішення: запобігання витокам маршрутизації

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

1. Брандмауер ядра та механізм аварійного вимкнення

Надійний механізм Kill Switch не повинен спиратися лише на пріоритети маршрутів. Необхідне впровадження фільтрації пакетів на рівні ядра, яка блокує будь-які вихідні дані через фізичний адаптер, якщо вони не належать зашифрованому транспорту підтвердженого сервера.

У системі Linux за допомогою nftables вихідний трафік на фізичному інтерфейсі жорстко фільтрується:

# Дозвіл виключно для інкапсульованих пакетів UDP на фізичній мережевій карті
table inet vpn_filter {
    chain output {
        type filter hook output priority 0; policy drop;

        # Пропуск локального трафіку loopback та віртуального інтерфейсу
        oifname "lo" accept
        oifname "rice0" accept

        # Дозвіл лише на підключення до легітимного сервера тунелю
        oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
    }
}

У середовищі Windows платформа Windows Filtering Platform (WFP) блокує відкриті пакети на транспортному рівні ще до їх передачі на фізичний контролер. На платформі macOS правила пакетного фільтра pf гарантують, що жоден фізичний інтерфейс не оброблятиме користувацький трафік поза віртуальним інтерфейсом.

2. Вимкнення спільного доступу до локальної мережі в публічному Wi-Fi

Оскільки атака LocalNet спирається на винятки для локальних ресурсів, надійні клієнти вимикають доступ до локальної мережі в ненадійних середовищах:

  • Видалення прямих маршрутів зв'язку канального рівня.
  • Спрямування всього трафіку до захищеного тунелю.
  • Навіть якщо шкідливий сервер DHCP призначає фальшиву маску /8, мережевий фільтр не дозволяє пакетам виходити напряму.

3. Мережеві простори імен та прив'язка через SO_BINDTODEVICE

В операційних системах Linux та Android мережеві простори імен (Network Namespaces) забезпечують безкомпромісну ізоляцію. Завдяки переміщенню фізичного адаптера Wi-Fi в окремий простір імен і утриманню додатків користувача в основному просторі, де присутній тільки віртуальний інтерфейс, програми просто позбавлені технічної змоги взаємодіяти із зовнішніми мережевими маршрутами.

Також додатки можуть безпосередньо прив'язувати мережеві сокети до віртуального адаптера:

// Прив'язка сокета додатка безпосередньо до інтерфейсу тунелю
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));

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

Практична перевірка конфігурації пристрою на стійкість

Адміністратори та користувачі можуть самостійно перевірити захищеність власної системи:

  1. Аналіз активної таблиці маршрутизації: Порівняйте стан маршрутів до та після встановлення захищеного з'єднання, щоб переконатися у відсутності незрозумілих маршрутів хоста /32 чи аномальних локальних підмереж:
    ip route show table all
  2. Тест із підробленою підмережею: Налаштуйте тестовий роутер на роздавання публічного пулу адрес (наприклад, 198.51.100.0/24) через локальний DHCP. Під'єднайтеся до мережі, увімкніть тунель і переконайтеся, що запити до 198.51.100.1 прямують у зашифрований тунель або відкидаються захистом.
  3. Контроль налаштувань локальної видимості: Перевірте, щоб функція Local Network Sharing була деактивована під час роботи в кафе, готелях та аеропортах.

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

Для надійного захисту робочих станцій, ноутбуків та смартфонів встановіть актуальний клієнт на сторінці Завантажити VPNRice.