TunnelCrack проти TunnelVision: що насправді ламає кожен із них

Дві дослідницькі назви використовуються взаємозамінно для будь-якого трафіку VPN, що залишає тунель, але механізми за ними не однакові. TunnelCrack описує дві родини винятків маршрутизації; TunnelVision описує маршрут, який DHCP надає кінцевому пристрою. Жоден не ламає шифрування, і жоден не каже, що робить сьогодні конкретна збірка клієнта. П'ять перевірок відокремлюють механізми від заголовка.

Перший крок: назвіть механізм, який ви переглядаєте

Розкриття TunnelCrack у серпні 2023 року описує дві родини атак. У випадку локальної мережі трафік, який клієнт вважає належним локальній мережі, отримує виняток локального доступу і залишає тунель. У випадку адреси сервера маршрут, потрібний клієнту, щоб дістатися до самого сервера VPN, розташований поза тунелем, і противник, який контролює цю адресу, може скористатися винятком.

TunnelVision — це окремий звіт про безкласові статичні маршрути, які надає DHCP. Зловмисний сервер DHCP може передати кінцевому пристрою маршрути, що змінюють шлях трафіку, зокрема шлях до сервера VPN. Звіт визнає попередню роботу про пов'язані ефекти маршрутизації, що нагадує: базовий механізм старший за назву.

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

Другий крок: подивіться на виняток локального доступу

Більшість клієнтів виключають трафік локальної мережі, щоб принтери, трансляція екрана та спільний доступ до файлів працювали, поки тунель увімкнено. Цей виняток — політичне рішення з ціною для безпеки: противник у тій самій мережі може представитися локальним хостом, і трафік, що до нього доходить, ніколи не входив у тунель.

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

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

Третій крок: подивіться, як вивчається адреса сервера

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

Закріплення адреси, використання перевіреного сертифіката з правильним іменем і відмова повертатися до неперевіреного сервера — усе це зменшує вплив. Жодне з них не усуває потреби дістатися сервера поза тунелем; вони змінюють, хто може відповідати за цю адресу.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

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

Четвертий крок: подивіться на маршрути, які надає DHCP

Безкласові статичні маршрути дозволяють серверу DHCP роздавати записи таблиці маршрутизації, і кінцевий пристрій зазвичай приймає їх, не питаючи. У мережі, де противник може відповісти на DHCP швидше за законний сервер, ці записи можуть переспрямувати трафік, який користувач вважає таким, що перебуває всередині тунелю.

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

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Останнє налаштування — це керування на боці кінцевого пристрою, яке багато клієнтів і платформ надають у якійсь формі: ігнорувати маршрути, які надає мережа. Вимкнення автоматичного приймання маршрутів — це компроміс, бо воно вимикає й законну розділену маршрутизацію від корпоративного сервера DHCP, тому вирішуйте це за класом мережі, а не глобально.

П'ятий крок: відокремте повідомлення від поточної збірки

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

Запишіть версію клієнта, платформу, налаштування профілю, які керують винятками вище, і дату перевірки. Цей запис старіє чесно, а нотатка про те, що VPN пропатчили через TunnelCrack, старіє нечесно. Перечитуйте її при кожному оновленні клієнта, бо значення профілю за замовчуванням може змінитися під версією, якої ви не торкалися.

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

Насамкінець, тримайте захист на рівні застосунку в полі зору. Виняток маршрутизації може розкрити трафік, який тунель ніс би, а TLS застосунку й далі захищає цей трафік від кінця до кінця. Два шари відмовляють незалежно, тому під'єднаний канал керування не є доказом того, що кожен потік пішов запланованим шляхом.