Testowanie bezpieczeństwa aplikacji internetowych – część 1: Identyfikacja dostępnych zasobów
[15-09-2007]
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 – 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.
Komentarze
Leave a Comment
Hmm, początek dość obiecujący – mam nadzieję, że wpis będzie się rozwijał. Sam chciałem coś takiego napisać, ale nie starczyło czasu.
Zabierałem się do tego od dawna, więc materiały mam na kilkanaście takich krótkich odcinków – a na ile wystarczy czasu, to zobaczymy. Ciekaw jestem, w jakim stopniu moje metody pokrywają się z tym, co robią pentesterzy w Polsce (mam na myśli tylko wycinek webappsec, nie pełne testy). Mam nadzieję na komentarze, kiedy już wrzucę kilka części :)
Na razie ciężko stwierdzić, na ile się pokrywają, bo rekonesans to wszędzie wygląda podobnie. Moim zdaniem warto by jeszcze opisać w jaki sposób testować, jaki serwer nasłuchuje na danym porcie – Tomcat, Apache czy coś innego. Na tym etapie mamy też zwyczaj testować konfigurację SSL oraz czy dostępny jest listener bazy danych.
Jeśli chodzi o rekonesans samej aplikacji, to po prostu odpalamy BurpProxy (czy też WebScarabb) w trybie logowania i przeprowadzamy normalne operacje w aplikacji. Potem starczy przejrzeć logi i wyniki działa nia spidera.