Zgodnie z corocznym raportem White Hat Security nt. bezpieczeństwa aplikacji webowych w dalszym ciągu wśród krytycznych podatności można odnaleźć XSS na trzecim miejscu z prawdopodobieństwem 47% istnienia podatności. Ustępuje miejsca jedynie ogólnemu „wyciekowi informacji” (56%) oraz braku miejsca bezpieczeństwa warstwy transportowej (70%). Wynika to z faktu, że przyrost drobnych i średnich stron internetowych jest bardzo duży, natomiast nieproporcjonalny do wzrostu liczby świadomych programistów nauczonych budować serwisy bezpieczne.


Szkolenie pracownika nie jest tanie, a zazwyczaj istotny jest sam wkład własny projektanta. Pomijając wiele aspektów pracowniczych i psychologicznych tej dysproporcji nie zmienia to faktu, że istnieje ciągła potrzeba przeprowadzania testów penetracyjnych zewnętrznych lub we własnym zakresie. Oczywistym jest, że oficjalne łatanie podatności trwa długo i może być kosztowne, wobec czego im szybciej luka zostanie wykryta – tym korelacja pomiędzy próbą naruszenia dostępu do systemu, a świadomością włamania może być bardziej zadowalająca. W sposób samodzielny jednym z komponentów do zbadania podatności na własnym systemie może być poniżej opisane narzędzie, jedno z wielu skanerów dostępnych w sieci. Niewiele jednak jest tak dobrze udokumentowanych, ciągle rozwijanych i przede wszystkim darmowych, takich jak Vega.

 

Vega jest otwartą platformą do skanowania i testów bezpieczeństwa aplikacji webowych stworzoną przez firmę Subgraph. Narzędzie wspomaga odnalezienie i walidowanie takich podatności jak: SQL Injection, XSS (Cross-Site Scripting), przypadkowo ujawnione informacje i inne podatności o zróżnicowanym znaczeniu. Vega jest napisane w Javie, więc narzędzie jest multi-platformowe (Linux, OS X, Windows) wraz z przyjaznym GUI. Platforma była także dostępna jako wbudowany komponent w dystrybucji Kali (dedykowany system linuksowy do wykonywania testów penetracyjnych) i można było je znaleźć w gałęzi: Applications > Kali Linux > Web Applications > Web Vulnerability Scanners > VEGA. Zawiera automatyczne skanery do szybkich testów oraz przechwytujące proxy do wykonywania inspekcji krokowych. Niewątpliwą zaletą jest także rozbudowywalne API.

 

Instalacja

W przypadku świeżej instalacji dystrybucji Kali wystarczy wydać polecenie:

apt-get install vega

W przypadku dystrybucji innych, ale opartych od Debiana, jako prekwizyt należy zainstalować bibliotekę webkitgtk, ze względu na fakt, że Xulrunner nie jest kompatybilny z platformą Eclipse (na której zbudowane jest narzędzie):

apt-get install libwebkitgtk-1.0

Na systemach opartych o Red Hat/Fedorę:

yum install webkitgtk Hint:

W przypadku instalacji dystrybucji Kali na maszynie wirtualnej pod systemem Windows np. Oracle VirtualBox 5.0.14 mogą wystąpić problemy, które można szybko rozwiązać:

Jeśli Kali nie ma dostępu do Internetu W ustawieniach maszyny wirtualnej w zakładce Settings > Network należy ustawić połączenie sieciowe na NAT’owane.

Vega może również zostać zainstalowane bezpośrednio w systemie Windows. Będzie potrzebne wtedy środowisko Java 7 JRE i poprawa pliku Vega.ini parametrem -Xmx1536m w przypadku gdyby maszyna nie chciała wystartować.

 

Po instalacji

Narzędzie uruchamia się jako:

root@dArkSTAr:~# vega

Narzędzie po uruchomieniu może pracować w dwóch trybach: skaner lub proxy. Tryb skanera to wcześniej wspomniane narzędzie do testowania zabezpieczeń. Główną rolą trybu jest indeksowanie stron na podstawie podanego ciągu URL, analiza zawartości strony w celu odnalezienia odniesień lub parametrów formularzy. Odnajdywanie punktów wtrysku czyli węzłów stanów ścieżki i następnie ich analiza modułowa z JavaScript. Węzłami mogą być foldery, pliki lub pliki z instrukcjami POST/GET.

Z racji, że skaner przeszukuje URL rekursywnie, liczba węzłów i głębokość szukania może znacznie wydłużyć czas skanowania dlatego w zależności od badanego środowiska należy dopasować parametry indywidualne z menu Window > Preferences > Scanner.

 

Niektore parametry skanera

• Total number of path descendants [8192] – maksymalna liczba podwęzłów czyli folderów lub parametrów każdego węzła.

• Total number of child paths for a single node [512] – maksymalna liczba podwęzłów dla jednego węzła (foldery, pliki, parametry)

• Maximum path depth [16]– maksymalna hierarchiczna głębokość przeszukiwania (np. poziom1/poziom2/poziom3/…)

• Maximum number of duplicate path elements [3] – maksymalna liczba dozwolonych powtórzeń fragmentów ścieżek przyległych (np. /images/images/)

• Maximum length of strings to display in alert reports [400] – maksymalna liczba wyświetlanych łańcuchów znaków w raporcie (np. kod źródłowy strony)

• Maximum number of requests to send per second [25] – maksymalna liczba odpytań strony na sekundę. Parametr ważny, z tego względu, że mechanizmy ochrony typu WAF mogą wychwytywać próby rekonesansu, więc parametr należy odpowiednio zwiększyć wydłużając czas skanowania.

• Maximum response size to proces in kilobytes [1024] – maksymalna wielkość odpowiedzi w kilobajtach.

 

W celu przeprowadzenia skanowania hosta należy kliknąć „Start New Scan” lub CTRL+N i wpisać poszukiwany adres URL.

 

W następnym oknie należy wybrać moduły wstrzykujące które będą próbowały odnaleźć podatność pod wskazanym URL celu oraz jego podwęzłach. Moduły dzielą się na: Injection modules oraz Response Processing Modules. Moduły są napisane w JavaScript i operują na JS Rhino interpreterze.

Moduły Injection są uruchamiane na poszczególnym węźle i wykonują aktywny fuzzing uwzględniając URI będące plikami lub folderami lub URI będące parametrami samodzielnie tworzącymi odrębne węzły.

 

Moduły typu Response Processing są uruchamiane na wszystkich odpowiedziach wygenerowanych przez serwer. Dokumentacja określa je jako moduły „grep”. W trakcie skanowania zacznie wypełniać się drzewo podatności w oknie „Scan Alerts” pokategoryzowane po skali zagrożenia. Każda z podatności może zostać indywidualnie zinterpretowana. Nie jest to oczywiście odnalezienie typowej luki (tak jakby zrobił to MetaSploit), a w większości przypadków punkt zaczepienia od którego można pociągnąć dalsze wnioski.

 

Przewagą Vegi jest fakt, że każda podatność jest opisana i tak naprawdę narzędzie może służyć jako ciekawa metoda nauki pozyskiwania podatności wraz z odsyłaczami do konkretnych stron gdzie można dowiedzieć się więcej. Po kliknięciu w zakładce REQUEST pozycji z GET /uri/ uzyskuje się okno ze źródłem REQUEST oraz RESPONSE mogące służyć do głębszej analizy.

 

Proxy

 

Vega potrafi działać w trybie przechwytującego proxy tak jak znane, płatne narzędzie Burpsuite (również oparte o Javę). Proxy jest umieszczone pomiędzy przeglądarką lokalną a serwerem hostującym aplikację poddaną testowi. Potrafi przechwycić wszystkie żądania i odpowiedzi przeglądarki oraz zmodyfikować je zgodnie z potrzebą zanim zostaną przesłane dalej (do serwera). Możliwa jest również przechwytywanie po protokole HTTPS jednak domyślnie przeglądarka zwróci monit o certyfikat uznając go za nieznany (wystarczy zaimportować do magazynu przeglądarki certyfikat samodzielnie podpisany).

Tryb proxy wymaga ustawienia w przeglądarce jej działania przez proxy. Z reguły te ustawienia można znaleźć w zaawansowanych ustawieniach przeglądarki. Np. w Mozilla IceWeasel 43.0.4 będzie to Preferences > Advanced > Network > Settings. Najprościej można przeglądarkę ustawić domyślnie.

W celu uruchomienia trybu proxy wystarczy kliknąć ikonę „Start HTTP Proxy”, równocześnie można uruchomić moduł „Proxy Scanning”, czyli przechodzenie po zawartości strony również sprawdza je pod kątem podatności.

Jednak ważniejszym aspektem trybu proxy jest możliwość edytowania żądań/odpowiedzi oraz przechwytywania konkretnych typów transakcji (wszystkich zgodnie ze zdefiniowaną maską lub zgodnie z punktami przerwania).

Żądanie można edytować w sposób dowolny i obserwować wyniki w przeglądarce. Dodatkowo w zakładce Intercept można zdefiniować dokładnie w którym momencie ruch ma zostać przechwycony poprzez wskazanie breakpoints. Eliminuje to zbędne strony statyczne lub niepodatne z długiej listy przechwyconych pozycji w widoku Website view. Breakpoint można zdefiniować na podstawie kryterium nazwy hosta, metody, nagłówka, ścieżki żądania oraz kodu, nagłówka i długości odpowiedzi z pomocą operatorów logicznych.

W przypadku na natrafienie na breakpoint, przeglądarka zatrzyma się, a w oknie Intercept pojawi się kod żądania który możemy zmodyfikować, a następnie przepuścić do serwera lub anulować.

 

Inteligentne skanowanie

 

Same tryby skanowania dla użytkownika nie mającego wiele wspólnego ze znajomością podatności aplikacji webowych niewiele się zdadzą. Ważne jest zrozumienie i właściwa interpretacja wyników. Ważną zaletą trybu skanowania Proxy poza zbieraniem parametrów i informacji ścieżki w komunikacji klient-serwer jest umiejętność przechwytywania tego, czego nie potrafi crawler (RPC Endpoints oraz linki w kontenerach aktywnych jak Flash czy Java). Jednak przed przystąpieniem do interpretacji czegokolwiek należy zwrócić uwagę na pewne aspekty serwisów nie pozwalające w jednoznaczny sposób zeskanować i wykryć podatność. Chodzi o co raz chętniej i powszechnie stosowany szyfrowany protokół HTTPS. Kiedy przeglądarka wyśle żądanie HTTPS do serwera w przypadku prób skanowań Man-In-The-Middle zakończyło by się niemożnością podglądu i ich edycji przez właśnie szyfrowanie. W tym celu Subgraph zaimplementowało gotowy certyfikat, który można zaimportować do kontenera przeglądarki. Wystarczy wejść na stronę http://vega/ca.crt i pobrać lub zaimportować wprost certyfikat do dowolnej przeglądarki.

 

Metody importu mogą się nieco różnić. W przypadku IceaWeasel, po wejściu na stronę wystarczy zaufać wskazanemu CA. Po przeładowaniu strony https – zaczyna ona wyświetlać się prawidłowo.

 

W celu odnalezienia ważniejszych informacji w Proxy Scanning należy kliknąć ikonę na dole po lewej określoną jako „Scan Alerts” gdzie pojawi się znajomy inspektor ruchu z trybu skanowania. Bez uzasadnienia jest uruchamianie skanowania w obrębie całej domeny, a raczej w zakresie węzłów które komunikują się z serwerem. W tym celu warto ograniczyć skanowanie w polu „Edit Target Scope” [CTRL+E] lub prawym klawiszem na wybranym łączu w WebSite View i „Add to current Target Scope”. Jest to sposób pozwalający zaoszczędzić czas skanowania serwisu. Warto również wspomnieć, że podczas włączonego skanowania proxy, przechwytywane również mogą być cookies używane przez klienta, zachowując zautentykowane sesje podczas skanowania. By zachować tę ciągłość wystarczy zalogować się do web-aplikacji przez proxy, upewniając się, że „Target Scope” zawiera konkretny węzeł z logowaniem i poruszać się po stronie z włączonym „Proxy Scanning”. W związku z tym także Vega oferuje mechanizm „Identyfikacji” – automatycznie uzupełniając formularze do logowania na podstawie jednego z czterech trybów: http basic, http digest, ntlm oraz macro. Podczas Proxy Scanning należy przejść do zakładki Scanner i kliknąć w oknie „Identities” opcję po prawej „Create new Identity”, wprowadzić identyfikator oraz w/w typ autentykacji (rozsądnie jest wybrać „macro”).

 

Po kliknięci „Next” w kolejnym oknie należy zdefiniować elementy podlegające pod makro, czyli wskazać URL z metodą POST (musi być to metoda „jawnie” przekazująca parametr login i hasło, jak np. profil.wp.pl). W parametrze login.username oraz login.password należy podać znane parametry autentykacji.

 

Mając skonfigurowane wszystkie potrzebne elementy, można przystąpić do skanowania komplementarnego uderzając w konkretne węzły wykorzystujące autentykację w sposób zautomatyzowany. Należy w trybie Skanera kliknąć nowe skanowanie, a następnie uzupełnić pola o Target Scope. Następnie poprzez wybór metod skanowania i autentykacji automatycznej (wskazanie nazwy makra oraz ustawienia cookie). Należy pamiętać by wykluczyć metodę POST związaną z wylogowaniem.

 

Przykład użycia

 

Do realnego wykorzystania potencjału narzędzia posłuży znana domena http://testphp.vulnweb.com, którą należy umieścić w Target Scope i uruchomić skanowanie.

Skaner zwrócił informację, że węzeł /search.php jest podatny z metodą POST na Cross-Site Scripting. W łatwy sposób można ten fakt sprawdzić czy wykona się kod umieszczony w formularzu do wyszukiwania, poprzez wpisanie ciągu.

 

Wstrzyknięcie nieinwazyjnego kodu zadziałało, więc podatność została potwierdzona. Jeżeli dany serwer nie ma zaimplementowanego modułu mod_rewrite to teoretycznie wystarczy w wyszukiwarce goOgle przeszukać ciąg znaków inurl:/search_results.php?search= i zacząć skanowanie w tych domenach. Domena vulnweb.com służy do testów, więc zawiera również kilka innych popularnych podatności jak m.in. SQL Injection.

 

Typowe odpytanie metody GET dla SQLi to

url.php?cat=1%20AND%201=2%20--%20,

jednak interesujący jest węzeł

product.php?pic=5

czyli Blind Test Injection Differential dla Input Validation Error. Wystarczy w Request Editor w trybie Proxy Scanner zmienić GET url na

/product.php?pic=5’

i na stronie pojawia się komunikat związany z mysql_fetch_array();

W celu dalszej analizy można wykorzystać narzędzie SQLmap i wykonać polecenie:

root@dArkSTAr:~# sqlmap –dbs –url http://testphp.vulnweb.com/product.php?pic=5

 

Podsumowanie

 

Skaner VEGA jak najbardziej nadaje się, by przeksanować w przyzwoity sposób witrynę internetową, bez angażowania drogiej firmy specjalizującej się w testach penetracyjnych.


2016-10-30 21:08:16 Presented by Martin S