Seria o SQL Injection:
Jak zostać ekspertem od SQL Injection – cz. 1
Jak zostać ekspertem od SQL Injection – cz. 2
Jak zostać ekspertem od SQL Injection – cz. 3
Jak zostać ekspertem od SQL Injection – cz. 4
Jak zostać ekspertem od SQL Injection – cz. 5
Witam Cię ponownie w kolejnej części poradnika JAK ZOSTAĆ EKSPERTEM OD SQL INJECTION. To już trzecia odsłona tej serii i już jesteś coraz bliżej kompletnej wiedzy w tym zakresie.
W poprzednim artykule Jak zostać ekspertem od SQL Injection cz.2 pokazałem Ci techniki wykrywania podatności – w zupełności wystarczające by już móc zacząć „działać”.
Poznałeś również, kiedy having a kiedy group by będzie skuteczne.
Teraz uzupełnimy wiedzę z poprzednich serii o metody wykrywania zabezpieczeń. Z pewnością to ważne, aby być bardziej skutecznym w wykrywaniu lub ukrywaniu – tak do rymu
Omijanie zabezpieczeń
Techniki omijania walidacji danych wejściowych oraz wyjściowych są bardzo do siebie zbliżone. Systemy wykrywania włamań bazujące na sygnaturach są zawodne i można je oszukać.
Przykładowa sygnatura ‘ OR 1=1 może zostać ominięta poprzez następujące, równoważne jej wyrażenia:
1. ‘ OR ’tekst’ = X’tekst’
2. ‘ OR 2=2
3. ‘ OR 1
4. ‘ OR TRUE
5. ‘ OR ’tekst’ = concat(‘tek’,’st’)
6. ‘ OR ’tekst’ = ’tekst’
7. ‘ OR ’tekst’ IN (‘tekst’)
8. ‘ OR ’tekst’ like ’teks%’
9. ‘ OR 2 > 1
10. ‘ OR 2 BETWEEN 1 AND 3
11. ‘ OR ’tekst’ > ’t’
Z kolei znak większości lub mniejszości można zastąpić predykatem BETWEEN -> Sygnatura OR id>1 może być wyrażona przez:
OR id between 2 and 1e100
Zabezpieczenia mogą zostać ominięte poprzez różne kodowanie danych. Ważnym aspektem jest, aby zrozumieć sposoby kodowania
na przykładzie adresu URI, poniżej przedstawiłem budowę URI oraz możliwe formy kodowania tego adresu:
Oznaczenia
A) Schemat (protokół),
B) Użytkownik oraz hasło,
C) Autoryzacja (nazwa serwera),
D) Port,
E) Ścieżka do pliku,
F) Zapytanie,
G) Fragment.
W atakach typu SQL Injection modyfikujemy zapytania. Kodowany znak w systemie szesnastkowym poprzedzamy znakiem procenta %. Dlatego w przypadku kodowania ciągiem znaków, odpowiadającym znakowi spacji jest %20.
Zapytanie:
http://user:pass@host:80/kat1/kat2/plik?par1=wart1&par2=wart2#fragment_dokumentu
w kodowaniu szesnastkowym, potencjalnie umożliwiające ominięcie systemów wykrywania włamań będzie wyglądać następująco:
par1=%77%61%72%74%31%26%70%61%72%32%3D%77%61%72%74%32
W związku z tym systemy, które nie radzą sobie z dekodowaniem szesnastkowej reprezentacji znaków w adresie internetowym, nie są w stanie wykryć ataków typu SQL Injection, przeprowadzonych przy użyciu kodowania szesnastkowego. Używając funkcji MySQL CHAR, atakujący jest w stanie zakodować ciąg znaków przekazanych do funkcji MySQL, na różne systemy pozycyjne.
Przykładami wykorzystania kodowania za pomocą funkcji CHAR są:
● Wykorzystanie predykatu LIKE, bez użycia apostrofów:
Zapytanie:
SELECT login FROM tabela WHERE login LIKE ’%a’
można zapisać kodując %a:
SELECT login FROM tabela WHERE login LIKE char(37,97), char(0×2561),
●Wykorzystanie zapytania bez używania cudzysłowów:
Zapytanie równoważne:
SELECT * FROM tabela WHERE id = 1
to:
SELECT * FROM tabela WHERE id = char(49)
● Załadowanie pliku z dysku z kodowaniem jego nazwy:
W celu wczytania pliku plik można wykorzystać:
SELECT (load_file(char(112,108,105,107))),
● Sprawdzenie istnienia pliku plik na dysku:
IF((load_file(char(112,108,105,107))<>char(39,39)),1,0)
Oczywiście powyższe przykłady nie wyczerpują zbioru możliwych wariantów kodowań znaków, które mogą zostać z powodzeniem wykorzystane do omijania zabezpieczeń.
Podczas wykrywania podatności na ataki typu SQL Injection bardzo ważną rolę odgrywa wykrywanie różnego sposobu zapisu białych znaków, ze szczególnym uwzględnieniem znaku spacji. W celu oszukania systemów wykrywania włamań używamy wielokrotne spacje oraz zamienniki spacji.
Poniżej przedstawione są fragmenty kodu służącego do wstrzyknięcia w oryginalne zapytanie SQL, oraz odpowiadające im fragmenty zapisane tak, aby ominąć ochronę IDS/IPS z zarazem mające identyczną funkcjonalność:
Do powyższych przykładów można dodać wiele innych kombinacji zapisu białych znaków, razem z równoważnikami warunków logicznych, ich wielokrotnym zestawianiem, dlatego utrudnia to analizę takiego wyrażenia przez systemy ochronne.
Podsumowanie
Posiadając wiedzę z poprzednich części jak przeprowadzać ataki SQL Injection, tutaj pokazałem Ci w jaki sposób wejść na wyższy level – jak ominąć aktywne / pasywne systemy zabezpieczeń.
Wiedza z tej części pomogła mi być niesamowicie skutecznym w mojej codziennej pracy pentestera, włączając w to całkiem spektakularne i udane testy wielkich serwisów i systemów!
Jeśli spodobał Ci się ten artykuł, podziel się swoim komentarzem oraz udostępnij dalej ten post aby wiedza docierała do większej liczby osób.
Co w kolejnej części.
W kolejnej części zobaczymy już realne fragmenty kodu aplikacji i SQL i prześledzimy dokładnie błędy umożliwiające atak SQL Injection. Teorię przekujemy w praktykę!
