Tworzenie własnego PHP Proxy dla narzędzi typu sqlmap – podstawy

13 czerwca 2019, 09:34 | Teksty | komentarze 4
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Praca z narzędziami takimi jak sqlmap wymaga od nas czasami kreatywnego podejścia do realizowanych testów. Zdarza się, że czasami musimy znaleźć wywołanie naszego payloadu w innymi miejscu niż te, w którym występuje wstrzyknięcie, bądź musimy w odpowiedni sposób obrobić dane, aby narzędzie testujące zrozumiało odpowiedź strony.

https://pl.pinterest.com/pin/412923859572038212/?lp=true

Testowana przez nas aplikacja przyjmuje parametry metody GET w celu pokazania informacji o użytkowniku oraz w celu pokazania informacji o wszystkich użytkownikach. Ponadto zwracane informacje są z niejasnych względów „zakodowane” poprzez następującą kombinację funkcji:

  1. Konwersja do base64
  2. Wprowadzenie szyfru cezara z przesunięciem o 13 (rot13)

Przykładowe zapytanie aplikacji zwracające informacje o profilach:
http://127.0.0.1/?user=all

Odpowiedź serwera aplikacji:

Rozwiążmy zatem zawartość pola ‘data’, pierwszy krok to zdekodowanie zawartości według instrukcji znanych z początku artykułu.

Operacja ROT13:

Źródło ROT13

Operacja Base64 Decode:

Źródło Base64 Decode

Aplikacja pozwala również na przeglądanie każdego użytkownika pojedynczo poprzez zapytanie:
http://127.0.0.1/?user=2

Odpowiedź serwera aplikacji:

Z racji, iż jest to aplikacja szkoleniowa – wiemy, że podatnym parametrem jest właśnie ‘user’ z metody GET. Niestety, aby nie było zbyt łatwo, występuje w tym miejscu atak Second Order SQL Injection, w tym przypadku niebezpieczny kod SQL nie da efektu bezpośrednio w odpowiedzi HTTP na wysyłane zapytanie, lecz po powrocie do spisu wszystkich użytkowników.

Sprawdźmy zatem ponownie odpowiedź API dla listingu wszystkich użytkowników po wcześniejszym przeglądnięciu jednego – czyli wracamy na stronę:
http://127.0.0.1/?user=all

Odpowiedź serwera aplikacji:

Ponownie zdekodujemy zawartość pola ‘data’.

Operacja ROT13:

Źródło ROT13

Operacja Base64 Decode:

Źródło Base64 Decode

W odpowiedzi aplikacji pojawiło nam się pole ‘lastVisited’ – które to właśnie będzie wektorem naszego ataku.

Czy narzędzia automatyczne typu Burp, ZAP, WebInspect lub nawet dedykowany sqlmap w domyślnych konfiguracjach odnajdą błąd?
Odpowiedź brzmi: „nie”, ponieważ: po pierwsze jest to atak Second Order SQL Injection, po drugie zawartość kontekstu jest niestety kodowana w dość dziwny sposób.
Dowód nieudanego testu programem sqlmap.

Sposobem na automatyzację tego ataku jest stworzenie własnego skryptowego proxy.

Krok pierwszy to utworzenie skryptu, który pobierał będzie zawartość strony biorąc pod uwagę przekazany metodą GET parametr (nasz payload).

Uruchamiamy nasze proxy w przeglądarce w celu weryfikacji, czy dane są pobierane:
http://localhost/proxy.php?user=2

Jak widać, podstawowe proxy działa, ale czy tego chcemy? Atak SQL Injection przez takie proxy nadal będzie niewykrywalny dla większości skanerów, bo praktycznie nic nie zostało zmienione.

Kolejnym krokiem zatem będzie postępowanie zgodnie z zasadami ataku Second Order, czyli weryfikacja kontekstu na innej podstronie.

Dla przejrzystości dodaliśmy opisy kroków, w celu weryfikacji tego co się dzieje:
http://localhost/proxy.php?user=2

Za pomocą tego proxy już w tej chwili jesteśmy w stanie wykonać atak Second Order SQL Injection, jednak dane przekazywane są w nieczytelnej formie – co nadal unieszkodliwia większość skanerów.

Rozwińmy zatem kod o deszyfrowanie otrzymanych danych w celu ich łatwiejszej interpretacji:

Ponownie zweryfikujmy odwiedzając stronę przez proxy w naszej przeglądarce:
http://localhost/proxy.php?user=2

Proxy w obecnej postaci powinno umożliwić wykonanie ataku SQL Injection dla programu typu sqlmap:

W pełni wykonany atak pozwala na zrzut danych z bazy:

Podsumowując, warto posiadać odrobinę wiedzy programistycznej podczas realizacji testów bezpieczeństwa, chociażby właśnie po to, aby móc posiłkować się własnymi skryptami.

Jeżeli macie ochotę przetestować skrypt na własnej maszynie, znajdziecie go poniżej.

  1. Plik bazy danych:
  2. Plik podatnej strony:

    — Robert Kruczek, hakuje w Securitum

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Wowa

    Osobiście w takich sytuacjach tworzę tamper script do sqlmapa ale jak ktoś nie lubi/zna Pythona to rzeczywiście można sobie proxy w dowolnym języku stworzyć. Spoko artykuł

    Odpowiedz
  2. Wowa

    Ok tamper może być niewystarczający bo odpowiedź musi być zmieniona … nvm

    Odpowiedz
  3. wnnb

    Fajny artykuł, dziękuję.

    Odpowiedz
    • zero one

      Prawda. Dołączam się.
      Jeszcze ten obrazek. :-D

      Odpowiedz

Odpowiedz