Łukasz Pilorz

Przez ostatnie tygodnie w wolnych chwilach starałem się uporządkować swoje notatki o testach serwisów internetowych - jako efekt uboczny powstał ten wpis.

Tekst dotyczy przede wszystkim typowych aplikacji tworzonych w PHP: CMS-ów, serwisów społecznościowych i informacyjnych, BIP-ów, sklepów internetowych. Takie serwisy nie wymagają zabezpieczeń na poziomie bankowości elektronicznej. Najczęściej wystarczające są testy przeprowadzone przez programistów lub inżynierów QA, i mam nadzieję, że właśnie im przyda się poniższa lista. Zainteresowanych ogólniejszą i pełniejszą wiedzą odsyłam na strony OWASP

Identyfikacja dostępnych zasobów

Jako pierwszy etap proponuję przeprowadzenie rozpoznania, jakie informacje o aplikacji jest w stanie zebrać osoba z zewnątrz. Do tego celu najprościej jest wykorzystać typowe narzędzia, ale odrobina “twórczości własnej” też może się przydać. Przykładowy zestaw:

• Fierce
• Nmap
• Nessus
• Wfuzz
• Google

Fierce - to narzędzie jest przeznaczone do przeszukiwania zasobów sieci korporacyjnych, ale sprawdza się też przy małych serwisach. Metodą brute-force znajduje subdomeny, a następnie przeszukuje okoliczne IP w poszukiwaniu zasobów powiązanych z tą samą firmą:
perl fierce.pl -dns example.com -search nazwa,firmy,i,inne,slowa,kluczowe
Przykładowy wynik można obejrzeć tutaj. Podobna funkcja jest wbudowana w skaner Acunetix WVS (również w darmowej wersji).

Znajomość programu Nmap jest obowiązkowa dla administratorów, ale przy rekonesansie przydaje się również w testach aplikacji WWW. Do określenia celu można wykorzystać wyniki z Fierce, a skan wystarczy ograniczyć do portów typowych dla protokołu HTTP:
nmap -v -P0 -sV -p T:80,443,8080 example.com

Zadaniem Nessusa jest zweryfikowanie podatności systemu na podstawie bogatej listy sygnatur. Ten skaner nie wykryje błędów w napisanych przez nas aplikacjach, ale zastosowanie się do jego wskazówek pomoże między innymi w obronie przed robakami internetowymi oraz script kiddies. Dodatkowa funkcja, o której dokumentacja milczy, to wykrywanie nieodpowiednio zorganizowanych powiadomień o atakach na serwis - sygnaturą jest (dobiegający zwykle z pokoju obok) charakterystyczny krzyk osoby, której skrzynka pocztowa została zalana setkami alertów.
Przed użyciem Nessusa w środowisku produkcyjnym należy koniecznie analogiczny skan przeprowadzić przeciwko serwerowi testowemu, na którym uruchomione są te same aplikacje (możliwie wierna kopia) - w przeciwnym razie konsekwencje mogą być trudne do przewidzenia.

W kolejnym kroku proponuję powrócić do wyników uzyskanych przy pomocy Fierce oraz Nmapa, i tym razem wyszukać dostępne w znalezionych domenach katalogi/pliki. Do tego celu świetnie nadaje się Wfuzz - narzędzie do przeprowadzania ataków brute-force na aplikacje internetowe. Jego możliwości są znacznie większe niż wyszukiwanie, ale na tym etapie wystarczy ograniczyć się do poniższych poleceń:
./wfuzz.py -c -z file -f slownik.txt --hc 404 http://example.com/FUZZ/
./wfuzz.py -c -z file -f slownik.txt --hc 404 http://example.com/FUZZ.php
Do określenia rozszerzeń plików, których będziemy szukać, może się przydać metoda, którą opisałem tutaj.

Na koniec pozostaje metoda, w której można się wykazać własną inicjatywą, czyli Google Hacking. Poza wykorzystaniem Google Hacking Database, można podsumować informacje ze skanerów, i na tej podstawie próbować nowych sztuczek. Poniżej zamieszczam kilka googledorków, które kiedyś okazały się dla mnie przydatne:

• site:example.com intitle:”Index of /” modified
• site:example.com intitle:phpinfo
• site:example.com filetype:php inurl:upload
• site:example.com filetype:php inurl:file
• site:example.com inurl:config
• site:example.com filetype:inc config
• site:example.com inurl:admin

Ciąg dalszy wkrótce (część 2: Analiza funkcjonalności aplikacji). Komentarze i propozycje poprawek mile widziane - tutaj lub mailowo.