Исследователи рекомендуют срочно отключить протокол WPAD на Windows
Web Proxy Auto-Discovery Protocol (WPAD) — это протокол автоматической настройки прокси, который используется клиентами (браузером) для определения места (URL) расположения конфигурационного файла с использованием технологий DHCP и/или DNS. При совершении запроса браузером вызывается функция FindProxyForURL из PAC-файла, куда передается URL и хост. Ожидаемый ответ — список прокси, через которые будет осуществляться выход на этот адрес. WPAD включен по умолчанию в Windows, поддерживается он и другими операционными системами. Но этот протокол подвержен ряду уязвимостей, что показали специалисты по информационной безопасности Алекс Чапман (Alex Chapman) и Пол Стоун (Paul Stone) на Defcon. Злоумышленники, используя эти уязвимости, могут получить данные жертвы (история поиска, доступы к аккаунтам, фото, документы и т.п.), несмотря на HTTPS или VPS соединения. Тип атаки, который применяется в этом случае — man-in-the-middle.
Размещение конфигурационного PAC-файла можно определить с использованием Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS) или Link-Local Multicast Name Resolution (LLMNR). Киберпреступники при желании могут использовать уязвимость в WPAD, указав размещение специально сконфигурированного PAC-файла, который направит запрос браузера через прокси-серверы, находящиеся под контролем злоумышленников. Этого можно добиться в открытой беспроводной сети, скомпрометировав роутер или точку доступа, либо открыв для всех желающих доступ к собственной точке доступа, сконфигурированной должным образом.
Компрометировать собственную сеть атакуемого ПК не обязательно, поскольку система будет использовать WPAD для обнаружения прокси в случае подключения по открытой беспроводной сети. При этом WPAD используется и в корпоративном окружении, эта опция включена по умолчанию на всех Windows-ПК, как уже говорилось выше.
Собственный прокси-сервер позволяет злоумышленникам перехватывать и модифицировать незашифрованный HTTP-трафик. Это не дает слишком многое киберпреступникам, поскольку большинство сайтов сейчас работает по HTTPS (HTTP Secure). Но, поскольку PAC-файлы обеспечивают возможность задавать различные адреса прокси для определенных веб-адресов, и для этих адресов можно принудительно выставить DNS lookup, хакеры-«белошляпники» создали скрипт, который позволяет получать все защищенные HTTPS URL на собственный сервер.
Полный адрес HTTPS URL должны быть скрыт, поскольку он содержит токены аутентификации и другую частную информацию. Но злоумышленник может восстановить адрес. Например, example.com/login?authtoken=ABC1234 может быть восстановлен путем использования DNS-запроса https.example.com.login.authtoken.ABC1234.leak и восстановлен на сервере киберпреступника.
Используя такой метод, атакующий может получить список поисковых запросов жертвы или просмотреть, какие статьи определенного ресурса жертва сейчас читает. Это не слишком хорошо с точки зрения информационной безопасности, но вроде бы не слишком опасно. Правда, неприятности жертвы на этом и не заканчиваются.
Исследователи разработали еще один тип атаки, который может использоваться для перенаправления пользователя открытой беспроводной точки доступа на фейковую страницу точи доступа. Многие беспроводные сети собирают данные о пользователях при помощи специальных страниц. После ввода своих данных пользователь получает доступ к интернету (часто такая схема используется провайдерами беспроводной связи в аэропортах).
Страница, сформированная злоумышленниками, загружает в фоне привычные пользователю Facebook или Google, а затем выполняет 302 HTTP редирект на другие URL при условии аутентификации пользователя. Если пользователь уже вошел в свою учетную запись, а большинство людей не выходят из своих учетных записей на различных ресурсах, работая со своего ПК или ноутбука, то мошенник может получить идентификационные данные жертвы.
На ОС Windows WPAD активируется при включении опции «Автоматическое определение параметров». Эта опция включена по умолчанию
Это касается учетных записей на самых разных ресурсах, причем по прямым ссылкам злоумышленник может получить доступ к личным фото жертвы, равно, как и другим данным. Злоумышленники могут похищать и токены для популярного протокола OAuth, который позволяет логиниться на различных сайтах, используя данные своего Facebook, Google или Twitter аккаунта.
Возможности нового метода специалисты показали на Defcon. Используя свою технологию, эксперты получили доступ к фото жертвы, истории координат, напоминаниям календаря и данных профиля аккаунта Google, а также доступ ко всем документам жертвы на Google Drive. Здесь стоит подчеркнуть, что атака не затрагивает HTTPS-шифрование, данные по-прежнему защищены. Но если в ОС включен WPAD, то HTTPS уже гораздо менее эффективен в плане защиты приватных данных пользователя. И это также касается информации тех пользователей, кто работает c VPN. WPAD позволяет получить доступ и к этим данным.
Все дело в том, что популярные VPN-клиенты, вроде OpenVPN, не очищают сетевые настройки, заданные WPAD. Это означает, что если атакующему уже удалось установить на ПК жертвы свои настройки прокси, прежде, чем на этом ПК было установлено соединение с VPN, то трафик также будет идти через прокси-сервер злоумышленника. Это открывает возможность получения всех данных, указанных выше.
Большинство операционных систем и браузеров работают с WPAD, и являются уязвимыми к такому типу атаки. Эксперты, обнаружившие проблему, сообщили о ней разработчикам различных уязвимых программных продуктов. Патчи выпущены для OS X, iOS, Apple TV, Android, Google Chrome. Microsoft и Mozilla все еще работают над исправлением проблемы.
Как защититься?
Самый простой способ — отключить WPAD. Если вам нужны PAC -файлы для работы, отключите WPAD и сконфигурируйте исключения URL самостоятельно.
Чапман и Стоун — не единственные эксперты по информационной безопасности, кто обратил внимание на уязвимость протокола WPAD. Несколькими днями ранее схожий тип атаки был продемонстрирован на конференции Black Hat. А в мае объединенная команда специалистов Verisign и Мичиганского университета рассказала о том, что десятки миллионов WPAD-запросов идут в сети каждый день, когда ноутбуки пользователей отключаются от корпоративных сетей. Эти машины дают запросы на внутренние WPAD домены с расширениями типа .global, .ads, .group, .network, .dev, .office, .prod, .hsbc, .win, .world, .wan, .sap, and .site.
Проблема в том, что такие доменные зоны уже существуют в глобальной сети, и при желании злоумышленник может зарегистрировать себе домены, на который идут запросы с корпоративных машин, отключенных от сети предприятия. А это, в свою очередь, позволяет злоумышленникам «скормить» самостоятельно сконфигурированных PAC-файл машинам, которые отключены от корпоративных сетей, но которые дают WPAD запросы на обнаружение упомянутых выше адресов в глобальной сети.
Комментарии (17)
dartraiden
15.08.2016 14:51До кучи, наверное, можно попробовать ещё отключить и службу автоматического обнаружения веб-прокси WinHTTP (WinHttpAutoProxySvc). Правда, у неё в зависимостях «вспомогательная служба IP», которая, как я понимаю, отвечает за поддержку 6to4 и Teredo.
xforce
15.08.2016 15:00Да можно много всего наотключать, но непонятно, зачем. WPAD подсовывается с DHCP. Мне уже разок попадалась ссылка на эту статью, там мне никто не смог объяснить, каким образом подкидывание WPAD дает большую дыру, чем возможность развернуть левый DHCP сервер в сети, который неободим для передачи WPAD.
throttle
15.08.2016 16:00Например, тем, что wpad-запрос может вырваться за пределы сети.
Если комп находится в домене city.example.office, то wpad будет последовательно искать:
wpad.city.example.office.
wpad.example.office.
wpad.office.
wpad.
И на одном из этапов можно подсунуть свой pac-файл, и направить трафик туда, куда надо.
pit_art
15.08.2016 15:03Странно все это.
Для работы wpad должна быть сделана соответствующая настройка на dhcp-сервере (dhcp option 252), или же в некоторых случаях можно обойтись компрометацией dns-сервера
Если в руках злоумышленников находится dhcp и/или dns сервер сети — право же wpad меньшая из проблем.lubezniy
15.08.2016 19:57Если сеть специально создана злоумышленником, комп автоматом цепляется к открытым сетям, а всевозможные приложения на нём открывают сайты и передают куки да пароли, то вот и результат.
pit_art
18.08.2016 13:59+1Если сеть специально создана злоумышленником то роутер в его руках.
Это уже mitm, без всяких ухищрений с wpad.
kvant21
17.08.2016 14:09Только вот HTTPS вы не поломаете, подменив DHCP. А с WPAD — как оказалось, частично можете.
В любой недоверенной сети DHCP и DNS могут быть скомпрометированы, так что никакая безопасность на них строится не должна — и не строится, см. HTTPS/SSL/TLS.
albik
15.08.2016 20:31Этой «уязвимости» сто лет в обед, еще в прошлом году мейлрушники об этом рассказывали — https://habrahabr.ru/company/mailru/blog/259521/. Измельчал DefCon и специалисты по информационной безопасности, что такие глупости преподносят под соусом «на острие атаки».
Sleuthhound
15.08.2016 20:39Это не уязвимость, а такой принцип работы авто конфигурирования прокси. А первые упоминания об эксплуатации wpad исходят ещё к 2009 году и отчету Positive Technologies, погуглите и найдёте этот отчёт.
matrix9164
16.08.2016 11:28Все дело в том, что популярные VPN-клиенты, вроде OpenVPN, не очищают сетевые настройки, заданные WPAD. Это означает, что если атакующему уже удалось установить на ПК жертвы свои настройки прокси, прежде, чем на этом ПК было установлено соединение с VPN, то трафик также будет идти через прокси-сервер злоумышленника. Это открывает возможность получения всех данных, указанных выше.
А я вот никак не пойму этого абзаца. Каким это интересно образом злоумышленник вклинится внутрь туннеля и что-то оттуда получит?
Тем более против MITM в OpenVPN есть специальная опция HMAC Signature Check (TLS-Auth).
Vindicar
19.08.2016 08:58Если я правильно понял, идея в том, что VPN-решения работают уровнем ниже и настройки проксирования не трогают. Трафик будет идти по цепочке клиент-туннель-vpn сервер-прокси злоумышленника-целевой сайт. Таким образом, внутрь туннеля злоумышленник не попадет, но запрос всё равно будет проведен через его прокси — уже после выхода из туннеля.
matrix9164
19.08.2016 10:01Да не должно такого быть в любом раскладе. Должно быть «Клиент — прокси — VPN сервер — целевой ресурс». И потенциальный хацкер увидит только шифрованный тоннель, от которого толку нет.
Vindicar
19.08.2016 11:40Почему же? Давайте по шагам. Обычно трафик идет по цепочке: браузер — gateway — целевой ресурс (упрощенно).
Теперь рассмотрим ситуацию, когда компьютер подключается к скомпрометированной сети и получает настройки WPAD. Если прокси находится за gateway, то получаем цепочку: браузер — gateway — прокси — целевой ресурс.
Пользователь активирует VPN подключение. VPN, как правило, меняет только default gateway, но НЕ трогает системные настройки прокси. Иными словами, туннель вклинивается на место gateway. Тогда получаем цепочку: клиент — [tun/tap = gateway = vpn сервер] — прокси — целевой ресурс ([=] означает туннель). Это в том случае, если сам VPN игнорирует настройки прокси.
Чтобы получилась ваша схема, нужно чтобы а) VPN клиент тоже подцепил настройки прокси и б) браузер отказался от использования прокси после поднятия VPN. Если произойдёт только a) (наиболее вероятный вариант), получим следующую цепочку: клиент — [tun/tap = gateway = прокси = vpn server] — прокси — целевой ресурс. Т.е. трафик будет проходить через прокси дважды, один раз завернутый в туннель (согласно настройкам VPN клиента), а второй раз (согласно настройкам браузера) уже нет. Ключевым является то, что браузер ничего не знает о необходимости отказаться от прокси после поднятия VPN.
Во всяком случае, я понимаю логику работы именно так. Если вы видите ошибку в моих рассуждениях, прошу указать.Vindicar
19.08.2016 11:55Подумал еще, и заметил одну вещь…
Как именно VPN клиент взаимодействует с настройкаим прокси?
Пусть есть сеть с default gateway 192.168.0.1, клиентом 192.168.0.100 и VPN сервером вне сети, скажем. по внешнему адресу 100.100.100.100 и внутренними адресами 10.1.0.0/24.
Без прокси, VPN клиент (упрощенно) ставит маршрут до 100.100.100.100 через 192.168.0.1, а как default gateway ставит 10.1.0.1. Тогда весь трафик, кроме трафика на адрес VPN сервера, идет через tun/tap интерфейс, шифруется, и по первому маршруту попадает на VPN сервер.
Если есть прокси, VPN клиент не может прописать первый маршрут просто на сервер — ведь без прокси он не сможет установить соединение с внешней сетью. Он должен вместо этого прописать маршрут через default gateway до прокси сервера, и использовать прокси для установки соединения с VPN сервером.
Но если браузер настроен на использование того же самого прокси (а это обеспечивается WPAD), то его трафик на адрес прокси, по идее, должен пойти прямо по прописанному маршруту, не затрагивая VPN вообще!
xforce
А можно объяснить, каким образом что-то, не относящееся к днс имени, магически попадает в днс запрос? Это что такое в этом WPAD должно быть написано? Бегло посмотрел ПДФ из ссылок, не увидел там такого или не туда смотрел? Если такого нет, то это ничем не опаснее подмены DHCP.
Vindicar
JS-скрипту, выполняемому в контексте PAC, доступен полный запрашиваемый URL и функция dnsResolve(). Соответственно, если PAC файл скомпрометирован, злоумышленник может вызвать эту функцию, поместив в доменное имя интересующую его информацию, которую расшифрует его собственный DNS сервер.
После чего можно либо просто вернуть 'DIRECT' (подключаться напрямую), либо, для интересующих не-HTTPS ресурсов, 'PROXY evil.addr'.
xforce
Вот, теперь ясно, спасибо. Про JS я забыл. Нашел даже статью про описание метода на хабре — https://habrahabr.ru/company/mailru/blog/259521/