Do myślenia dał mi ostatnio ten post: Banking Malware uses PAC file. W tym przykładzie malware wprost ustawia adres skryptu PAC, z którego korzysta przeglądarka do określania przez jakie proxy powinna przesłać żądanie. Malware musi jednak jakoś ten klucz ustawić, czyli musi wejść na komputer. A co, jeśli wchodzić by nie musiał?
Czy WPAD może się przydać malware?
Jak zapewne wiecie istnieje mechanizm Web Proxy Autodiscovery Protocol za pomocą którego administrator sieci może przekazać klientom skrypt konfiguracyjny dla proxy. Adres ten może zostać przekazany przy pomocy:
- serwera DHCP,
- serwera DNS,
W tej chwili skupmy się może na przeglądarce Internet Explorer. Mechanizm działania WPAD w tym przypadku jest dość dobrze wyjaśniony we wpisie WPAD detection in Internet Explorer. Zwracam uwagę, że w tym przypadku wymienione są trzy mechanizmy:
- DHCP,
- DNS,
- NetBIOS,
W chwili uruchomienia przeglądarki IE można zaobserwować pakiet DHCP Inform, który na liście Parameter Request List zawiera między innymi opcję 252, czyli Private/Proxy autodiscovery. Jeśli serwer DHCP nie dostarczy oczekiwanej odpowiedzi, całość przechodzi do kolejnego kroku.
Kolejny krok to użycie DNS, czyli zapytanie o nazwę wpad.nazwa.domeny. Jeśli i tutaj nie ma odpowiedzi, następuje zapytanie NetBIOS o maszynę o nazwie WPAD.
Pytanie - jakie widzicie tutaj możliwości ataku? Mnie po głowie chodzi co najmniej:
- fałszywy serwer DHCP,
- odpowiadanie na zapytanie NetBIOS o nazwę WPAD,
Nie weryfikowałem tego, ale z dużym prawdopodobieństwem zadziałałoby:
- udzielenie odpowiedzi na zapytanie DHCP z odpowiednio uzupełnioną opcją 252,
- udzielenie odpowiedzi na zapytanie NetBIOS (albo zarejestrowanie tej nazwy w WINS),
Warto też zwrócić uwagę, że w przypadku Internet Explorer wyższy priorytet ma DHCP. Jakie to ma znaczenie? O tym za chwilę. Jednocześnie trzeba zwrócić uwagę, że Firefox DHCP nie wspiera, a i nie jestem przekonany, czy wykorzystywany jest NetBIOS.
Trzeba zauważyć, że opcja automatycznego wykrywania ustawień proxy jest domyślnie wyłączona. A przynajmniej takie mam wrażenie po sprawdzeniu konfiguracji IE i Firefox zaraz po instalacji. Być może się mylę, w razie czego proszę o sprostowanie. Jeśli rzeczywiście ta opcja jest domyślnie wyłączona, ilość potencjalnych ofiar tego teoretycznego cichego ataku ulega znacznej redukcji.
Wróćmy do DHCP. Zapytanie DHCP będą wysyłać klienci, którzy mają opcję WPAD aktywną. Skoro DHCP ma priorytet przed DNS, można próbować wbudować w malware odpowiedni serwer DHCP, który podrzucałby klientom z włączonym WPAD odpowiednio spreparowany plik konfiguracyjny. Akurat wbudowanie serwera DHCP w malware oryginalnym pomysłem nie jest, patrz: Rogue DHCP servers.
Można się zastanowić nad ROI związanym z implementacją takiego "ataku". Wydaje mi się, że głównym problemem mogłaby być dość ograniczona populacja potencjalnych ofiar. W zależności od przyjętej strategii populacja ta ograniczałaby się do użytkowników, którzy mają aktywną opcję automatycznej konfiguracji proxy, lub nawet dalej, do użytkowników Internet Explorer, którzy mają aktywną autokonfigurację. Chyba bardziej opłacalne byłoby zaszycie w malware mechanizmu arp-poisoning... Z drugiej strony chwila ze snifferem i znalazłem cztery potencjalne ofiary, więc może pomysł nie jest tak całkiem pozbawiony sensu? :)
EDIT: Właśnie korzystając z międzyczasu napisałem sobie prawie działającego PoC przy pomocy scapy. Prawie, bo muszę jeszcze zrobić do końca poprawne wypełnianie pakietu opcjami DHCP, ale większym problemem jest to, że mój PoC przegrywa wyścig z "prawdziwym" serwerem DHCP. Chyba dodatkowo będzie skłonić prawdziwy serwer DHCP do tego, by zajął się sobą. Ale niestety, międzyczas się skończył, koniec zabawy...
EDIT2: W drugim międzyczasie udało mi się podstawić WROGI serwer proxy z użyciem WPAD i DHCP. Koniec zabawy :)
udostepnisz src?
def dhcp_callback(pkt):
global fake
if pkt.haslayer(DHCP):
if fake and pkt[DHCP].options[0][1] == 8:
fake[Ether].dst = pkt[Ether].src
fake[IP].dst = pkt[IP].src
fake[BOOTP].xid = pkt[BOOTP].xid
fake[BOOTP].ciaddr = pkt[IP].src
fake[BOOTP].yiaddr = pkt[IP].src
fake[BOOTP].siaddr = '172.16.0.254'
fake[BOOTP].chaddr = pkt[BOOTP].chaddr
sendp(fake)
Podrabiany pakiet przygotowałem ręcznie, adres siaddr też wpisałem na sztywno, bo to tylko PoC w końcu. Dorzucenie opcji 252 to tylko dorzucenie do pkt[DHCP].options (252, "adres-do-skryptu-pac").
Można to rozwinąć preparując "szablon" pakietu na podstawie podsłuchanej odpowiedzi serwera DHCP, czyli najpierw czekamy na pierwszy pakiet z odpowiedzią, zapamiętujemy go, a później jak się pojawi pytanie, odsyłamy go odpowiednio wcześniej modyfikując.