Wprowadzenie
Dzisiaj o ataku BadWPAD, dzięki któremu można podsłuchiwać i modyfikować niezaszyfrowany ruch internetowy na twoim komputerze.
Myślisz że temat Cię nie dotyczy?
Jeżeli używasz Windowsa i przeglądarki internetowej, istnieje spora szansa, że używasz (bądź używałeś) tej funkcji w przeszłości, nawet nie zdając sobie z tego sprawy.
Jeżeli materiały tego rodzaju Ci się podobają, zapraszam do dołączenia do grupy od 0 do pentestera na Facebooku, gdzie dzielimy się swoją wiedzą z zakresu bezpieczeństwa komputerowego.
Serwer proxy
W środowisku korporacyjnym często mamy do czynienia z sytuacją, kiedy to komputery pracowników powinny łączyć się ze stronami w Internecie przy użyciu serwerów proxy.
Żeby komputer łączył się z Internetem poprzez serwer proxy, musi zostać w odpowiedni sposób skonfigurowany.
W przypadku małej firmy nie jest to dużym problemem.
Administrator może ręcznie skonfigurować odpowiednie ustawienia na każdej z maszyn.
Sytuacja komplikuje się jednak w przypadku dużych sieci ze spora ilością komputerów.
Dodatkowo musimy rozważyć sytuację: co w przypadku, gdy zmieni się chociażby adres serwera proxy lub też firma w ogóle z niego zrezygnuje?
Czy za każdym razem administrator musi wszystko zmieniać ręcznie?
Web Proxy Auto-Discovery Protocol
WPAD to technologia, która pozwala przeglądarkom na automatyczne wykrycie lokalizacji plików PAC przy użyciu DNS albo DHCP.
Każdy komputer przed połączeniem z witryną najpierw powinien sprawdzić swoją konfigurację serwera proxy.
W tym celu łączy się z serwerem, na którym to hostowany jest plik PAC (z angielskiego: proxy auto-config).
Plik ten to tak naprawdę plik z kodem JavaScript zawierający funkcję FindProxyForURL.
Przeglądarka każdy adres, który ma zostać odwiedzony przez użytkownika, przekazuje do tej funkcji.
W odpowiedzi zwraca ona, czy strona powinna zostać odwiedzona bezpośrednio, czy też może z użyciem konkretnego serwera proxy.
W ten oto prosty sposób można zdefiniować czy i kiedy użytkownik danego komputera do połączeń z daną domeną powinien używać serwera proxy.
Plik PAC
WPAD, czyli Web Proxy Auto-Discovery Protocol, zawiera mechanizmy, które służą do znalezienia odpowiedniego pliku pac.
Pierwszy wykorzystuje serwer DHCP, drugi natomiast DNS.
W przypadku, gdy plik PAC nie został odnaleziony przy użyciu pierwszej metody, przeglądarka automatycznie wykorzystuje drugą.
W przypadku metody pierwszej wysyłany jest specjalny pakiet do serwera DHCP z prośbą o zwrócenie specjalnej opcji o numerze 252.
Jeżeli jest ona skonfigurowana - serwer w odpowiedzi zwraca bezpośredni adres do pliku PAC, który następnie jest pobierany przez przeglądarkę.
Zostało tutaj jednak poczynione jedno dość mocne założenie.
Zakładamy, że serwer DHCP jest nieszkodliwy i kontrolowany przez naszą organizację.
Ale przecież nie zawsze musi tak być.
Protokół ten bowiem był tworzony w czasach, gdy praktycznie nie istniały komputery przenośne i wszystkie urządzenia były wpinane do sieci korporacyjnej przy użyciu kabla.
Ale to już dawno uległo zmianie.
Plik PAC poprzez DHCP
Załóżmy, że podłączamy się do Internetu przy użyciu otwartej sieci Wi-Fi na lotnisku.
Serwer DHCP kontrolowany przez lotnisko przydziela nam konkretny adres IP.
Jeżeli nasz komputer ma włączoną opcję "automatycznego wykrywania ustawień", oprócz prośby o adres IP, wyśle również zapytanie do serwera DHCP z prośbą o plik PAC.
Dzięki temu administratorzy lotniska mogą kontrolować serwery, przez które będzie przechodził nasz ruch.
Jest to więc idealna metoda do przeprowadzenia ataku Man in the middle, kiedy to część naszego ruchu nie trafia bezpośrednio do serwera z którym chcemy się komunikować, lecz po drodze jest przesyłana do innego - kontrolowanego przez atakujących.
Ten przykład jest jednak nieco na wyrost.
W przypadku otwartych sieci Wi-Fi właściciel takiej sieci i tak kontroluje nasz ruch - i to bez protokołu WPAD.
PAC poprzez DNS
O co więc cały ten ambaras?
WPAD obsługuje również metodę pozyskiwania pliku PAC poprzez użycie DNS.
Weźmy pod uwagę firmę, która korzysta z Active Directory do zarządzania wszystkimi zasobami w organizacji.
Każdy komputer może mieć skonfigurowaną listę przeszukiwania sufiksów DNS.
Lista ta jest stosowana przy rozwiązywaniu nazw o pojedynczej etykiecie.
A mówiąc prościej: jeżeli chcemy połączyć się z innym komputerem, nie musimy wpisywać całego adresu w stylu: komputer1.nazwadomeny.local lecz możemy skorzystać z krótkiej nazwy komputer1.
Sufiks DNS
Jeżeli przeglądarka nie otrzymała pliku PAC z poziomu serwera DHCP, spróbuje skorzystać z alternatywnej metody DNS.
W tym celu bierze sufiks DNS i dokleja do niego wartość WPAD.
Popatrzmy na przykład: jeżeli nasz sufiks to korporacja.szurek.pl, przeglądarka wyśle zapytanie DNS z nazwą wpad.korporacja.szurek.pl.
Gdy taki serwer istnieje w obrębie danej sieci, spróbuje pobrać z niego przy użyciu protokołu http plik o nazwie wpad.dat.
W przypadku sukcesu całej operacji zostanie on wykorzystany - czyli będzie służył do ustalania które domeny mają być odwiedzane przy użyciu serwera proxy.
Jak na razie wszystko jest w porządku.
Administrator kontroluje domenę korporacja.szurek.pl, może więc w niej stworzyć komputer o nazwie wpad, którego to jedynym zadaniem będzie wyświetlanie odpowiedniego pliku wpad.dat.
W przypadku jakiejkolwiek zmiany konfiguracji - wystarczy zmienić wpis właśnie w tym miejscu, a zmiana zostanie automatycznie rozpropagowana na wszystkie maszyny w obrębie danej domeny.
DNS name devolution
Ale w przeszłości wyglądało to nieco inaczej.
Jeżeli algorytm nie wykrył pliku wpad – działał dalej, próbując kolejne wersje adresów.
Z kronikarskiego obowiązku dodam jeszcze, że potrzebne było zaznaczenie opcji: „dołącz sufiksy nadrzędne podstawowego sufiksu dns”.
Wtedy, drugie żądanie było wysyłane do wpad.szurek.pl.
A kolejne do wpad.pl.
Takie zachowanie nazywa się DNS name devolution i okazało się być w pewnych przypadkach niebezpieczne.
Dlaczego?
Ponieważ w ostatnim kroku przeglądarka próbuje pobrać plik wpad ze strony wpad.pl.
A domena wpad.pl nie jest subdomeną domeny korporacja.szurek.pl i może należeć do innej osoby bądź instytucji.
Dochodziło więc do sytuacji w której komputer firmowy, który był źle skonfigurowany, mógł pobrać ustawienia serwera proxy z innej, niekontrolowanej przez daną firmę domeny.
A ponieważ ustawienia serwera proxy wpływają na to jak nasz komputer łączy się z każdą witryną, atakujący, który posiada regionalne domeny wpad może dość skutecznie kontrolować co i jak jest wyświetlane na stronach, które przeglądamy przy użyciu protokołu http.
Poprawka z 2009
Problem został dostrzeżony w 2009 roku, kiedy to wprowadzono poprawkę, która umożliwiała między innymi ustawienie maksymalnego poziomu, do którego rozwiązywane są domeny.
A więc opisywany problem nie jest już taki groźny, chyba że nasz komputer ma ustawiony sufiks DNS składający się tylko i wyłącznie z ciągu pl, com.pl, org.pl i tak dalej.
Można to sprawdzić wpisując w linii komend polecenie: ipconfig /all.
Polski akcent
I tutaj pojawia się ciekawy zwrot akcji.
Jeżeli domeny wpad.pl czy też wpad.com.pl są (lub były) tak interesujące z punktu widzenia bezpieczeństwa – to do kogo należą?
Tematowi przyjrzał się jakiś czas temu Adam Ziaja1 z firmy RedTeam.pl.
Zauważył on, że w rękach jednej osoby znajdowało się wiele domen wpad.
Mowa tutaj między innymi o wpad.cz, wpad.pl, wpad.it czy też wpad.tw.
Co więcej, w toku analizy okazało się, że domeny te serwowały prawidłowy plik wpad.dat.
W treści pliku znajdowały się specjalne reguły, których celem było zarabianie pieniędzy poprzez programy partnerskie różnych serwisów internetowych.
Duże serwisy dzielą się bowiem zyskami z osobami, które namawiają innych na odwiedzanie danych witryn.
W tym celu do odnośników doklejane są specjalne identyfikatory, które można było podmieniać na podstawie pliku PAC.
Dzięki temu w niewidoczny dla użytkownika końcowego sposób, właściciel domen wpad mógł zarabiać tylko dlatego, że komputery były błędnie skonfigurowane.
Po artykule Adama większość domen tego rodzaju została przejęta przez CERT Polska2, który monitoruje ich aktywność i dokłada wszelkich starań, aby nie były one używane w złych celach.
WPAD Name Collision
Ale to nie koniec – pora na WPAD Name Collision.
Na samym początku istnienia Active Directory zdarzało się, że jako nazwy domenowej używano nieistniejącej domeny.
Na przykład szurek.corp gdzie corp to nie jest prawidłowa domena.
W przypadku działania mechanizmu WPAD maszyna będzie się próbować połączyć z komputerem wpad.szurek.corp.
Gdy jesteśmy w obrębie sieci firmowej i mamy dostęp do firmowego serwera DNS – wszystko działa jak należy.
Ale co jeśli pracujemy poza biurem – chociażby w kawiarni?
Jeżeli firmowy serwer DNS nie jest dostępny – takie żądanie o nazwę DNS zostanie wysłane do publicznego serwera DNS.
A więc nasz system wyśle zapytanie: jaki adres IP ma komputer skojarzony z domeną wpad.szurek.corp.
Serwer DNS nie zwróci żadnego wyniku ponieważ corp nie jest prawidłową domeną – taka domena po prostu nie istnieje.
Jest tylko jedno małe ale.
Domeny najwyższego poziomu
Z roku na rok obserwujemy stale zwiększającą się liczbę domen najwyższego poziomu, które można zakupić.
Na samym początku Internetu istniało tylko kilka domen najwyższego poziomu takich jak org, net czy tez com.
Teraz możemy rejestrować domeny z końcówkami network lub global.
Może więc dojść do dziwnej sytuacji, kiedy to firma w Active Directory używa domeny, która jeszcze parę lat temu nie istniała – na przykład korporacja.global.
Teraz natomiast taka domena najwyższego poziomu istnieje i może zostać zakupiona chociażby przez konkurencję.
Jeżeli użytkownik będzie korzystał z komputera w kawiarni – gdzie nie ma dostępu do firmowego serwera DNS – wyśle żądanie o adres IP komputera wpad.korporacja.global.
Publiczny serwer DNS zwróci wtedy odpowiedni adres – o ile oczywiście taka domena została zarejestrowana.
Jeżeli na tym serwerze będzie się znajdował plik PAC – komputer użytkownika może nagle zacząć korzystać z zewnętrznego serwera proxy.
A to wszystko bez wiedzy użytkownika.
Zalecenia dla administratorów
Jeżeli więc jesteś administratorem rozważ wyłączenie opcji WPAD na komputerach użytkowników.
W systemie Windows należy przejść do opcji internetowych.
Tam w zakładce połączenia a dalej ustawienia sieci LAN należy odznaczyć opcję automatycznie wykryj ustawienia.
Warto też rozważyć zmianę domeny na taką, która należy do firmy.
Czyli zamiast szurek.corp spróbować przejść na szurek.pl (oczywiście jeżeli szurek.pl jest w naszym posiadaniu).
Można też w serwerze DHCP zdefiniować rekord 252 do pliku wpad.dat, który będzie zwracał wartość return "DIRECT" – informującą, że wszystkie połączenia maja się odbywać bez udziału serwera proxy.
Atak lokalny
Ale zdalny atak to nie wszystko.
Podatność ta może zostać nadużyta przez atakującego, który zdobył dostęp do wnętrza naszej sieci firmowej.
Wystarczy iż zmieni on nazwę jednego z komputerów podłączonych do domeny na wpad.
Wtedy to inne komputery zaczną komunikować się z tym jednym, w celu pozyskania informacji o serwerze proxy.
Taki atak nie jest trudny do przeprowadzenia.
Framework metasploit używany do pentestów posiada moduł, który wykonuje właśnie tą czynność.
Z tego też powodu można pokusić się o 2 dodatkowe kroki:
Pierwszy – stworzenie komputera o nazwie wpad, który zwraca plik wpad.dat.
Drugi – monitorować sieć i alarmować, gdy któryś z komputerów próbuje zmienić swoją nazwę na wpad.
