------------------------------------------------------------------------------------------------------------------
Wstęp
"Dziurawe" strony internetowe to temat rzeka,
zresztą nie od dziś. Rozwijająca się technologia elektronicznego dostępu do
danych oprócz możliwości, stwarza również zagrożenia, o których warto wiedzieć.
Od kilku lat zajmuję się testowaniem bezpieczeństwa również webaplikacji,
dlatego w tym artykule opiszę krok po kroku pewne etapy automatyzacji
testów. Po lekturze, Czytelnik powinien
wiedzieć jak przeprowadzić "test bezpieczeństwa własnej strony WWW".
Jedne z
najpopularniejszych błędów na stronach internetowych to brak filtrowania treści
przekazywanej przez użytkownika.
Zaliczamy do tego wszelkie miejsca na stronie (czy też w kodzie źródłowym
"firmowego CMS'a"), do których użytkownik może przekazać inne dane,
niż "aplikacja zakłada", że dostanie. Np.: w polu login ("same
litery"), nasz 'zły-użytkownik' wpisze "same cyfry". W związku z
tym, że programista "nie przewidział" takiego zachowania użytkownika,
nie "zaprogramował" 'reakcji' na to zdarzenie. W związku z tym jest
to błąd. Jaki? Różnie bywa :)
W związku z tym, w tej części
artykułu zajmiemy się błędami typu "Cross-Site Scripting". Hitem
sezonu błędy te oczywiście nie są, a co lepsze, bardzo często są
bagatelizowane. "Kojarzą się" bowiem, wyłącznie z wyskakującym
okienkiem, albo obrazkiem dodanym na stronę. W związku z rozwojem technologii
możemy długo rozmawiać, co można a czego nie "przez XSS", ale póki
co, warto w tej sprawie dowiedzieć się więcej na popularnej Wikipedii pod
adresem: http://pl.wikipedia.org/wiki/Cross_Site_Scripting. Bezdyskusyjnie jest
to groźny błąd, bo jak mówią: "najmniejsza luka w Twoim systemie, to
największa luka". ;)
Wobec
tego przejdźmy od razu do rzeczy i omówmy „krok po kroku” pewne etapy
automatyzacji testów.
Oprócz lepszego rozumienia zagrożeń internetowych, możemy
teraz do woli testować pracę naszych programistów, lub nasze własne. Zacznijmy
od tych ostatnich... ;)
Środowisko: LAMP, aplikacja którą
testujemy, Burpsuite
Aby zacząć testy, przydałby nam się jeszcze "poligon
doświadczalny"... :)
Doskonale nadaje się do tego komputer z programem do obsługi
"wirtualnych maszyn". Ciekawym rozwiązaniem może być VirtualBox ze
strony https://www.virtualbox.org/wiki/Downloads.
W internecie znajdziecie również obraz płyty (ISO) z dystrybucją Linuxa (może być dowolna, jednak w artykule bazujemy na ostatnim Ubuntu (11.04 w chwili pisania) ze strony www.ubuntu.org).
Po uruchomieniu systemu w VirtualBox'ie (lub lokalnie na laptopie), musimy zainstalować serwer WWW z obsługą MySQL i PHP. Będą nam potrzebne w dalszej części artykułu. Nie będziemy omawiać instalacji i konfiguracji środowiska LAMP, ponieważ jest to do znalezienia "na Google" w 30 sekund ;)
Po zainstalowaniu serwera Apache, PHP'a i bazy MySQL, do naszego WWW-root zgrajmy pliki "strony internetowej" (CMS'a, forum, naszej księgi gości, dowolnie...), którą chcemy przetestować.
Możemy śmiało uruchomić przeglądarkę (w artykule: Firefox) i
przejść na http://localhost/nasz-wwwroot/,
aby sprawdzić, czy "wszystko działa". Jeśli etap ten mamy za sobą i
widzimy "naszą stronę" na naszym lokalnym serwerze WWW, możemy
przejść dalej.
Następnym krokiem jest poznanie terminu "proxy". Proxy, to pewnego rodzaju "pośrednik" (w ruchu internetowym). W przypadku proxy, z którego będziemy korzystać dalej, będzie to "pośrednik" między naszym „kliknięciem na stronie WWW", a samą stroną WWW.
Czyli: gdy uruchomimy "proxy", wejdziemy na
http://localhost/www/ (lokalizacja u Ciebie, może być inna), i na "naszej
stronie" klikniemy w link (lub wypełnimy formularz), program proxy
"złapie" to "zapytanie do strony" (ze wszystkimi
parametrami przekazywanymi drogą
„użytkownik <-> WWW”).
„użytkownik <-> WWW”).
Daje nam to wiele możliwości :)
Przejdźmy teraz na stronę bardzo dobrego narzędzia proxy, mowa
o BurpSuite (http://portswigger.net/). Oprócz samego programu, znajdziemy tu również
jego aktualną dokumentację. (Nie jest to jedyne rozwiązanie tego typu. Bardzo
popularne są również WebScarab i ParosProxy. Na potrzeby artykułu będziemy
korzystać z darmowej wersji Burp'a. Zanim go uruchomisz, sprawdź, czy na Twoim
komputerze zainstalowana jest Java.)
"... po kroku"
Ok. Mamy "środowisko".
Mamy "narzędzia". Mamy stronę, którą możemy przetestować. Zacznijmy
wobec tego działanie od wspomnianego wcześniej ataku XSS (analogiczne „ataki”
przygotowywać można również dla innych błędów, np. SQL Injection).
Cross-Site Scripting
– to przekazanie pewnego kodu do webaplikacji w taki sposób, że wykonuje ona dodatkowe
zadania (np. po osadzeniu na stronie pewnego kodu, haker może wykradać
„cookies” lub przekierowywać użytkowników „do konkurencji” lub na stronę z
phishingiem).
To nie tylko „okienka” ;) Więc…
Ciekawych bezpieczeństwa
webaplikacji zapraszam na następną stronę WWW. http://ha.ckers.org/xss.html to strona, na której RSnake omówił wiele
przykładowych metod na przekazanie „kodu do aplikacji” WWW. Skorzystajmy z jego
„podpowiedzi” do budowy naszego pierwszego pliku: payload.txt.
Otwórzmy ulubiony edytor i po przeczytaniu wspomnianej wyżej strony,
przepiszmy „ciągi znaków do ataku”, które najbardziej nas interesują.
(Podpowiem Wam, że do testów, z ciekawości „wybrałem wszystkie”;)) Lista wobec
tego może wyglądać np. tak:
Na potrzeby być może bardziej
początkujących Czytelników mała wskazówka: jeśli w ten sposób chcecie testować
swoje webaplikacje w poszukiwaniu błędów cross-site scripting, „na początek”
wartości w nawiasach typu ‘XSS’, czy „XSS”, zamieńcie na wartości numeryczne,
np.: alert(12345678).
Część filtrów wprowadzana
przez programistów może „nie przepuścić” Waszych „ataków” z „średnik-XSS”,
natomiast cyfry (zazwyczaj ;)) przechodzą. Piszę to, ponieważ „sam kiedyś
zaczynałem” i okazało się pewnego razu, że spędziłem kilka godzin z Burp’em i
skryptami nad tym, żeby w końcu „wpaść na pomysł”, że może w ataku można
wrzucić „tylko cyfry”… J (Jako pracę domową możecie przygotować
„payload” z /dev/urandom i wtedy zacznijcie skanować Burp’em;) )
Weryfikację ataków można robić oczywiście jeszcze inaczej,
ale o tym ewentualnie później.
Wobec powyższego dla naszych potrzeb lekko zmieniona treść
pliku payload.txt powinna wyglądać mniej więcej tak:
Jak możemy przeczytać na Wikipedii, czy na stronach OWASP (www.owasp.org), cross-site scripting to jedna z wielu
popularnych metod ataku na strony internetowe (a raczej na odbiorców tych
stron. „Zły haker” który podmienia naszą stronę na taką zawierającą kod XSS np.
w komentarzach wątpliwie użyje któregoś z przykładów z listy RSnake. Częściej
będzie się starał, aby „jego ofiary” (zwykli użytkownicy danej strony) niczego
nie podejrzewali i nic nie zauważyli.)
Wróćmy do naszej listy kroków potrzebnej do rozpoczęcia
testów. Kolejne linie w pliku „payload.txt” odzwierciedlają wartości
parametrów, które Burp przekaże do webaplikacji podczas „sprawdzania”. Oprócz
pliku z atakami potrzebujemy pliku z „odpowiedziami”. Odpowiedzi możemy do
pewnego stopnia „przewidzieć”. Da nam to punkt zaczepienia do „głębszych
poszukiwań” (lub pisania exploita).
Atak będzie wyglądać tak, że do wybranej przez nas strony
(„złapanej” przez Burp’a), przekazywać będziemy (jako wartości parametrów)
kolejne linie z payload.txt. Będziemy odwiedzać stronę niejako „przez Burp’a”,
więc treść pytania (request HTTP do strony WWW) jak i treść odpowiedzi
(response) będzie widoczna w programie. Z lektury ha.ckers.org, owasp.org i
google.com możemy wywnioskować „odpowiedzi”. Skoro w ataku używamy schematu
(kawałka kodu), który ma się pojawić w odpowiedzi, wpiszmy ten „kawałek kodu”
do pliku response.txt. (Na potrzeby projektów, tzw. „testów penetracyjnych
stron WWW”, najczęściej payload dla XSS zawiera funkcję alert(), czyli właśnie
„to okienko z XSS”, stąd utarło się, że XSS jest nie groźny ;)).
Dokumentacja Burp’a opisuje możliwość dodania pliku „z
odpowiedziami”, tak jak była możliwość dodania „pliku z atakami”.
Szukamy odpowiedzi
Plik „response.txt” stwórzmy w tym samym katalogu co
„payload.txt”. Skoro podczas ataku XSS przekazujemy przez przeglądarkę do webaplikacji
pewne wartości, spodziewamy się pewnych odpowiedzi. Te właśnie „odpowiedzi”
wpisujemy do pliku „response.txt”.
Powiedzmy, że czytaliśmy w internecie artykuł o atakach SQL
Injection i wiemy z niego, że „gdy może być błąd” tego typu, źle napisane
aplikacje zazwyczaj odpowiadają „treścią” zawierającą komunikaty takie jak:
„Warning”, „SQL”, „error”, czy „invalid”. Takie właśnie „odpowiedzi”, których
Burp będzie zaraz szukał, wpiszmy do naszego nowego pliku. Oprócz tego, skoro
„ustawiliśmy to wcześniej” w kolejnej linii response.txt dopiszmy naszą
„standardową wartość numeryczną”, którą ustaliliśmy wcześniej (będzie to 123123).
(Swoją drogą w Burp’ie na karcie „Options” jest (kolejna) karta „options”. W
niej autorzy programu wpisali już kilka możliwych „odpowiedzi webaplikacji”:
Plik z odpowiedziami na początek może wyglądać tak:
Możemy teraz zrobić następny krok w kierunku wykrywania podatności
w naszych stronach internetowych.
Do pierwszego testu, aby sprawdzić, czy nasze ustawienia
pozwalają na faktyczne „wykrywanie luk” skorzystajmy z programu MFM dostępnego
na stronie www.sourceforge.net. Jest to manager plików, który autor
opisuje tak: „file manager for UNIX systems ( writed on FreeBSD
)like MS Explorer with directory treebased …”. Do
naszych testów będzie idealny :)
Pobierzmy program i rozpakujmy w katalogu naszego serwera
WWW, tak aby po przejściu na stronę http://localhost/mfm/ zobaczyć pliki tego managera.
Jest tu przycisk tworzenia folderu. Na razie nic nie klikajmy tylko włączmy w
Burpie przechwytywanie danych. Możemy to zrobić przechodząc w karcie „Proxy”
programu do karty „intercept”, a tam klikamy „intercept on” jeśli jest
wyłączone.
Firefox (w zależności od wersji) w menu Edycja ->
Preferencje, lub Narzędzia -> Opcje posiada wybór kilku kart. Przejdźmy do
karty „Sieć” i wybierzmy przycisk „Ustawienia”. Tam interesuje nas „ręczna
konfiguracja serwerów proxy”. W pole „Serwer proxy HTTP” wpiszmy localhost lub
adres 127.0.0.1, a w polu port, wpiszmy numer portu, którego używamy w Burp’ie
(standardowo 8080). Ok.
Dopiero teraz w przeglądarce (i naszym managerze) spróbujmy
utworzyć nowy katalog. Po podaniu nazwy w okienku webaplikacji i naciśnięciu
„ok”, Burp od razu alarmuje nas o podjętej akcji (a raczej wstrzymaniu jej do
naszej decyzji).
A że nasze decyzje możemy podejmować dziś jednym palcem,
kliknijmy w oknie „przechwycenia” w Burpie prawy przycisk myszy, aby wybrać
możliwość „send to intruder”. Po wyborze tej akcji, karta „Intrudera” w głownym
oknie (Burp’a) zaświeci się na chwilę na czerwono.
Przejdźmy tam teraz.
Burp
przechwycił zapytanie do WWW.
Wysyłamy je do
„Intrudera”.
Teraz możemy dodać nasz „atak” i oczekiwaną na niego
„odpowiedź” do programu, aby zautomatyzować przeszukiwanie kodu tej
webaplikacji (może nie do końca sprawdzamy kod „jako tako”, ponieważ testując
przy pomocy Burp’a w ten sposób, testujemy właściwie „zachowanie webaplikacji
na przekazanie jej konkretnych wartości dla konkretnych parametrów” od strony
użytkownika, a nie „czytelnika kodu”. Tak więc błędy, które znajdziemy, równie
dobrze może znaleźć każdy inny użytkownik naszej strony, czy „rozwiązania WWW”).
Dodajmy więc w karcie „Payload” nasz „payload.txt” z
przykładowymi atakami (na razie tylko XSS), oraz w karcie „Options” obok,
najpierw wyczyśćmy aktualną listę zaproponowaną przez twórców Burp’a (przycisk
„Clear”) a później („Add”) dodajmy „response.txt” aby wprowadzić „nasze
odpowiedzi”.
Kroki te przedstawione są na rysunkach poniżej:
1. Dodajemy payload:
2. Dodajemy
„odpowiedzi”, które pozwolą nam szybko wskazać podatność:
Jak można zauważyć na obrazku (payload), przy
„przekierowaniach” zaznaczyłem „zawsze” („always”). Czytelnikom polecam
sprawdzenie wyników bez ustawiania przekierowań („never”) oraz „z nimi” jako
pracę domową. Porównajcie wyniki.
Gdy ustawimy już pytania i odpowiedzi w naszym proxy, możemy
rozpocząć „atak”. Wybierzmy z menu na samej górze „Intruder -> start
attack”.
W nowym oknie Burp pokaże nam wyniki (w tym nasze
szukane-znalezione „odpowiedzi”):
3. Kolorem czerwonym na tym obrazku zaznaczyłem miejsce, w których
Burp uznał coś za „podatne” (przynajmniej tak możemy rozumieć wyniki podczas
prezentowanej tu automatyzacji testów).
Aby zweryfikować czy faktycznie w tym programie
występuje luka XSS, kliknijmy na „atak”, w którym Burp wskazał wszystkie (lub
wiele) odpowiedzi, prawym klawiszem myszy i wybierzmy akcję „show response in
browser”. Następnie w oknie przeglądarki w polu adresu wpiszmy („Ctrl+V”) adres
skopiowany z Burp’a.
( Wyślij
atak do przeglądarki.)
Po naciśnięciu „Enter”, nie trzeba długo czekać na wynik:
Bingo! Udało nam się zautomatyzować proces „prostego
szukania luk”. Myślę, że w związku z tym prostym przykładem, możemy „przesiąść
się na testy czegoś mocniejszego”.
W następnej części artykułu omówimy poszukiwania SQL
injection.
Skoro wiemy już jak przygotować się do przykładowego ataku,
kolejnym krokiem jest poznanie „magii SQL injection”. (Czytelników, którzy nie
do końca rozumieją na czym polegają te ataki, zapraszam „na Wikipedię” .) Aby
spróbować znaleźć błędy tej klasy, zmieńmy trochę nasz plik payload.txt oraz
response.txt. Przykładowe, bardzo pomocne „ciągi znaków” (poprawne lub nie,
zapytania do bazy danych w języku SQL) możecie znaleźć w internecie. Jedną z
moich ulubionych „list”, z których kiedyś korzystałem do wykrywania podatności
tego typu, zbudowałem w oparciu o http://pentestmonkey.net/cheat-sheet/sql-injection/mysq-sql-injection-cheat-sheet
. Wspomniany RSnake, również ma dla Was coś do poczytania w tym zakresie na http://ha.ckers.org/sqlinjection.
Przykładowy plik do ataków może zawierać takie wiersze jak:
Najpopularniejsze odpowiedzi w przypadku tych ataków
znajdziecie w treści na wspomnianych stronach oraz we wcześniejszej części
artykułu. Niektóre z nich, autorzy Burp’a zaproponowali domyślnie (i te
ponownie „na początek” będą dobre do naszych testów).
Jakie mogą być rezultaty szukania błędów SQL injection za
pomocą automatycznej pracy Burp’a możecie sprawdzić na blogu http://hauntit.blogspot.com. Ostatnio
dodałem tam informacje na temat SQL injection w najnowszym Bloofox CMS.
Wykonując analogiczne kroki dla BloofoxCMS jak dla
webaplikacji użytej do testów w artykule, Czytelnik znajdzie błąd SQL Injection
bez problemu „sam” :)
Testy opisane tutaj, to oczywiście „kropla w morzu” jeśli
chodzi o szukanie błędów.
Jak się bronić przed tego typu atakami
To kolejna zagwozdka, tym razem z drugiej strony barykady. W
odniesieniu do wspominanej już Wikipedii, która podobnie do artykułów
technicznych w internecie, zaleca maksymalnie przemyślane filtrowanie treści
przekazywanej przez użytkownika, oprócz tego dodatkowo zalecałbym cykliczne
testy bezpieczeństwa. Jak wiadomo, „co dwie głowy to nie jedna”, a w
bezpieczeństwie firmowych sekretów, konstruktywna współpraca może przynosić
relacje na lata.
Podsumowanie
Temat testów bezpieczeństwa WWW oraz ich automatyzację
poruszę jeszcze nie raz w artykułach lub na blogu. Następną publikację planuję
poświęcić na omówienie wykrywania innych błędów za pomocą Burp’a. Ostatnio
znalazłem kilka nowych zastosowań dla Burp’a więc w następnej części omówię
znajdowanie podatności typu „user enumeration” lub „remote code execution”.
Powodzenia w kreatywności w poszukiwaniu błędów!
_____________________________________
Użyte linki:
Burp - www.portswigger.net
Wikipedia – pl.wikipedia.org
RSnake - http://ha.ckers.org
Ubuntu - www.ubuntu.com
OWASP –
www.owasp.org
Google – www.google.pl
_____________________________________
No comments:
Post a Comment
What do You think...?