Przejdź do zawartości

BadWPAD

Dodaj linki
Z Wikipedii, wolnej encyklopedii

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[1].

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[1].

Mechanizm

[edytuj | edytuj kod]

WPAD został opisany w szkicu internetowym draft-ietf-wrec-wpad-01, który wygasł w grudniu 1999 roku i nigdy nie stał się standardem[2][1]. 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[1].

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[1].

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[1][3]. 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[1].

Historia

[edytuj | edytuj kod]

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[4][1].

Pierwsza publikacja naukowa poświęcona zagrożeniom związanym z WPAD ukazała się dopiero w 2003 roku[1]. 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[1].

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[5][1]. 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[6]. 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[7][1].

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[8][1].

Wykorzystanie w atakach

[edytuj | edytuj kod]
 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)[9].

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[10].

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[1].

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[1].

Przypadek polskich domen wpad.*.pl

[edytuj | edytuj kod]

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[3][11].

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[3][12].

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[13][14]. 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[1].

Skala zagrożenia

[edytuj | edytuj kod]

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[1].

Przeciwdziałanie

[edytuj | edytuj kod]

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[15][1].

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[1].

Przypisy

[edytuj | edytuj kod]
  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Elyssa Boulila, Marc Dacier, WPAD: Waiting Patiently for an Announced Disaster, „ACM Computing Surveys”, 55 (10), 2023 [dostęp 2026-08-28] (ang.).
  2. ↑ Paul Gauthier, Josh Cohen, Martin Dunsmuir, Charles E. Perkins, Web Proxy Auto-Discovery Protocol. Internet-Draft draft-ietf-wrec-wpad-01 [online], IETF, 1999 [dostęp 2026-08-28] (ang.).
  3. 1 2 3 Adam Ziaja, BadWPAD, DNS suffix and wpad.pl / wpadblocking.com case [online], RED TEAM, 2 maja 2019 [dostęp 2026-08-28] (ang.).
  4. ↑ Microsoft Security Bulletin MS99-054 – Patch Available for „WPAD Spoofing” Vulnerability [online], Microsoft, 1 grudnia 1999 [dostęp 2026-08-28] (ang.).
  5. ↑ Qi Alfred Chen, Eric Osterweil, Matthew Thomas, Z. Morley Mao, MitM Attack by Name Collision: Cause Analysis and Vulnerability Assessment in the New gTLD Era, „2016 IEEE Symposium on Security and Privacy (SP)”, 2016, s. 675–690, DOI: 10.1109/SP.2016.46 (ang.).
  6. ↑ Alert TA16-144A: WPAD Name Collision Vulnerability [online], US-CERT, 23 maja 2016 [dostęp 2026-08-28] (ang.).
  7. ↑ Maxim Goncharov, badWPAD – The Lasting Menace of a Bad Protocol [online], Black Hat USA, 2016 [dostęp 2026-08-28] (ang.).
  8. ↑ Ivan Fratric, Thomas Dullien, James Forshaw, Steven Vittitoe, aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript [online], Google Project Zero, 18 grudnia 2017 [dostęp 2026-08-28] (ang.).
  9. ↑ Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay (T1557.001) [online], MITRE ATT&CK, 12 maja 2026 [dostęp 2026-09-30] (ang.).
  10. ↑ Adam Ziaja: BadWPAD and spear-phishing using Battle.net Desktop App. RED TEAM, 2020-07. [dostęp 2026-10-01]. (ang.).
  11. ↑ Kacper Szurek, BadWPAD [online], security.szurek.pl [dostęp 2026-08-28].
  12. ↑ Anna Wasilewska-Śpioch, Jak pewien Polak mógł latami przejmować ruch milionów komputerów [online], Zaufana Trzecia Strona, 23 lipca 2019 [dostęp 2026-08-28].
  13. ↑ Paweł Srokosz, Przejęcie domen.pl związanych z atakiem BadWPAD [online], CERT Polska, 14 czerwca 2019 [dostęp 2026-08-28].
  14. ↑ Krajobraz bezpieczeństwa polskiego internetu. Raport roczny 2019 z działalności CERT Polska [online], CERT Polska, 2020, s. 61–63 [dostęp 2026-08-28].
  15. ↑ Enterprise Remediation for WPAD Name Collision Vulnerability [online], Verisign, maj 2016 [dostęp 2026-08-28] (ang.).

Linki zewnętrzne

[edytuj | edytuj kod]
Źródło: „https://pl.wikipedia.org/w/index.php?title=BadWPAD&oldid=81091666”