07 paź 07 Rails 2.0: wbudowana ochrona przed CSRF
Niedawno narzekałem na RoR, a tymczasem w Rails 2.0 formularze są domyślnie chronione przed CSRF, zmienił się filtr zapobiegający XSS oraz dodano obsługę ciasteczek HTTPonly. Zwłaszcza pierwsza z tych zmian może znacznie zwiększyć bezpieczeństwo aplikacji. Polecam też Ruby on Rails Security Cheatsheet.
Jeśli ktoś czeka na trzecią część tekstu o testowaniu bezpieczeństwa aplikacji internetowych, to uspokajam: jest gotowa i czeka tylko na odpowiedź jednego ze wspomnianych w niej serwisów.
29 wrz 07 Czarny tydzień Google
W tym tygodniu padło na Google. W ciągu kilku dni opublikowane zostały informacje o pięciu lukach w aplikacjach tej firmy. Z ciekawości wyszukałem informacje o podobnych zgłoszeniach w tym roku:
09/2007
http://sirdarckcat.blogspot.com/2007/09/google-mashups-vulnerability.html
http://xs-sniper.com/blog/2007/09/28/all-your-google-docs-are-belong-to-us/
http://www.thespanner.co.uk/2007/09/27/google-adsense-csrf-hole/
http://hackademix.net/2007/09/24/googhole-xss-pwning-gmail-picasa-and-almost-200k-customers/
http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/
http://blog.beford.org/?p=3
http://websecurity.com.ua/1368/
http://sla.ckers.org/forum/read.php?3,15534,15534
08/2007
http://ha.ckers.org/blog/20070817/xss-hole-in-google-apps-is-expected-behavior/
http://sla.ckers.org/forum/read.php?4,15136,15136
06/2007
http://websecurity.com.ua/1049/
05/2007
http://www.0×000000.com/index.php?i=319
http://www.earlofgrey.com/blog/major-google-security-flaw-to-remove-sites-from-the-index.html
04/2007
http://sla.ckers.org/forum/read.php?2,10960
03/2007
http://mybeni.rootzilla.de/mybeNi/2007/gmail_information_disclosure/
02/2007
http://www.watchfire.com/news/releases/02-21-07.aspx
http://ha.ckers.org/blog/20070222/google-desktop-the-saga-continues/
http://sla.ckers.org/forum/read.php?2,6505,6562
http://sla.ckers.org/forum/read.php?3,44,page=40#msg-7125
http://sla.ckers.org/forum/read.php?3,44,page=40#msg-7126
01/2007
http://googlified.com/2007follow-up-on-the-gmail-bug/
http://blogoscoped.com/archive/2007-01-14-n21.html
Czy jest to powód do unikania produktów Google? Jeżeli nawet tak, to nie ze względu na powyższe błędy (które były łatane w błyskawicznym tempie), ale raczej dlatego, że stają się one aplikacjami powszechnego użytku – a popularność często oznacza większe ryzyko ataku.
24 wrz 07 Testowanie bezpieczeństwa aplikacji internetowych – część 2: Analiza funkcjonalności aplikacji
Tematem tej części można byłoby pewnie wypełnić książkę, tutaj ograniczę się do bardzo skrótowego ujęcia. Analiza funkcjonalności polegać będzie na skatalogowaniu akcji dostępnych w serwisie, a następnie określeniu zagrożeń, które z nich wynikają. Na tym etapie proponuję też wskazać fragmenty aplikacji, dla których należy sprawdzić istnienie typowych błędów.
Zarówno ten etap, jak i kolejne, najwygodniej będzie wykonywać przy pomocy przeglądarki internetowej (np. Firefox z rozszerzeniami: Firebug, Live HTTP Headers, Modify Headers i Edit Cookies) w połączeniu z Burp Suite lub podobnym narzędziem. Szczególnie polecam Burp Proxy, który pozwala modyfikować „w locie” dane przesyłane pomiędzy przeglądarką i serwerem. Po uruchomieniu Burp Suite należy ustawić w przeglądarce proxy localhost:8080, proponuję też przełączyć działanie Burp Proxy na „intercept off” i włączyć przechwytywanie dopiero przy następnych testach.
Podczas przeglądania przez nas testowanej aplikacji Burp Suite będzie na bieżąco aktualizował listę znalezionych podstron/linków, którą później można przejrzeć w zakładce spider->run->”show results”. W połączeniu z danymi uzyskanymi wcześniej z Wfuzz powinniśmy mieć w ten sposób w miarę dobry obraz struktury plików w aplikacji.
W trakcie tego etapu proponuję „przeklikać” aplikację kilkukrotnie, za każdym razem zmieniając nieco ustawienia przeglądarki:
- ze standardowymi ustawieniami
- z wyłączoną obsługą JavaScript
- z wyłączonym nagłówkiem Referer (w rozszerzeniu Modify Headers do Firefoksa reguła „Filter”:”Referer”:”")
Powyższy krok może pomóc w szybkim wykryciu brakującej walidacji po stronie serwera (realizowanej tylko skryptami JavaScript) oraz zabezpieczeń bazujących na adresie strony odsyłającej.
Załóżmy, że testowany serwis zawiera następujący zestaw funkcji (do nich będę się odnosił również w następnych częściach):
- wyświetlenie podstrony o zadanym identyfikatorze
- wyszukiwanie
- rejestracja użytkownika
- logowanie/wylogowanie użytkownika
- mechanizm odzyskiwania zapomnianego hasła
- zmiana hasła, adresu e-mail i innych danych użytkownika, usuwanie konta
- edycja tekstu/HTML (notka w serwisie blogowym, komentarz w sklepie internetowym, itp.)
- upload plików (np. grafiki)
- przesyłanie wiadomości pomiędzy użytkownikami/do obsługi serwisu/na adres e-mail
Za elementy z natury niebezpieczne uznałbym możliwość edycji HTML (persistent XSS, CSRF, phishing), możliwość przesyłania e-maili (spam, phishing), upload plików (kod wykonywalny, persistent XSS, phishing) oraz mechanizm odzyskiwania zapomnianego hasła. Analiza tych funkcji serwisu będzie zatem bardziej złożona – w trakcie testów powinniśmy sprawdzić, jakie zostały wprowadzone zabezpieczenia, ocenić ich skuteczność i ewentualnie zaproponować alternatywne rozwiązania. Pozostałe z dostępnych akcji nie powinny mieć wpływu na bezpieczeństwo, o ile nie zawierają błędu programistycznego – a więc ich testy sprowadzą się do sprawdzenia typowych problemów (reflected XSS, CSRF, SQLI, header injection, path traversal, session fixation, integer overflow, itd.).
Najtrudniejsze do wykrycia są zazwyczaj błędy w logice aplikacji. Ponieważ są one ściśle powiązane z zastosowaniem serwisu, nie można ich znaleźć przy pomocy skanerów i wymagają przygotowania osobnego zestawu testów praktycznie dla każdej funkcji. Do ataków wykorzystujących błędy logiczne zalicza się między innymi parameter tampering i forceful browsing, ale zakres tego typu problemów może być bardzo szeroki. Przykładem może być sytuacja, w której wieloetapowy mechanizm odzyskiwania hasła nie bierze pod uwagę zmian danych użytkowników jakie nastąpiły pomiędzy etapami, w wyniku czego na adres atakującego może być przesłany link do zmiany hasła innego użytkownika.
Przy okazji polowań na błędy w logice serwisu można też spróbować określić, jakie działania użytkownika nie powinny mieć miejsca w określonych sytuacjach, nawet jeśli nie mają wpływu na bezpieczeństwo. Przykład: wykorzystanie przypomnienia hasła w momencie, gdy użytkownik jest zalogowany. Zwykle nie ma powodu, by blokować takie zachowanie (wyjątek: ataki XSS/CSRF), jednak jest ono nieco podejrzane, i w związku z tym można do istniejących mechanizmów ostrzegania dodać alert dla tej sytuacji. Wprowadzenie większej ilości takich punktów kontrolnych może ułatwić odpowiednio wczesne wykrywanie nietypowych (a więc zwykle niechcianych) działań użytkowników – to już oczywiście zadanie dla programistów i administratorów serwisu, ale testerzy mogą mieć ciekawe pomysły, które warto zapisać.
Proponuję wrócić teraz do Burp Suite i zwrócić uwagę na możliwości narzędzi Repeater oraz Intruder. Jednym z elementów testu bezpieczeństwa powinno być sprawdzenie, czy zasoby dostępne wyłącznie dla zalogowanych użytkowników rzeczywiście są chronione. W tym celu wylogujemy się z aplikacji, a następnie w zakladce spider->run->”show results” wybierzemy interesujący nas plik. Po kliknięciu prawym klawiszem wybieramy „send request to repeater”, po czym przechodzimy do podświetlonej na czerwono zakładki. W polu tekstowym widoczne jest żądanie HTTP, które przeglądarka wykonała podczas legalnego dostępu do danej strony. Wybierając przycisk „go” powtórzymy to żądanie, a w dolnym okienku pojawi się odpowiedź serwera, która powinna wskazywać odmowę dostępu do strony (np. komunikat, przekierowanie do strony logowania, formularz logowania).
Burp Intruder przedstawię już w następnej części tego tekstu (na przykładzie próby ataku na parametr określający wybór podstrony serwisu). Trzecia część będzie też zawierać informacje o atakach wykorzystujących upload plików.
15 wrz 07 Testowanie bezpieczeństwa aplikacji internetowych – część 1: Identyfikacja dostępnych zasobów
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.
12 wrz 07 Directory Traversal w Total Commanderze
Kilka dni temu na secunia.com pojawiła się informacja o Total Commander FTP Download Directory Traversal Vulnerability. Jak widać, problemy ze wstrzykiwaniem ścieżki do pliku nie dotyczą tylko aplikacji internetowych. Przykład w wersji dla korzystających z klasycznego hostingu PHP + FTP, bez możliwości utworzenia pliku inną drogą:
<?php
touch("./..\\..\\..\\..\\..\\..\\Windows\\system32\\drivers\\etc\\hosts");
?>
Plik wrzucamy (za pomocą FTP) do katalogu w którym PHP ma prawa do zapisu plików, odpalamy z przeglądarki, i odświeżamy widok katalogu FTP w Total Commanderze. Pojawi się niewinnie wyglądający plik hosts (cała reszta nazwy jest niewidoczna), który możemy spróbować skopiować do jakiegoś katalogu na dysku C:\.
Efekt:
Target already exists:
C:\Windows\system32\drivers\etc\hosts
Do you want to overwrite it?
