BadWPAD

BadWPAD – klasa ataków wykorzystujących słabości protokołu Web Proxy Auto-Discovery Protocol (WPAD), służącego do automatycznego wykrywania konfiguracji serwera proxy przez komputery klienckie. Atakujący, który zdoła podszyć się pod serwer WPAD, może narzucić ofierze własny plik konfiguracyjny i w efekcie przekierować przez kontrolowane przez siebie proxy część lub całość ruchu sieciowego, co umożliwia atak man in the middle, przechwytywanie danych uwierzytelniających, a w niektórych scenariuszach zdalne wykonanie kodu.

Problem jest znany od 1999 roku i pozostaje aktualny: protokół WPAD nie doczekał się statusu RFC, a mimo to jest domyślnie włączony w systemach Windows i obsługiwany przez wszystkie popularne przeglądarki.

Mechanizm

WPAD został opisany w szkicu internetowym draft-ietf-wrec-wpad-01, który wygasł w grudniu 1999 roku i nigdy nie stał się standardem. Jego celem jest wskazanie klientowi adresu pliku konfiguracyjnego PAC (proxy auto-config) – skryptu w języku JavaScript zawierającego funkcję FindProxyForURL, która dla każdego żądanego adresu wskazuje właściwe proxy.

Klient poszukuje serwera WPAD kolejno przez DHCP (opcja 252), protokół SLP oraz DNS. W wariancie DNS do nazwy sieci dopisywany jest przedrostek wpad, a jeśli zapytanie nie przyniesie odpowiedzi, klient usuwa skrajnie lewy człon nazwy i powtarza próbę – aż do osiągnięcia domeny najwyższego poziomu. Mechanizm ten nosi nazwę DNS devolution.

To właśnie on odpowiada za podstawowe zagrożenie: komputer skonfigurowany z sufiksem DNS um.warszawa.pl odpyta kolejno wpad.um.warszawa.pl, wpad.warszawa.pl i wreszcie wpad.pl – a więc nazwę spoza granic organizacji, którą może zarejestrować dowolna osoba. Jeżeli żadna z metod nie zadziała, klient sięga po protokoły rozgłoszeniowe NetBIOS (NBNS), LLMNR i mDNS, szukając nazwy wpad.local.

Historia

Pierwszą podatność związaną z WPAD odnotowano w 1999 roku jako CVE-1999-0858. Microsoft opublikował wówczas biuletyn bezpieczeństwa MS99-054, opisujący dokładnie problem schodzenia zapytań w dół hierarchii nazw: klient w domenie a.b.microsoft.com odpytuje kolejno wpad.a.b.microsoft.com, wpad.b.microsoft.com i wpad.microsoft.com, a w zastosowaniach międzynarodowych domena trzeciego poziomu może nie być zaufana.

Pierwsza publikacja naukowa poświęcona zagrożeniom związanym z WPAD ukazała się dopiero w 2003 roku. W kolejnych latach opisano m.in. ataki przekaźnikowe na uwierzytelnianie NTLM, przechwytywanie ruchu SSL/TLS oraz wykonywanie złośliwego kodu JavaScript zawartego w pliku PAC. Do 2022 roku zarejestrowano 23 podatności CVE zawierające w opisie słowo wpad.

Przełomem było wystąpienie Qi Alfreda Chena i współpracowników na konferencji IEEE Symposium on Security and Privacy w 2016 roku, poświęcone atakom typu name collision. Wykazano w nim, że znaczna liczba wewnętrznych zapytań o WPAD wycieka do publicznych serwerów DNS, a do przejęcia roli serwera WPAD wystarczy zarejestrować odpowiednią domenę – co ułatwiło wprowadzenie nowych domen gTLD w 2013 roku. W następstwie tej pracy amerykański US-CERT wydał w maju 2016 roku ostrzeżenie TA16-144A dotyczące podatności na kolizję nazw WPAD. W tym samym roku Maxim Gonczarow przedstawił na konferencji Black Hat analizę wycieków zapytań WPAD, wskazując m.in. rejestrującego, do którego należały domeny wpad.pl, wpad.sk i wpad.be.

W grudniu 2017 roku zespół Google Project Zero opublikował atak nazwany aPAColypse now, łączący błędy silnika JScript wykonującego pliki PAC z technikami omijania zabezpieczeń Windows 10 i prowadzący do zdalnego wykonania kodu z uprawnieniami systemowymi.

Wykorzystanie w atakach

 Zobacz też: NTLM#Bezpieczeństwo.

Ponieważ w ostatnim kroku klient szuka serwera WPAD przez protokoły rozgłoszeniowe, atakujący w tej samej sieci lokalnej może odpowiedzieć na takie zapytanie i skierować komunikację ofiary do kontrolowanego przez siebie systemu. Jeśli ten system zażąda uwierzytelnienia, komputer ofiary prześle mu nazwę użytkownika i odpowiedź NTLMv2 (tzw. Net-NTLMv2). Atakujący może ją następnie złamać w trybie offline, aby odtworzyć hasło, albo przekazać do innego serwera w ataku przekaźnikowym (ang. relay).

Kontrolując plik PAC, atakujący może też modyfikować nieszyfrowany ruch HTTP aplikacji, które z niego korzystają. Pokazano to na przykładzie aplikacji Battle.net, używanej przez miliony graczy, w której podmiana treści przesyłanych przez HTTP pozwalała prowadzić ataki socjotechniczne (spear phishing) bez użycia poczty elektronicznej.

Najgłośniejszym przypadkiem wykorzystania WPAD było złośliwe oprogramowanie Flame, wykryte w 2012 roku i wymierzone w komputery na Bliskim Wschodzie. Odpowiadając na rozgłoszeniowe zapytania NBNS o WPAD, Flame podszywał się pod serwery aktualizacji Windows i dostarczał ofiarom własne pliki jako aktualizacje systemu.

Z mechanizmu korzystały też trojany bankowe. Od 2009 roku odnotowywano złośliwe oprogramowanie wymuszające na zainfekowanych komputerach pobranie spreparowanego pliku PAC. W 2013 roku funkcję taką miała większość brazylijskich trojanów bankowych, a w 2014 roku wykryto trojana Blackmoon, przekierowującego klientów południowokoreańskich banków na strony phishingowe.

Przypadek polskich domen wpad.*.pl

W 2019 roku badanie zapoczątkowane przez Gonczarowa kontynuował polski zespół RED TEAM, którego ustalenia opisał Adam Ziaja. Osiemnaście domen wpad w polskiej domenie krajowej – w tym wpad.pl, wpad.com.pl, wpad.warszawa.pl i wpad.katowice.pl – wskazywało na jeden adres IP w Niemczech, z którego serwowano plik konfiguracyjny PAC. Ten sam adres obsługiwał kilkadziesiąt domen wpad w innych rozszerzeniach, m.in. czeskiej, włoskiej, łotewskiej i tajwańskiej.

Domeny były rejestrowane od 2007 roku przez prywatną spółkę, która przedstawiała przedsięwzięcie jako projekt ochronny. Archiwalne kopie plików wpad.dat z lat 2015–2017, odtworzone z archiwum internetu, zawierały jednak zaciemnione wyrażenia regularne kierujące przez wskazane proxy część ruchu do programów partnerskich, a domena wpad.pl przekierowywała do programu afiliacyjnego serwisu Booking.com.

Po ujawnieniu sprawy właściciel przekazał domeny pod kontrolę NASK, a CERT Polska skierował je na sinkhole i opublikował analizę techniczną. W tygodniu od 15 do 22 maja 2019 roku sinkhole odnotował 6,5 mln żądań HTTP z około 40 tysięcy unikatowych adresów IP. Powiadomione zostały również zespoły CERT właściwe dla pozostałych domen najwyższego poziomu, a część domen przejęła firma Cloudflare.

Skala zagrożenia

Według danych NASK przytoczonych w przeglądzie opublikowanym w ACM Computing Surveys zespół monitorował 153 domeny wpad. W okresie od 27 maja do 12 lipca 2021 roku sinkhole odnotowywał średnio 1,13 mln zapytań dziennie pochodzących średnio z 5800 różnych adresów IP, przy czym najczęściej odpytywanymi domenami były wpad.com.pl i wpad.pl. Autorzy przeglądu wskazują, że liczby te dowodzą, iż mechanizm DNS devolution jest nadal realizowany aż do poziomu domeny najwyższego poziomu przez dużą liczbę klientów.

Przeciwdziałanie

Zalecenia opracowane po ostrzeżeniu US-CERT obejmują wyłączenie WPAD na stacjach roboczych tam, gdzie serwery proxy nie są potrzebne, wpisywanie adresów proxy na stałe w konfiguracji systemów, stosowanie w sieciach firmowych pełnych nazw domenowych zamiast wewnętrznych domen najwyższego poziomu oraz blokowanie wychodzących zapytań o nazwy zaczynające się od wpad.

Autorzy przeglądu w ACM Computing Surveys zwracają uwagę, że powierzchnia ataku jest na tyle szeroka, iż usunięcie wszystkich problemów jest praktycznie niewykonalne, a wykrywanie ataków bywa zawodne – złośliwy plik PAC może przekierowywać jedynie wąsko wybrany ruch, pozostawiając resztę aktywności komputera bez zmian.

Przypisy

Linki zewnętrzne

• Alert TA16-144A: WPAD Name Collision Vulnerability [online], CISA  (ang.).