Podczas naszego kursu dla początkujących hakerów Web Application Penetration, zaprezentowaliśmy wszystkie dostępne na pierwszy rzut oka podatności występujące w poszczególnych lekcjach oprogramowania webowego Damn Vulnerable Web Application.
Jeśli oglądałeś uważnie nasze materiały wideo, pewnie zauważyłeś że skaner podatności Vega wykrył podatność typu SQL Injection w module prezentującym formularz logowania podatny na atak na hasła metodą słownikową lub brute-force.
Dzisiaj będzie bardzo krótko i na temat. Pokażemy Tobie na przykładzie wykorzystanie wstrzykiwania zapytań tzn. SQL Injection do obejścia mechanizmów logowania witryny internetowej. Czyli w uproszczeniu mówiąc, tym razem nie będziemy wyciągać żadnych informacji z bazy danych a logować się bez znajomości i łamania hasła.
Podatność SQL Injection w module brute-force (DVWA)
Na wstępie przed omówieniem luki warto zajrzeć do kodu źródłowego obsługującego logowanie w tym module. Możesz to zrobić w skrypcie DVWA przyciskiem View Source. Pamiętaj, że działamy na poziomie zabezpieczeń LOW.
Zwróć uwagę, że w zapytaniu wstawiana jest zmienna $user z danymi przekazanymi za pomocą adresu URL metodą GET. Informacje przekazane z formularza do tej zmiennej nie są w żaden sposób filtrowane, przez co skrypt narażony jest na atak SQL Injection.
Jak pewnie zauważyłeś argument $_GET[’password’] przekazujący hasło od użytkownika, nie jest podatny na SQL Injection. Dzieje się tak dlatego ponieważ, każda wartość wprowadzona w formularzu zamieniana jest za pomocą funkcji haszującej na skrót MD5.
Obchodzenie logowania z SQL Injection
W skrypcie występuje następujące zapytanie widoczne również na powyższym zrzucie ekranu. Czerwonym kolorem zostało oznaczone miejsce w którym należałoby uciąć resztę zapytania za pomocą komentarza SQL. W miejscu zmiennej $user wstrzykujemy złośliwy kod SQL.
SELECT * FROM 'users’ WHERE user= ’$user’
AND password = '$pass’;
Przykład 1 – pominięcie hasła użytkownika
Przejdźmy do pierwszego przykładu. Spróbuj zalogować się za pomocą loginu użytkownika skryptu DVWA odcinając resztę zapytania. Tego typu metoda SQL Injection została zaprezentowana na poniższym obrazku.
Uwaga! W wszystkich przykładach za znakiem komentarza, czyli — występuje jedna spacja niewidoczna na obrazkach. W skrypcie DVWA widać również, że w pewnym miejscu powinien wyświetlany być awatar użytkownika systemu DVWA. Niestety to nie działa bo prawdopodobnie gdzieś w konfiguracji skryptu DVWA są podane złe ścieżki do katalogu z awatarami. Chcę żebyś tylko wiedział, że przyczyną nie jest oczywiście atak SQL Injection.
Przykład 2 – operator logiczny LUB i limitowanie SQL OR
Drugim przykładem jest wykorzystanie operatora OR do zalogowania się do systemu. Tłumacząc fragment zapytania z poniższego obrazka na język naturalny brzmi to tak: wybierz JEDNEGO użytkownika z bazy danych o nazwie a LUB jeśli 2 jest większe od 1.
Wprowadzenie operatora OR umożliwiło dodanie dodatkowego warunku. W naszym przypadku jest to OR czyli po polsku LUB. Z logiki matematycznej wynika też, że liczba dwa jest zawsze większa od liczby jeden, dlatego zapytanie SELECT zwróciło jakiś wynik.
Jeśli spojrzysz ponownie na kod źródłowy to zauważysz, że w instrukcji warunkowej IF jest sprawdzana ilość zwróconych wierszy z bazy danych (użytkowników). Dlatego ograniczyliśmy za pomocą klauzury LIMIT ilość wyników do jednego, ponieważ tylko w takim wypadku skrypt stwierdza, że logowanie się powiodło.
Na kogo w tym przypadku zalogujemy się? Wszystko zależy od silnika bazy danych, jednak prawdopodobnie będzie to pierwszy rekord w bazie danych czyli użytkownik najwcześniej dodany do encji lub o najniższej wartości identyfikacyjnej (ID).
Przykład 3 – logowanie na konkretnego użytkownika po ID
Trzecim i ostatnim dzisiaj przykładem jest logowanie się bez znajomości loginu. W tym celu ponownie wykorzystamy operator logiczny OR (lub). Tym razem jednak zakładamy, że penterser zna strukturę bazy danych a dokładniej nazwy kolumn. Za pomocą user_id ustala na jakiego użytkownika chce się zalogować. Przykład znajduje się poniżej.
W języku naturalnym powyższe zapytanie wygląda następująco: wybierz użytkownika o loginie a LUB o wartości user_id równej 5. Można sobie zadać pytanie, czemu tym razem nie użyliśmy klauzury LIMIT?
Odpowiedź jest bardzo prosta. W większości baz danych systemy projektuje się w taki sposób, żeby wartość ID (identyfikator rekordu) był unikalny. W naszym przypadku każdy użytkownik systemu spełnia tę formułę, ponieważ posiada unikalną wartość w kolumnie user_id. Dzięki czemu mamy pewność, że i tak zwrócony zostanie jeden użytkownik i instrukcja warunkowa IF się wykona.
Oczywiście w testach bezpieczeństwa z wykorzystaniem zapytań SQL musisz być bardzo elastyczny. Na pewno wiele więcej kombinacji udałoby Ci się wymyślić, umożliwiających w tym mechanizmie atak.
Jeśli jesteś tutaj pierwszy raz to na pewno zainteresuje Cię nasz kurs na blogu u YouTube WEP. Poniżej umieszczam jego playlistę. Wśród lekcji są oczywiście zagadnienia dotyczące SQL Injection.
Podsumowanie o obchodzeniu mechanizmów z wstrzykiwaniem zapytań SQL
Chcę żebyś po tym krótkim wpisie, wiedział że SQL Injection umożliwia nie tylko na wyciąganie lub modyfikowanie wartości z bazy danych. Czasami po wstrzyknięciu możliwe jest ominięcie pewnych mechanizmów strony internetowej. Nie ograniczaj swojego umysłu i bądź kreatywny, tego typu bypass nie musi wcale dotyczyć tylko logowania użytkownika.
Dla przykładu wyobraź sobie, że na stronie internetowej istnieje mechanizm dodawania komentarzy pod wpisami na blogu. Administrator ma możliwość w nim banowania adresów IP złych hejterów. Po prostu wtedy komentarze dodawany przez taką osobę nie jest wyświetlany.
Potencjalnie taki hipotetyczny szybko wymyślony na potrzeby tego podsumowania mechanizm może posiadać w sobie lukę SQL Injection, za pomocą której cyberprzestępca mógłby wyciąć część odpowiadającą za sprawdzane adresu ip podobną do następującego fragmentu: AND ip=’ip odwiedzajacego’.
Pamiętaj że SQL Injection nie tylko może dotyczyć klauzury SELECT. Może być to dowolnie inne klauzury w którym są wstawiane dane pochodzące od użytkownika lub samej przeglądarki np: INSERT, DROP, UPDATE. Jak wiesz nagłówki HTTP też mogą być fałszowane… Jeśli chcesz być na bieżąco śledź nas na Faceboku #HakerEduPL. To by było dzisiaj na tyle, powodzenia w edukacji pentesterskiej :-).