Wprowadzenie do logiki systemów WAF (Web Application Firewall)

Systemy Web Application Firewall (WAF) stały się integralną częścią infrastruktury znakomitej większości wykorzystywanych komercyjnie aplikacji internetowych. Pomysł na zbliżone podejście do problemu niebezpiecznego inputu, jak w przypadku niechcianych pakietów sieciowych, okazał się skuteczną ochroną przed typowymi klasami błędów trapiących aplikacje webowe. Do najpopularniejszych projektów open-source, realizujących funkcjonalność WAF należą: ModSecurity, PHPIDS, NAXSI oraz lua-resty-waf. Sposób działania WAFa najłatwiej jest pokazać na przykładzie analizy żądania HTTP pochodzącego od klienta:

1. Klient wysyła żądanie o zasób do serwera
2. Żądanie “wpada” do WAFa
3. Na podstawie typu requestu wybierany jest odpowiedni zestaw reguł
4. Normalizacja danych do formatu zrozumiałego przez firewall
5. Rozkład payloadu na części składowe
6. Aplikacja reguł lub rozpoczęcie działania mechanizmu klasyfikacyjnego
7. Korelacja zdarzeń (np. wykryte reguły i historia danej sesji) oraz zapis danych do logu
8. Odrzucenie żądania w przypadku pozytywnej klasyfikacji pod kątem złośliwości

Źródło rysunku – https://www.blackhat.com/docs/eu-16/materials/eu-16-Argyros-Another-Brick-Off-The-Wall-Deconstructing-Web-Application-Firewalls-Using-Automata-Learning.pdf

Najpopularniejszymi sposobami detekcji niebezpiecznych danych (punkt 6 z powyższej listy) są:

• Sygnatury oparte o wyrażenia regularne,
• Wykrywanie anomalii,
• Budowa scoringu żądań i klientów,
• Mechanizmy określania reputacji.

Znając teoretyczne aspekty pracy WAF, jesteśmy w stanie określić potencjalne możliwości ataku, którego celem jest przemycenie niebezpiecznych danych do aplikacji webowej.

Co może zepsuć się w WAFie?

Najprostsze problemy z WAF leżą w jego funkcjonalnościach, a dokładniej w tych których brakuje: rzadko używane sposoby kodowania danych, nieobsługiwane protokoły, brak rozpoznawania nowych typów zawartości przekazywanej do serwera. Czasami są to również problemy związane z ograniczeniami na poziomie implementacji: ograniczenia długości payloadu, obsługiwanych zestawów znaków czy typów parametrów.

Etapem pracy WAF, w którym można zaobserwować powyższe ograniczenia jest normalizacja danych. Jak wcześniej zostało wspomniane, ten krok odpowiada za przystosowanie danych do formatu “zjadalnego” przez firewall, dla przykładu: podmieniane są wszystkie nadmiarowe cudzysłowy, zamieniane są duże litery na małe oraz usuwane są niepotrzebne znaki. Inną interesującą słabością, którą można zaobserwować w ramach tej fazy pracy firewalla są niespójności pomiędzy regułami normalizacji a regułami wykrywającymi ataki – w skrajnych wypadkach mogą się wykluczać. W momencie zaistnienia takiej sytuacji zazwyczaj payload jest przekazywany dalej.

Wykrywanie ataków za pomocą sygnatur (najczęściej wykorzystywana metoda), w oczywisty sposób wymusza posiadanie wzorców ataków – te mogą być różne pod względem jakości, jak i zawartości. Dużym wyzwaniem jest pisanie generycznych reguł na skomplikowane ataki, bez znajomości sposobu w jaki pracuje chroniona aplikacja webowa. Dlatego warto mieć na uwadze, że niektóre metody exploitacji WAF są niezależne od technicznych aspektów jego pracy i wynikają z jego “braku wiedzy” lub niskiej jakości sygnatur – wzorce budowane w oparciu o “nieszczelne” wyrażenia regularne, są bardzo proste do obejścia i pozwalają maskować aktywność napastnika.

Webowe firewalle, podobnie jak każde oprogramowanie oparte o zewnętrzne zależności, stan bezpieczeństwa opierają o zabezpieczenia najsłabiej uszczelnionego komponentu. Ten fakt powoduje, że podatność w jakimkolwiek komponencie jest słabością WAF. Taka sytuacja miała miejsce w trakcie rozwoju projektu modsecurity, zależnego od biblioteki libinjection: deweloperzy sforkowali bibliotekę, zamiast podlinkować ją do projektu. W efekcie modsecurity korzystał z wersji, która nie była w stanie przeprowadzić detekcji ataku SQL Injection zawierającego prostą dyrektywę: or exists (select 1).

Atakowanie WAF za pomocą LightBulb

Niewątpliwie najpopularniejszym narzędziem w pracy pentesterów aplikacji webowych jest Burp Suite. Bogactwo jego funkcjonalności, niestety nie uwzględnia narzędzi przydatnych do testowania WAF. Tę niszę zapełnia projekt LightBulb, automatyzujący i “uczący” się reakcji firewalla na przesyłane fragmenty danych. Rozwiązanie zapewnia pełną integrację z Burpem.

Okno wtyczki LightBulb w BurpSuite.

Wyczerpujący opis instalacji wtyczki oraz przygotowania środowiska można znaleźć pod tym adresem. W opisie skupię się na przeprowadzeniu procesu nauki oraz obejścia WAFa. Testowaną platformą jest modsecurity (wersja 2.9.2) + sygnatury OWASP CRS (wersja 3.1.0; pobrane z GitHuba).

Jak działa WAF od strony LightBulb?

Pierwszym krokiem jest przekazanie żądania HTTP zawierającego testowany parametr, o wartości zablokowanej przez modsecurity, do LightBulb. W prezentowanym przykładzie jest to żądanie: GET /index.html?exec=/bin/bash. Kod błędu HTTP 403 informujący o odrzuceniu żądania jest wymagany do detekcji powodzenia działania wtyczki.

Następnym etapem jest wybór wyrażenia regularnego lub gramatyki, która będzie podstawą do wykrycia możliwości ataku na firewalla (Zakładka: LightBulb – Learning / Tests / Regex lub Grammar; Seeds jest wykorzystywane jedynie do wyrażeń regularnych). Po wyborze modelu ataku, zaznaczamy żądanie, które zostało przesłane z modułu Proxy w kroku poprzednim.

Klikamy prawym przyciskiem myszy na request i z menu podręcznego wybieramy opcję Start Filter Learning oraz potwierdzamy parametr będący celem testu:

LightBulb zaczyna działać i całkiem szybko (dokładnie zajęło mu to 208 requestów) udaje mu się znaleźć obejście dla kombinacji danej gramatyki początkowej i testowanego parametru. Przez obejście jest rozumiane przekazanie wygenerowanego inputu i otrzymanie statusu HTTP 200 OK:

Sprytniejsze podejście do nauki

Powyższe kroki demonstrują jedynie najprostszy scenariusz ataku. Zazwyczaj podczas testów potrzebujemy nieco więcej niż tylko obejście WAF – dobrze jest mieć payload wykorzystujący słabości firewalla oraz pozwalający na wstrzyknięcie kodu, który wykona się w przeglądarce użytkownika.

Źródło – https://census-labs.com/media/bsidesath2017-lightbulb.pdf

LightBulb umożliwia tworzenie i testowanie requestów zawierających dane o takiej specyfice. Służy do tego projekt SFADiff, który jest integralną częścią frameworka, łącząc w sobie znajomość gramatyki HTML, SQL oraz niezbędnych podstaw JavaScript.

Aby skorzystać z opcji hybrydowej musimy przejść do zakładki LightBulb – Differential Learning / Tests / Regex lub Grammar. Podobnie jak w przypadku zwyczajnego testowania WAF, wybieramy interesujące wyrażenia regularne lub gramatyki oraz wzorcowy request HTTP i klikamy na opcję ”Start Filter Differential Learning with Browser”. Do działania tej opcji wymagane jest uruchomienie przeglądarki i wejście na adres wyświetlony w okienku. Po uruchomieniu strony rozpoczną się testy:

Niestety, w trakcie moich testów nie powiodło się znalezienie wartości parametru, która jest w stanie obejść modsecurity oraz wykonać się w przeglądarce. Podczas tworzenia projektu autorzy znaleźli wartości pozwalające na obejście w regułach projektów PHPIDS oraz Expose. Efektywność wyszukiwania tego typu danych da się polepszyć, aktualizując wyrażenia regularne i gramatyki wykorzystywane przez LightBulb.

Rozpoznawanie firewalla

Dodatkową funkcjonalnością LightBulb, którą można uznać jako wersję przedprodukcyjną, jest rozpoznawanie rozwiązania chroniącego testowaną aplikację webową. Dostarczone reguły zawierają jedynie wąski zakres WAF dostępnych na rynku, w starych wersjach, co znacząco wpływa na skuteczność detekcji.

W przeprowadzonych testach za pomocą wbudowanych drzew decyzyjnych, modsecurity (wersja 2.9.2) rozpoznawany jest jako Expose 2.4.0 oraz WebCastellum 1.8.4. LightBulb umożliwia ręczne lub automatyczne budowanie reguł detekcji WAF, więc użytkownicy nie są skazani na “przeterminowane” drzewa decyzyjne.

W celu sprawdzenia swojego WAF należy wybrać zakładkę Tree i jedną z sygnatur wbudowanych domyślnie w projekt. Następnie, podobnie jak w poprzednich etapach wybór żądania testującego oraz opcję Start Filters(s) WAF Distinguish:

Z racji niewielkiego skomplikowania reguł, działają one bardzo szybko i po paru żądaniach ukazuje się wynik działania modułu:

Zakończenie

Web Application Firewalle są interesującą częścią infrastruktury webowej – ich słabości w znaczący sposób “pomagają” w kompromitacji aplikacji webowej. Do grona niebezpieczeństw trapiących ten rodzaj oprogramowania możemy zaliczyć: słabe jakościowo reguły, wykorzystujące wyrażenia regularne podatne na wstrzyknięcia dodatkowego inputu; nieaktualizowane biblioteki oraz brak wsparcia najnowszych standardów.

W artykule został przedstawiony obiecujący projekt, pozwalający na automatyzację testów WAF, pod kątem niespójności reguł, z poziomu Burp Suite – LightBulb. Narzędzie to jest na razie w początkowej fazie rozwoju i nie zaskakuje mnogością funkcjonalności. Lecz jego możliwości dostosowania pozwalają w znaczący sposób zwiększyć potencjał wyszukiwania błędów w logice filtrowania żądań, czyniąc z niego interesującą pozycję w zestawie narzędzi każdego pentestera.

– Kamil Frankowicz