Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Полный адрес HTTPS URL должны быть скрыт, поскольку он содержит токены аутентификации и другую частную информацию. Но злоумышленник может восстановить адрес. Например, example.com/login?authtoken=ABC1234 может быть восстановлен путем использования DNS-запроса https.example.com.login.authtoken.ABC1234.leak и восстановлен на сервере киберпреступника.
А можно объяснить, каким образом что-то, не относящееся к днс имени, магически попадает в днс запрос? Это что такое в этом WPAD должно быть написано? Бегло посмотрел ПДФ из ссылок, не увидел там такого или не туда смотрел? Если такого нет, то это ничем не опаснее подмены DHCP.
JS-скрипту, выполняемому в контексте PAC, доступен полный запрашиваемый URL и функция dnsResolve(). Соответственно, если PAC файл скомпрометирован, злоумышленник может вызвать эту функцию, поместив в доменное имя интересующую его информацию, которую расшифрует его собственный DNS сервер.
После чего можно либо просто вернуть 'DIRECT' (подключаться напрямую), либо, для интересующих не-HTTPS ресурсов, 'PROXY evil.addr'.
После чего можно либо просто вернуть 'DIRECT' (подключаться напрямую), либо, для интересующих не-HTTPS ресурсов, 'PROXY evil.addr'.
Вот, теперь ясно, спасибо. Про JS я забыл. Нашел даже статью про описание метода на хабре — https://habrahabr.ru/company/mailru/blog/259521/
До кучи, наверное, можно попробовать ещё отключить и службу автоматического обнаружения веб-прокси WinHTTP (WinHttpAutoProxySvc). Правда, у неё в зависимостях «вспомогательная служба IP», которая, как я понимаю, отвечает за поддержку 6to4 и Teredo.
Да можно много всего наотключать, но непонятно, зачем. WPAD подсовывается с DHCP. Мне уже разок попадалась ссылка на эту статью, там мне никто не смог объяснить, каким образом подкидывание WPAD дает большую дыру, чем возможность развернуть левый DHCP сервер в сети, который неободим для передачи WPAD.
Например, тем, что wpad-запрос может вырваться за пределы сети.
Если комп находится в домене city.example.office, то wpad будет последовательно искать:
wpad.city.example.office.
wpad.example.office.
wpad.office.
wpad.
И на одном из этапов можно подсунуть свой pac-файл, и направить трафик туда, куда надо.
Если комп находится в домене city.example.office, то wpad будет последовательно искать:
wpad.city.example.office.
wpad.example.office.
wpad.office.
wpad.
И на одном из этапов можно подсунуть свой pac-файл, и направить трафик туда, куда надо.
WPAD подсовывается с DHCP.Не только через DHCP, кстати.
Интересно, что Firefox игнорирует настройки WPAD, полученные по DHCP.
Странно все это.
Для работы wpad должна быть сделана соответствующая настройка на dhcp-сервере (dhcp option 252), или же в некоторых случаях можно обойтись компрометацией dns-сервера
Если в руках злоумышленников находится dhcp и/или dns сервер сети — право же wpad меньшая из проблем.
Для работы wpad должна быть сделана соответствующая настройка на dhcp-сервере (dhcp option 252), или же в некоторых случаях можно обойтись компрометацией dns-сервера
Если в руках злоумышленников находится dhcp и/или dns сервер сети — право же wpad меньшая из проблем.
Если сеть специально создана злоумышленником, комп автоматом цепляется к открытым сетям, а всевозможные приложения на нём открывают сайты и передают куки да пароли, то вот и результат.
Только вот HTTPS вы не поломаете, подменив DHCP. А с WPAD — как оказалось, частично можете.
В любой недоверенной сети DHCP и DNS могут быть скомпрометированы, так что никакая безопасность на них строится не должна — и не строится, см. HTTPS/SSL/TLS.
В любой недоверенной сети DHCP и DNS могут быть скомпрометированы, так что никакая безопасность на них строится не должна — и не строится, см. HTTPS/SSL/TLS.
Этой «уязвимости» сто лет в обед, еще в прошлом году мейлрушники об этом рассказывали — https://habrahabr.ru/company/mailru/blog/259521/. Измельчал DefCon и специалисты по информационной безопасности, что такие глупости преподносят под соусом «на острие атаки».
Все дело в том, что популярные VPN-клиенты, вроде OpenVPN, не очищают сетевые настройки, заданные WPAD. Это означает, что если атакующему уже удалось установить на ПК жертвы свои настройки прокси, прежде, чем на этом ПК было установлено соединение с VPN, то трафик также будет идти через прокси-сервер злоумышленника. Это открывает возможность получения всех данных, указанных выше.
А я вот никак не пойму этого абзаца. Каким это интересно образом злоумышленник вклинится внутрь туннеля и что-то оттуда получит?
Тем более против MITM в OpenVPN есть специальная опция HMAC Signature Check (TLS-Auth).
Если я правильно понял, идея в том, что VPN-решения работают уровнем ниже и настройки проксирования не трогают. Трафик будет идти по цепочке клиент-туннель-vpn сервер-прокси злоумышленника-целевой сайт. Таким образом, внутрь туннеля злоумышленник не попадет, но запрос всё равно будет проведен через его прокси — уже после выхода из туннеля.
Да не должно такого быть в любом раскладе. Должно быть «Клиент — прокси — VPN сервер — целевой ресурс». И потенциальный хацкер увидит только шифрованный тоннель, от которого толку нет.
Почему же? Давайте по шагам. Обычно трафик идет по цепочке: браузер — gateway — целевой ресурс (упрощенно).
Теперь рассмотрим ситуацию, когда компьютер подключается к скомпрометированной сети и получает настройки WPAD. Если прокси находится за gateway, то получаем цепочку: браузер — gateway — прокси — целевой ресурс.
Пользователь активирует VPN подключение. VPN, как правило, меняет только default gateway, но НЕ трогает системные настройки прокси. Иными словами, туннель вклинивается на место gateway. Тогда получаем цепочку: клиент — [tun/tap = gateway = vpn сервер] — прокси — целевой ресурс ([=] означает туннель). Это в том случае, если сам VPN игнорирует настройки прокси.
Чтобы получилась ваша схема, нужно чтобы а) VPN клиент тоже подцепил настройки прокси и б) браузер отказался от использования прокси после поднятия VPN. Если произойдёт только a) (наиболее вероятный вариант), получим следующую цепочку: клиент — [tun/tap = gateway = прокси = vpn server] — прокси — целевой ресурс. Т.е. трафик будет проходить через прокси дважды, один раз завернутый в туннель (согласно настройкам VPN клиента), а второй раз (согласно настройкам браузера) уже нет. Ключевым является то, что браузер ничего не знает о необходимости отказаться от прокси после поднятия VPN.
Во всяком случае, я понимаю логику работы именно так. Если вы видите ошибку в моих рассуждениях, прошу указать.
Теперь рассмотрим ситуацию, когда компьютер подключается к скомпрометированной сети и получает настройки WPAD. Если прокси находится за gateway, то получаем цепочку: браузер — gateway — прокси — целевой ресурс.
Пользователь активирует VPN подключение. VPN, как правило, меняет только default gateway, но НЕ трогает системные настройки прокси. Иными словами, туннель вклинивается на место gateway. Тогда получаем цепочку: клиент — [tun/tap = gateway = vpn сервер] — прокси — целевой ресурс ([=] означает туннель). Это в том случае, если сам VPN игнорирует настройки прокси.
Чтобы получилась ваша схема, нужно чтобы а) VPN клиент тоже подцепил настройки прокси и б) браузер отказался от использования прокси после поднятия VPN. Если произойдёт только a) (наиболее вероятный вариант), получим следующую цепочку: клиент — [tun/tap = gateway = прокси = vpn server] — прокси — целевой ресурс. Т.е. трафик будет проходить через прокси дважды, один раз завернутый в туннель (согласно настройкам VPN клиента), а второй раз (согласно настройкам браузера) уже нет. Ключевым является то, что браузер ничего не знает о необходимости отказаться от прокси после поднятия VPN.
Во всяком случае, я понимаю логику работы именно так. Если вы видите ошибку в моих рассуждениях, прошу указать.
Подумал еще, и заметил одну вещь…
Как именно 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 вообще!
Как именно 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 вообще!
В Firefox 51 по умолчанию отключена передача PAC-скрипту полных URL (будут передаваться только имена хостов).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимость в WPAD позволяет получать доступ к данным, защищенным при помощи HTTPS и VPN