26/7/2011
Na naszych szkoleniach poruszamy kilka technik omijania filtrów WAF. Jedną z nich jest HPP, czyli Http Parameter Pollution. Niedawno zaś pojawił się ciekawy dokument opisujący kolejną, zbliżoną do HPP metodę obchodzenia filtrów — Http Parameter Contamination.
Http Parameter Pollution (HPP)
Dla przypomnienia HPP, czyli Http Parameter Pollution to metoda modyfikacji tzw. query string (znaki od ? do końca URI), polegająca m.in. na przesyłaniu kilku takich samych nazw parametrów, ale z różnymi wartościami. W zależności od webserwera i języka programowania, reakcje webaplikacji mogą być różne (przyjęcie pierwszej lub ostatniej wartości, albo stworzenie tablicy z wszystkimi wartościami).
Dzięki HPP możemy tak zmodyfikować parametry w GET/POST/Cookie, aby możliwe było:
– nadpisanie wartości zahardcodowanych zmiennych
– wpłynięcie na działanie logiki webaplikacji
– ominięcie walidacji parametru (ew. regułki WAF)
Http Parameter Contamination (HPC)
HPC, czyli Http Parameter Contamination to celowe zanieczyszczanie nazw parametrów znakami, które wg RFC3986 i RFC2396 mają w przypadku URL różne przeznaczenie:
Bazując na powyższej tabeli, można zauważyć, że aby obejść regułkę Mod_Security blokującą http://localhost/?xp_cmdshell można przesłać do aplikacji następujące dane: http://localhost/?xp[cmdshell (bo [ jest zamieniane na _). Podobnie, aby wykonać blokowany atak path traversal http://IP/test.asp?file=../bla.txt można użyć http://IP/test.asp?file=.%./bla.txt (bo % jest pomijane).
Więcej o HPC możesz przeczytać tutaj. Jeśli jesteś zainteresowany bezpieczeństwem webaplikacji, zapraszamy na nasze szkolenie — właśnie otworzyliśmy rejestrację na kolejny termin (1-2 września), pozostało jeszcze 7 wolnych miejsc, a rejestrując się przed 10 sierpnia zapłacisz mniej.
Ciekawe, aczkolwiek jak sądzę, każdy szanujący się deweloper robi 2 rzeczy:
1. Waliduje dane,
2. Używa modułów wspomagających takich jak Suhosin dla PHP.
To pierwsze załatwia sprawę na poziomie kodu, a to drugie utwardza środowisko, w którym się działa (na wszelki wypadek).
To znaczy na Suhosin nie bedzie to dzialac? Tylko wadliwe jest mod_security?
Ciekawe, nie słyszałem wcześniej o tych metodach ataków, ale popieram przedmówcę – żadne dane nie trafiają do przetwarzania bez uprzedniego sprawdzenia ich zawartości. Szczególnie tak istotne dane jak ścieżki są escape’owane i przechowywane w taki sposób, żeby nie mogło dojść do LFI / RFI.
Tomasz Kowalczyk: Oczywiście, to co obaj mówicie, jest prawdą. Tylko, że
a) niestety nie wszyscy o tym wiedzą
b) niestety nie wszyscy, którzy o tym wiedzą, zawsze o tym pamiętają
c) niestety, nie wszyscy którzy o tym wiedzą i zawsze o tym pamiętają, zdają sobie sprawę z tego, że w funkcjach escape’ujących również zdarzają się błędy (por. ataki na addslashes) ;-)
Zechciej również zauważyć Tomaszu, że w np. w HPP nie zawsze i nie do końca chodzi o to, że dane przekazywane do webaplikacji są niepoprawne bądź nie są “walidowane”, tu atakujący może czasem wpłynąć na logikę webaplikacji, bo webserwer albo framework coś zrozumie tak, a nie inaczej.
dokładnie jak pisze Piotrek, czasem konkretne zachowanie zależy od webserwera na którym aplikacja jest uruchamiana, a nie zawsze używa się świadomie bądź nie środowiska zalecanego przez producenta. Co nie zmienia postaci rzeczy, że a) b) i c) należą do najczęstszych problemów :), problem niestety najczęściej pojawia się pomiędzy klawiaturą a krzesłem.
Czyli żeby wykryć atak HPP, już nie wystarcza walidacja każdego parametru z osobna zapisanego w $_GET[] i $_POST[] ale też trzeba sprawdzać cały łańcuch czyli $_SERVER[‘QUERY_STRING’]. Po prostu makabra! Tym sposobem rozmiar aplikacji i stopień komplikacji kodu rozrasta się do niebotycznych rozmiarów!
Ale kto ci każe parsować QUERY_STRING ?
lecisz po _POST/_GET i tyle – miej jedynie świadomość tego, że dziwne parametry mogą zostać przekazane i każdy należy dokładnie sprawdzić na okoliczność typu (np. można dostać array zamiast stringa).
Zwróć uwagę, że tabelki przedstawiają wejście w postaci query stringa a na wyjściu to, co widzi PHP. Ergo – ty i tak widzisz to, co PHP, tyle że w qs może pojawić się coś innego niż się spodziewasz :)
@Piotr Konieczny: Ależ ja wcale nie próbuję stawiać siebie na pozycji “tego nieomylnego”. ;] Zgadzam się z Tobą, że jeśli programista nie jest świadomy istnienia tego typu problemów, to włamywacze mają wolną drogę do danych / serwera. Celem mojego komentarza było jedynie wskazanie, że przed zdecydowaną większością podatności można się obronić. Jeśli błąd będzie w serwerze / interpreterze / czymkolwiek poza władzą teoretycznego programisty, to niestety “mówi się trudno” i stara wykombinować inne rozwiązanie. Chyba, że tak, jak wspomniał @Kenjiro, można się poratować np. Suhosinem.
@Marcin Maziarz
Zapomniałeś o walidacji nagłówków zapytania i cookies ;)
@Marcin Maziarz
Nie jest tak źle wystarczy wyseparować filtry wejścia i po problemie.
Generalnie kolejne przypomnienie że nie należy ufać magii serwera ;)
Jedynie mod_perl i python dają radę:)