Wpad dat что это
WPAD: инструкция по эксплуатации
Привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. На последнем Security Meetup’е я поделился результатами своего исследования протокола автоматической настройки прокси WPAD. Для тех, кто пропустил, — сегодняшний пост. Я расскажу о том, что такое WPAD, какие возможности для эксплуатации он предоставляет с точки зрения злоумышленника, а также покажу примеры того, как можно частично перехватывать HTTPS-трафик с помощью этой технологии.
Немного матчасти
WPAD (Web Proxy Auto Discovery protocol) служит для того, чтобы найти файл PAC (Proxy Auto Config), представляющий собой JavaScript с описанием логики, по которой браузер будет определять, как подключаться к нужному URL. При совершении запроса браузер вызывает функцию FindProxyForURL из PAC-файла, передает туда URL и хост, а в результате ожидает узнать, через какие прокси ходить на этот адрес. Выглядит это примерно так:
Помимо FindProxyForURL в PAC-скрипте доступны различные вспомогательные функции для более гибкой настройки. С их помощью можно, например, указать, что браузер должен открывать сайт mail.ru с часу до двух в понедельник через %proxynameX%, а в другое время — через %proxynameY%. Адрес 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.
Windows 7 ведет себя по-другому: сначала по DNS проверяет полный домен, потом пытается зарезолвить имя WPAD через Link-Local Multicast Name Resolution, а затем — с помощью NetBIOS Name Service. Последние два являются широковещательными протоколами, а LLMNR поддерживается только Windows, начиная с Vista.
Использование в локальной сети
Представим себя на месте злоумышленника, который хочет пустить весь локальный трафик через свой прокси-сервер. Если мы находимся в том же сегменте локальной сети (т.е. можем использовать NetBIOS), нам даже ничего не придется делать — можно воспользоваться готовым NBNS-спуфером из Metasploit.
Осуществление NBNS-спуффинга в локальной сети
Если же мы находимся в другой подсети, но в нашей сети есть WINS-сервер, мы можем поднять Windows-хост с именем WPAD, чтобы WINS распространил информацию о нас. Этот кейс вполне рабочий: при тестировании в достаточно крупной локальной сети одного вуза на хост, находящийся в сети даже меньше /24, начали приходить запросы с сотен различных IP.
Использование в интернете
Свободные для регистрации домены WPAD
Пару лет назад я регистрировал домен wpad.co, на который действительно шли многочисленные запросы за wpad.dat файлом. Но есть и более свежие свидетельства возможности перехватить то, что нам не предназначалось: месяц назад я зарегистрировал домен wpad.work. За 11 дней к нему обратились с 3901 уникального IP. При этом заметно, что количество запросов уменьшалось в выходные.
Количество обращений к wpad.work: динамика по дням недели
Что можно найти в логах, если отправить всех страждущих через свой прокси, можно увидеть ниже.
Фрагмент лога прокси-сервера
Profit?
Итак, мы заставили пользователей ходить через подконтрольный нам прокси-сервер. Что это нам дает? В случае HTTP-запросов — полный контроль над трафиком: заголовками и телом запроса и ответа, всеми параметрами, cookies, данными сабмитов форм.
HTTP-запрос через прокси-сервер
В случае с HTTPS мы увидим только метод CONNECT. Максимум доступной нам информации — хост и user-agent. К сожалению, самое интересное, то есть данные обмена между клиентом и сервером после handshake, для нас будет выглядеть лишь как набор бинарных данных.
HTTPS-запрос через прокси-сервер
Back to PAC
Несмотря на то, что PAC-скрипт написан на JavaScript, в нем недоступны объекты window, document, не получится вывести пользователю alert (он будет отображен только в логах браузера). Тем не менее, даже в этой урезанной версии есть свои приятные функции.
JavaScript-функции, доступные из PAC-скрипта
Одна из них — isResolvable — проверяет, возможно ли разрешить доменное имя в IP-адрес. Работает это так:
Что нам может дать использование этой функции? Чтобы ответить на этот вопрос, сначала разберемся, что именно передается в функцию FindProxyForURL в аргументе «URL». Оказывается, это зависит от браузера: Chrome передает схему, хост, запрос (GET-параметры), а вот Firefox вдобавок еще и фрагмент (location.hash).
Например, URL http://mail.ru/?a=123#token=secret обработается следующим образом:
Итак, с помощью нехитрых преобразований:
наш тестовый URL https://example.ru/?token=123 превращается в элегантное
https058047047example046ru047063token061123.hacker.com, из которого, посредством Perl-преобразования
можно легко получить исходную строку, то есть полный URL HTTPS-запроса. Таким образом, воспользовавшись неправильной настройкой клиента, злоумышленник может частично обойти HTTPS-шифрование и получить доступ к URL’ам всех запросов пользователя.
Не секрет, что во фрагменте URL (location.hash) часто передаются OAuth-токены. Таким образом, в случае использования Firefox, к нам в руки могут попасть и они.
В результате размещения этого скрипта на wpad.work были перехвачены несколько тысяч запросов пользователей, среди них самыми популярными протоколами оказались:
Чаще всего запросы приходили из следующих стран:
Итого
С помощью WPAD можно, невзирая на HTTPS, перехватывать локальный трафик, токены OAuth и другую информацию из URL. Однако мы как честные люди такого делать не будем. Лучше попробуем, используя имеющиеся у нас знания, защититься от потенциальных атак. Ниже — основные рекомендации, выполнение которых позволит обезопасить свой трафик.
Слабые стороны технологии WPAD
В этой статье мы поговорим об архитектуре WPAD и основных принципах функционирования данной технологии в корпоративных и домовых сетях, рассмотрим реальные примеры атак, а также разработаем рекомендации для рядовых пользователей и системных администраторов, позволяющие обезопасить себя от действий злоумышленников.
Автор: Сергей Рублев
Эксперт по информационной безопасности «Positive Technologies»
Скачать сетевую утилиту для проверки наличия потенциально опасных записей в серверах имен DNS и WINS можно по адресу:
www.ptsecurity.ru/freeware.asp
В процессе анализа ежемесячных обновлений от Microsoft мое внимание привлек бюллетень MS09-008, а точнее, его часть, в которой фигурирует имя WPAD. Этот бюллетень исправляет целый ряд уязвимостей в службах Microsoft DNS и Microsoft WINS, среди которых значится «Уязвимость регистрации WPAD», однако данное имя не первый раз встречается в уведомлениях по безопасности. Впервые о слабых сторонах WPAD заговорили в 1999 г., в 2007 г. был опубликован широкий спектр проблем, связанных с этой технологией, в том же году на конференции ShmooCon 2007 Крис Пейджет (Chris Paget) представил практические примеры эксплуатации уязвимостей WPAD. Сейчас, спустя 10 лет, Microsoft продолжает выпускать заплатки, закрывающие бреши данной технологии, а вопрос о безопасности сетей, в которых применяется WPAD, так и остался открытым. Успешная атака на WPAD гарантирует злоумышленникам полный контроль над пользовательскими данными, передаваемыми в Интернет, что может привести к краже критической информации, такой как пароли или номера банковских карт. На потенциальную опасность WPAD во многом влияют два фактора: во-первых, использование в конфигурации «по умолчанию», во-вторых, слабая осведомленность рядовых пользователей в данном вопросе.
В этой статье мы поговорим об архитектуре WPAD и основных принципах функционирования данной технологии в корпоративных и домовых сетях, рассмотрим реальные примеры атак, а также разработаем рекомендации для рядовых пользователей и системных администраторов, позволяющие обезопасить себя от действий злоумышленников.
Обзор WPAD
WPAD (Web Proxy Auto Discovery) – протокол, позволяющий Web-клиентам автоматически определять местоположение файла настроек браузера для работы через прокси-сервер. В 1999 г. Microsoft представила данный протокол на рассмотрение в IETF, однако в качестве стандарта WPAD так и не был принят. В настоящее время WPAD поддерживается семейством браузеров Internet Explorer и Mozilla Firefox (Google Chrome и Apple Safari используют настройки прокси-серверов браузера Internet Explorer, т.е. также поддерживают WPAD). Поддержка WPAD присутствует и в семействе открытых операционных систем, например, в браузере Konquerror в ОС Linux.
Включение WPAD в Microsoft Internet Explorer
По сути WPAD – это протокол обнаружения в сети специального файла (сценария). В спецификации WPAD перечислены способы и протоколы, с помощью которых осуществляется поиск. Для понимания технологии WPAD необходимо более детально познакомиться со сценариями автоматической настройки браузеров.
Сценарии Proxy Auto Configuration
Файл Proxy Auto Configuration (далее PAC-файл) используется в корпоративных сетях для централизованного распространения настроек, которые применяются при работе через прокси-сервер для браузеров пользователей.
По сути PAC представляет собой сценарий на языке JavaScript.
В нем должна быть определена функция FindProxyForURL(url, host), где
url – запрашиваемый адрес;
host – часть url в формате «имя хоста:порт».
function FindProxyForURL(url, host)
<
return «PROXY proxy.example.com:8080; DIRECT»;
>
Этот конфигурационный файл дает указание браузеру использовать прокси-сервер proxy.example.com для получения всех Web-страниц. Более подробное описание синтаксиса PAC-файлов можно найти в [3].
PAC-файлы могут использоваться как совместно с WPAD, так и обособленно, в этом случае в Интернет-браузере необходимо явно указать сетевой путь к данному файлу.
WPAD предоставляет пользователю возможность получения месторасположения PAC-файла одним из следующих способов:
При использовании WPAD к PAC-файлу предъявляются следующие требования:
Принцип работы WPAD в корпоративной сети
Принцип работы WPAD
Сценарии атак на Web Proxy Auto Discovery
В Internet Explorer WPAD включен по умолчанию, что делает уязвимым к атакам огромное число пользователей, отдающих предпочтение данному браузеру, а также браузерам, импортирующим его настройки. По данным SpyLog за апрель 2009 г. Internet Explorer, Apple Safari и Google Chrome вместе используют 55% пользователей Рунета
Наиболее уязвимым местом в технологии WPAD является поиск месторасположения PAC-файла. Если злоумышленнику удается убедить клиента в том, что необходимый файл конфигурации находится на сетевом узле, подконтрольном атакующему, атаку можно считать состоявшейся.
Для успешной атаки злоумышленнику необходимо иметь:
В рамках данной статьи не будут рассматриваться атаки, основанные на внедрении в сеть ложного DHCP-сервера, так как такая атака позволяет полностью контролировать все настройки сетевой подсистемы клиента, в том числе и WPAD. Далее по тексту предполагается, что месторасположение PAC-файла в данной сети по DHCP не распространяется. Локальные файлы hosts и lmhosts будем считать недоступными для злоумышленника.
Атака с использованием DNS-сервера
Система DNS поддерживает динамические обновления записей, что позволяет клиентам автоматически регистрировать свои имена и IP-адреса на DNS-сервере при входе в сеть или изменении IP-адресов с помощью сервера DHCP. Если в атакуемой зоне разрешены неаутентифицированные динамические обновления, то для регистрации записи достаточно одного специального DNS-пакета.
Сценарий атаки с использованием DNS-сервера
На схеме показан общий случай, во время атаки прокси-сервер злоумышленника и точка распространения PAC-файлов может находиться на одном и том же сетевом узле.
Примечания: Если DNS-сервер работает в составе домена Active Directory, возможна более безопасная конфигурация, позволяющая динамическое обновление записей только для аутентифицированных пользователей. Для успешной атаки в этом случае злоумышленнику необходимо иметь корректную учетную запись в атакуемом домене. [4]
Данный класс атак актуален только в сетях, имеющих доменную структуру, так как в сети на базе рабочих групп поиск PAC-файла при помощи запроса к DNS-серверу не используется. Атакам, описанным далее, подвержены как доменные, так и одноранговые сети.
Атака с использованием WINS-сервера
Регистрация имен компьютеров, входящих в сеть, является штатной функцией WINS-сервера. Как и в случае с DNS-сервером регистрация осуществляется при помощи одного специального пакета.
Сценарий атаки с использованием WINS-сервера
Атака в доступной подсети
Если месторасположение PAC-файла не найдено путем запроса к DNS- или WINS-серверам, согласно стандарту WPAD Web-клиенты делают широковещательный NetBIOS-запрос имени WPAD по всей подсети согласно сетевой маске.
Данный вектор атаки доступен, если у злоумышленника есть физический доступ к подсети клиента.
Сценарий атаки в доступной подсети
Описанный выше класс атак легко реализуется в большинстве сетей, где отсутствует строгая политика безопасности. Как пример можно привести домовые сети, сети небольших провайдеров, WiFi-интернет в кафе и торговых центрах, где WINS-серверы не используются, а NetBIOS-трафик не фильтруется на сетевых устройствах.
Использование WPAD в службах Microsoft
Помимо браузеров технологию WPAD для поиска прокси-сервера используют и ряд системных компонентов Microsoft:
Эти службы задействуют WPAD всегда независимо от настроек Internet Explorer.
Примечание: Windows Update и Crypto API передают только подписанные данные, поэтому не подвержены атакам класса «человек посередине». При организации одной из приведенных выше атак можно вызвать некорректную работу данных служб.
Устранение «Уязвимости регистрации WPAD» от Microsoft
В бюллетене MS09-008 исправляются следующие уязвимости:
Несмотря на название, установка исправлений не вносит никаких изменений в сам процесс регистрации имен, некоторые коррективы вносятся только в процесс разрешения (resolving) DNS- и NetBIOS-имени соответственно. До поиска в базе DNS- и WINS-серверы выполняют поиск запрашиваемого имени по «черному списку». Если имя находится в списке, то клиенту возвращается код ошибки «имя не найдено», иначе продолжается штатная работа сервера. Внедрение «черных списков» только сужает потенциальный масштаб атаки, а именно, возможность использования злоумышленником собственных записей на DNS- и WINS-сервере, однако атака на доступную подсеть все равно может быть реализована. Специалисты Microsoft объясняют такое поведение заботой о клиентах, которые внедрили и активно используют технологию WPAD.
«Черные списки» хранятся в следующих ключах реестра:
Состав «черных списков» по умолчанию:
Обратите внимание, что если на момент установки исправления в базе WINS или DNS существовали некоторые из вышеперечисленных записей, то они не добавляются в указанные списки.
«Черные списки» распространяются только на динамические записи, таким образом, у администратора есть возможность организовать работу WPAD путем регистрации статической записи в базах DNS и WINS соответственно.
Примечание: динамические записи добавляются в базу DNS- и WINS-сервера с помощью специального запроса регистрации, а статические – через консоль управления сервером.
Рекомендации по устранению уязвимости
Для конечных пользователей:
Для системных администраторов
В силу специфики уязвимостей более подверженными атакам являются сети, не использующие Web Proxy Auto Discovery, чем сети, где WPAD штатно работает. Для повышения уровня защищенности сети можно предпринять следующие действия:
В домене Active Directory существуют способы дополнительного повышения уровня безопасности:
Выводы
Основным фактором, делающим атаки на WPAD такими опасными, является его повсеместное использование в конфигурации «по умолчанию». В настоящее время корпорация Microsoft активно пропагандирует подход Secure by Default (безопасность по умолчанию) как один из основополагающих принципов SDL (Security Development Lifecycle – цикл разработки безопасных приложений), однако конфигурация прокси-серверов в Internet Explorer служит ярким примером нарушения данного принципа.
О слабых сторонах протокола WPAD известно еще с 1999 года, однако он продолжает использоваться и по сей день. Во многом на это повлияло доминирующее положение Microsoft на рынке Интернет-браузеров, и даже отсутствие стандартизации не смогло приостановить распространение данной технологии.
В статье описаны лишь самые простые атаки на WPAD, но существуют и более трудоемкие, требующие от атакующего дополнительных мер по противодействию средствам защиты. Подмена IP-адреса в пакетах регистрации или временный вывод из строя корпоративного DNS-сервера может помочь обойти ряд ограничений по эксплуатации уязвимости. Выбирая защитные механизмы, сетевым администраторам необходимо учитывать существование довольно большого спектра возможных векторов атаки, а также тот факт, что исправления от Microsoft закрывают уязвимость лишь частично.
Слабые места в использовании WPAD до сих пор не устранены, а значит, у злоумышленников есть широкий простор для атакующих действий.
Возможно, пока вы читаете эту статью, ваш браузер ищет по сети волшебное имя WPAD
Литература
Об авторе: Сергей Рублев закончил МГТУ им. Баумана. Эксперт в области криптографии и протоколов защищенного обмена данными. В компании Positive Technologies специализируется на анализе уязвимостей в сетевых службах и разработке расширений к сканерам XSpider и MaxPatrol.
Настраиваем Web Proxy Automatic Discovery (WPAD)
Если вы настраиваете параметры прокси сервера в веб-браузере Internet Explorer (IE) с помощью групповых политик, и тем более делаете это с запретом изменений настроек для пользователя, то рано или поздно может возникнуть ситуация, когда пользователь выехавший в командировку не сможет воспользоваться на служебном ноутбуке браузером для доступа в интернет где-нибудь в гостинице или аэропорте из-за невозможности отключения этих самых жёстко заданных настроек прокси.
Файл Wpad.dat это файл Java-script в котором задаются настройки параметров расположения имени и порта прокси сервера, а также список исключений для обхода прокси. В случае недоступности данного файла браузер будет выполнять попытку прямого подключения к Интернет-ресурсам через настроенный в свойствах сетевого адаптера шлюз по умолчанию. При этом в настройках самого браузера в явном виде параметры прокси не указываются, а включается соответствующая опция авто-обнаружения. Механизм WPAD поддерживают браузеры Internet Explorer, Mozilla Firefox, с некоторыми ограничениями Opera и др.
Для того чтобы клиентский браузер узнал о том, где в локальной сети расположен сервер с опубликованным файлом wpad.dat, может использоваться механизм обращения в DNS или получения настроек с сервера DHCP. Эти оба метода можно применять как раздельно, так и совместно и каждый из этих методов имеет свои достоинства и недостатки.
WPAD и DHCP
Его основа сводится к добавлению на сервер DHCP дополнительной опции 252, в которой указывается URL файла авто-настройки. Эта опция назначается на сервер или отдельную область и передается клиентам DHCP вместе с основными настройками IP.
В окне опций, чтобы добавить новую опцию нажмём Add и затем укажем параметры опции:
После этого зададим в поле String значение URL по умолчанию и сохраним параметр.
В документации встречается отдельное замечание о том, что имя файла wpad.dat должно быть написано в данном случае в нижнем регистре.
После того как опция создана мы можем сконфигурировать её как для отдельной области так и глобально для всего сервера DHCP:
WPAD и DNS
В нашем практическом примере мы будем использовать метод с использованием DNS, так как, на мой взгляд, он является наиболее универсальным, хотя и не лишён некоторых недостатков (некритичных в нашей ситуации).
Суть метода настройки клиентов WPAD с использованием DNS заключается в том, что в основной зоне DNS (DNS Suffix) создается запись формата wpad.domain.com которая ссылается на сервер где опубликован файл wpad.dat. Тип этой записи может быть как A так и CNAME.
dnscmd /info /enableglobalqueryblocklist
Чтобы получить содержимое блок-листа выполним:
dnscmd /info /globalqueryblocklist
В конфигурации по умолчанию в блок-лист как раз таки включены записи wpad и isatap. Чтобы переписать содержимое блок-листа, исключив оттуда интересующий нас wpad, выполним команду:
dnscmd /config /globalqueryblocklist isatap
В ветке реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters
блок-лист хранится в параметре GlobalQueryBlockList
Если есть желание отключить использование блок-листа совсем, можно выполнить:
dnscmd /config /enableglobalqueryblocklist 0
или же в изменить соответствующий параметр реестра EnableGlobalQueryBlockList
После сделанных изменений нужно перезапустить службу DNS
net stop dns & net start dns
WPAD сервер
В консоли Forefront TMG Management в дереве навигации перейдём в ветку Networking на закладку Networks и выберем сеть, для которой нам нужно создать прослушиватель WPAD (обычно это внутренняя сеть – Internal). Откроем свойства этой сети
В поле где указан номер порта устанавливаем 80 порт. Как уже отмечалось ранее, в силу того, что мы используем связку WPAD/DNS, мы должны использовать именно этот порт.
Переключаемся на закладку Web Browser и настраиваем список исключений для узлов и доменов к которым клиенты должны ходить напрямую минуя прокси.
Сохраняем настройки конфигурации TMG и после этого через веб браузер TMG должен отдавать нам скрипт авто-настройки по адресу http://tmgcluster.holding.com/wpad.dat
Открыв этот файл, мы сможем проверить попали ли в него данные списка обхода прокси. Изучив содержимое этого файла можно заметить то, что по умолчанию в этот файл адреса прокси-серверов попадают в виде IP адресов
Proxies = new MakeProxies();
Для того чтобы изменить адреса прокси попадающие в wpad с IP на FQDN можно воспользоваться подключением к COM-объекту TMG через Powershell и свойством CarpNameSystem. Чтобы получить текущее значение этого свойства, выполним скрипт:
$FPCRoot = New-Object -comObject «FPC.Root»
Установленное по умолчанию значение «2» нам нужно будет заменить на значение «0» следующим образом:
$FPCRoot = New-Object -comObject «FPC.Root»
Для вступления параметров в силу нужно перезапустить сервера TMG.
После перезагрузки снова проверяем содержимое файла wpad.dat и убеждаемся в том, что адреса прокси указаны в виде FQDN серверов.
WPAD клиенты
В браузере Mozilla Firefox активация механизма WPAD делается аналогичным образом и работает без нареканий (проверено на текущей версии 12.0)