Wprowadzenie do narzędzia Zed Attack Proxy (ZAP)

W wersji podstawowej, jest to program pośredniczący w ruchu HTTP i HTTPS, pozwalający zatrzymywać, edytować i odrzucać wysyłane żądania z przeglądarki internetowej. Niezwykle przydatny do sprawdzania zachowania web aplikacji, po wysłaniu danych innych, niż pozwala użytkownikowi jej frontend. Można to robić w czasie rzeczywistym (czyli zatrzymać żądanie, zmodyfikować i przesłać dalej), albo używając historii dotychczas wysłanych żądań, wraz z odpowiedziami serwera.

Dodatkowe funkcjonalności – jak różne skanery, fuzzery, słowniki, itp. – są dołączane jako dodatkowe moduły. Kilka z nich jest wstępnie dodanych; w dalszej części artykułu będą one traktowane jako część programu.

Jednym z założeń projektu, jest jego przystępność dla początkujących badaczy bezpieczeństwa. Dlatego można wybierać pomiędzy trybami pracy – od zupełnie bezpiecznych, aż do inwazyjnych – aby, ucząc się użycia programu, nie przeprowadzić nieautoryzowanych akcji. Dodatkowo, każda znaleziona klasa podatności jest opisana, wraz z podaniem sposobów, jak się przed nią chronić.

ZAP jest tworzony na zasadach OpenSource przez organizację OWASP, zajmującą się bezpieczeństwem w internecie. W założeniu twórców ma wspierać zarówno ręczne, jak i automatyczne testowanie aplikacji pod względem bezpieczeństwa.

Opisane niżej metody skanów/ataków (w ZAP każdy skan jest nazywany atakiem), są przedstawione w nieprzypadkowej kolejności. Jest to bowiem scenariusz prostego testu bezpieczeństwa aplikacji.

Rozpoczęcie

Konfiguracja HTTP

Pierwszy krok, to ustawienie w przeglądarce łączenia się przez proxy (w tym przypadku lokalnego ZAPa). Domyślne dane do połączenia lokalnego, to:

serwer: 127.0.0.1 port: 8080

Rys. 1 Konfiguracja ZAP

(Uwaga – często w przeglądarkach jest lista wyjątków od proxy, a w niej domyślnie localhost lub 127.0.0.1. Jeżeli testujemy aplikację lokalną, warto usunąć ten wyjątek)

Od teraz, cała komunikacja przechodzi przez ZAP-a. Każde nowe żądanie widać w zakładce Sites.

Rys.2 Okno wykrytych zasobów

Flaga przy zasobie oznacza znalezione potencjalne luki w bezpieczeństwie – im bardziej czerwona flaga, tym poważniejsza potencjalna luka.

Konfiguracja HTTPS

Aby używać naszego narzędzia jako proxy w przeglądarce na stronach wymagających https, potrzebujemy zaimportować certyfikaty ZAP-a do przeglądarki. W przeciwnym wypadku, przeglądarka będzie pokazywała stronę z informacją o nieprawidłowym certyfikacie, bądź – w przypadku nagłówka HSTS – w ogóle nie pozwoli wejść na żądną stronę. Certyfikat znajduje się w ustawieniach ZAP, w zakładce Dynamic SSL Certificates.

Rys. 3 Certyfikat w opcjach ZAP przed importem do przeglądarki

Co to są konteksty

Aplikację internetową można testować jednocześnie z kilku różnych poziomów dostępu, np.:

• jako nie zalogowany użytkownik,
• zalogowany na konto podstawowe,
• zalogowany z uprawnieniami administratora (zakładka Users i Authorization w edycji kontekstu).

Dodatkowo, część aplikacji może mieć inną strukturę składania parametrów w URL (zakładka Structure). Tutaj pomocne będą konteksty. Wystarczy stworzyć osobny kontekst dla każdego użytkownika, którego będziemy testować, a następnie, klikając prawym przyciskiem myszy na interesujących zasobach, dołączyć do wybranych kontekstów.

Podwójny klik na kontekst otwiera okno jego właściwości.

W trybie pracy Protected, konteksty mogą służyć również jako wydzielenie części strony do testów – aby uruchamiane skanery podatności, nie atakowały postronnych zasobów.

Modyfikacja żądań w czasie rzeczywistym (Proxy)

ZAP umożliwia przechwytywanie i edycję żądań do serwera. Do tego celu służy ikonka okrągłego przycisku…

Po kliknięciu jej, a następnie wejściu na dowolną stronę używając skonfigurowanej przeglądarki, w zakładce Break pokaże się całe żądanie. W razie potrzeby, możemy odrzucić żądanie – po to, aby np. sprawdzić, co zrobi aplikacja, gdy nie otrzyma odpowiedzi.

W zakładce History, w trybie ciągłym, zapamiętywana jest komunikacja z serwerem. Po wybraniu żądania, można je obejrzeć wraz z odpowiedzią. Klikając prawym przyciskiem myszy na historii i wybierając opcję Resend, można edytować i wysłać ponownie żądanie (analogicznie jak Repeater w konkurencyjnym programie BurpSuite).

Rys. 4 Historia stron

Ataki/Skanery

Spider

Po manualnym odkryciu najważniejszych zasobów, czas na ujawnienie tych mniej oczywistych. Pomoże w tym skan z użyciem narzędzia Spider:

Rys. 5 Wybór dostępnych ataków na wybrany zasób

W trakcie skanu, na liście zasobów będą pojawiać się te nowo odkryte.

Jeżeli interesują nas grafiki dociągane w trakcie działania strony skrypty JavaScript, albo komunikacja Ajaxowa z “żywą” przeglądarką – przydatny będzie AJAX Spider. W tej sytuacji, proces skanowania trwa znacznie dłużej, ponieważ po załadowaniu strony, czeka on w zadanym czasie na ewentualne pobieranie kolejnych zasobów. Pozwala jednak podejrzeć zasoby ściągane przez JavaScript, zaraz po załadowaniu strony.

Forced Browse

A co w przypadku, gdy na stronie znajdują się zasoby w tzw. “głębokim ukryciu”, czyli nigdzie nie podlinkowane (w nadziei, że nie będą znalezione przez osoby postronne)?

Albo, gdy programiści zapomnieli usunąć pliki konfiguracyjne, bądź repozytorium?

Z pomocą przychodzi atak Forced Browse. Sprawdza on na zasadzie “brute force”, czy w badanej aplikacji istnieją zasoby o popularnych nazwach. Zakres poszukiwań można rozszerzać, poprzez dodawanie plików z frazami w ustawieniach programu.

Rys. 6 Ustawienia do ataku Forced Browse

Fuzzer

Gdy znajdziemy, które parametry są wysyłane do aplikacji, możemy spróbować przeprowadzić ataki wstrzykujące kod, albo z wykorzystaniem niestandardowych danych. Podczas podglądu dowolnego żądania, wystarczy zaznaczyć zmieniający się ciąg znaków.

Tutaj posłużyło narzędzie Resend na historycznych żądaniach:

Rys. 7 Zidentyfikowana wysyłana zmienna

Następnie, należy wybrać Fuzz. Możemy dobrać kilka różnych miejsc do fuzzingu jednocześnie, każde jest zaznaczone innym kolorem. Po czym, wybieramy wartości jakie chcemy podstawić w wybrane miejsce (tzw. payloads). W tym przypadku jest to wyszukiwarka na stronie, więc z pewnością warto sprawdzić, czy jest podatna na Cross-Site-Scripting (XSS).

Rys. 8 Wybór payloadów w Fuzzerze

W kolejnym kroku, wybieramy w jaki sposób przekazywane są wartości do aplikacji – czy są one zakodowane w base64, md5, czy też w inny sposób. W tym przykładzie, fuzzowany ciąg znaków znajduje się w URLu, więc wybieramy URL Encode, aby wyglądał jakby rzeczywiście był wysłany przez przeglądarkę (akurat w URLu można pominąć ten krok – ZAP sam zamieni znaki na prawidłowe).

Rys 9. Wybór sposobu kodowania w Fuzzerze

Gdy będziemy mieli trochę szczęścia, ZAP sam zaznaczy, na które dane aplikacja jest podatna. Warto dodatkowo przeanalizować odpowiedzi na wysłane payloady – mogą naprowadzić nas na nie znalezione wcześniej problemy. Polecam odrębne otwieranie poszczególnych skanów w przeglądarce i śledzenie ich wyników.

Rys. 10 Wyniki Fuzzera

Active Scan

Poza pasywnym wyszukiwaniem podatności, w ZAP wbudowany jest skaner aktywny. Wysyła on żądania mające wskazać możliwe podatności. Używa on odkrytych zasobów – wobec czego, dobrze jest najpierw manualnie, lub Spiderem, znaleźć jak najwięcej stron, a dopiero później włączyć Active Scan. Trwa on dosyć długo, wobec czego dobrą praktyką jest wcześniejsze opracowanie ścisłych kontekstów zasobów, które chcemy sprawdzić, następnie na nich wykonywać skan. Należy mieć na uwadze, że niektóre żądania mogą być inwazyjne, jak i to, że żaden automatyczny skan nie zastąpi człowieka.

Rys 11 Statystyki poszczególnych skanów z Active Scan

Active Scan użyty na przykładzie aplikacji WackoPicko znalazł XSS w wyszukiwarce, ale także możliwość zdalnego wykonania kodu na serwerze.

Rys.  12 Wyniki Active Scan na aplikacji WackoPicko

Dodatkowo pokazał linki do katalogów, które nie są zabezpieczone przed listowaniem zawartości. Może to być cenne źródło informacji o strukturze aplikacji.

Rys. 13 Linki z zawartością katalogów na aplikacji WackoPicko

WebSockets

Obsługa WebSockets jest podobna do obsługi zwykłych żądań HTTP, lecz ma swoją osobną zakładkę z historią. Przesyłane żądania również można oglądać, wstrzymywać (działa wyłącznie po ustawieniu breakpoint), jak i przesyłać ponownie. Zabawę możemy zacząć od przeglądarkowej gry http://browserquest.mozilla.org (polecam użyć Firefoxa – na innych przeglądarkach bywają problemy z logowaniem przez proxy ZAP-a).

Zacznijmy od komunikacji przychodzącej. Podczas poruszania się – gdy nie ma innych graczy w pobliżu – niewiele się dzieje. Zaatakujmy potwora. Coś się dzieje – pojawiają się żądania z treścią wyglądającą, jak dwuelementowa tablica w JavaScripcie [10,60]. Pierwsza wartość się nie zmienia – zapewne jest to typ wykonywanej akcji. Natomiast druga wartość zmniejsza się. Wyślijmy zapytanie jeszcze raz – już poza walką. Przeglądarka dostaje żądanie, lecz nie z serwera, a z ZAPa i… poziom życia maleje. Druga wartość sygnalizuje, ile puntów życia pozostało naszej postaci. Spróbuj wpisać wartość ujemną.

Rys. 14 Historia WebSockets, opcje filtrowania i gra w tle

Sprawdźmy teraz, co gra wysyła do serwera. Przy każdym poruszeniu postacią, wysyłana jest trójelementowa tablica (podobna do [4,128,33]), z informacją o typie akcji (4-poruszenie się) oraz z współrzędnymi X/Y. Zmieniając parametry, wysyłamy serwerowi informację, że się poruszamy. Niestety, przeglądarka „nie wie” o tych żądaniach, postać  nie poruszy się na ekranie, więc niewiele nam to da.
Spróbujmy zaatakować potwora. Tutaj pojawiają się naprzemiennie dwa pakiety: [8,78163] oraz [9,78163]. Tak jak w pozostałych, pierwsza wartość to typ akcji, ale druga tym razem się nie zmienia. Po walce z kilkoma potworami można przypuszczać, że jest to numer identyfikacyjny potwora, a jeden w tych pakietów to jest akcja ataku.
Co się stanie, gdy zaczniemy ją wysyłać w mniejszych odstępach czasu, niż robi to gra? Czy jest komunikat zwrotny o dozwolonej szybkości atakowania, czy też zajmuje się tym aplikacja klienta (gra w przeglądarce)?

Zachęcam wypróbowanie, aby własnoręcznie przekonać się, jak przebiega badanie komunikacji pomiędzy grą a serwerem. Może znajdziesz coś bardziej interesującego?

Pozostałe opcje

Quick Start

Pierwsze, co się rzuca w oczy po włączeniu aplikacji, to zachęta do użycia przycisku w oknie Quick Start. Wystarczy wpisać URL i aplikacja sama użyje Spider -a i włączy Active Scan na znalezionych zasobach.
Jest to przydatna opcja przy wykorzystaniu ZAP-a do automatycznych testów aplikacji, lub jako szybki test możliwości narzędzia.

Rys. 15 Okno opcji Quick Start

Alerts

W zakładce Alerts wskazane są miejsca warte sprawdzenia. Na wybranym zgłoszeniu można prześledzić, jak został przeprowadzony atak, wraz z opisem podatności oraz metodami zabezpieczenia (świetne do nauki na przykładach).

Rys. 16. Znaleziona podatność XSS

Parametry szybkości skanowania

Raz mamy bezpośredni dostęp do aplikacji będąc w tej samej sieci, a innym razem działamy incognito i nie chcemy aby przeprowadzane skany zostały wykryte. Dlatego możemy regulować parametry każdego ataku klikając na koło zębate:

Rys. 17 Regulacja szybkości przeprowadzania ataku

Encode/Decode

Mała rzecz, a nieraz usprawnia pracę. Zamiast kopiować każdy zakodowany ciąg znaków do (np. internetowego) dekodera wystarczy zaznaczyć i wybrać dekodowanie. W poniższym przykładzie podejrzewamy, że ciąg może być  zakodowany – używając base64 – sprawdźmy.

Rys. 18. Wybranie dekodowania ciągu

Naszym oczom ukazuje się okno z dekodowanymi wartościami – w tym przypadku wygląda na to podejrzenia były słuszne.

Rys. 19 Okno dekodera

Słowo na koniec

Niniejszy tekst opisuje wbudowane moduły ZAP-a. Dodatkowe można łatwo zainstalować, z dostępnego w programie marketplace – wszystkie dodatki są bezpłatne. Polecam własnoręcznie wypróbować możliwości ZAPa, tym bardziej że uruchamiany jest na wirtualnej maszynie Javy, więc system operacyjny nie jest ograniczeniem.

ZAP – dzięki możliwości uruchomienia w konsoli i sterowania za pomocą API, może być podpięty pod narzędzie wspierające Continuous Integration (np. Jenkinsa), jako dodatkowe kryterium sprawdzania. Pozwoli to programistom wyłapać możliwe podatności zaraz po ich stworzeniu.

Do prezentacji zostały użyte uruchamiane lokalnie aplikacje które celowo zawierają podatności:
BodgeIt napisana w Javie
WackoPicko napisane w PHP

Jeżeli chcesz się sprawdzić w wyszukiwaniu błędów, to polecam OWASP Broken Web Applications Project, który udostępnia wiele już skonfigurowanych aplikacji w postaci obrazu wirtualnej maszyny.

~ Krzysztof Chodakowski