Paweł Goleń, blog - Formularz komentarzy "Szybszy(?) blind sql injection"

Paweł Goleń: Szybszy(?) blind sql injection

nospam@example.com (Paweł Goleń) — Mon, 20 Jun 2011 20:25:43 +0200

Na początek zmieniłbym zakres rozważań do całego całego (że użyję pythonizmu) string.printable, co daje na początek zakres 100 znaków. Po pierwszym podziale mamy 50, po drugim 25, więc zakładam, że zgadnięcie dowolnego znaku z tego zakresu będzie wymagało 6-7 pytań (sprawdzę to później). Załóżmy, że jest to 7 zapytań, a długość odczytywanych danych to 10 znaków, mamy więc 70 zapytań. Zredukowanie początkowego zestawu znaków do 50 zmniejszy ilość wymaganych pytań prawdopodobnie do 60, jeśli udałoby się trafić w zakres 25 znaków, byłoby to jakieś 50 zapytań (i dalej w ten sam sposób). Być może sensowną strategią byłoby zapytanie o zbiory najbardziej prawdopodobnych znaków, kolejno o 13, 25, 50 i 75 znaków. W najgorszym przypadku ustalenie danych zajęłoby (wariant klasyczny) + 4 zapytania, natomiast w najlepszym jakieś 4. Wszędzie oczywiście jakieś ułamki, a przybliżenia biorę z głowy i mogę się mylić +/- 1. Ale i tak wszystko się rozbija o to, co w tej bazie, tabeli, wierszu i kolumnie właściwie jest.

Paweł Goleń: Szybszy(?) blind sql injection

nospam@example.com (Paweł Goleń) — Mon, 20 Jun 2011 20:01:47 +0200

To nie będzie zbiór znaków, tylko nadzbiór znaków. To znaczy zbiór znaków występujących w szukanych danych zawierać się będzie w tym zbiorze, który ustalisz tego typu regexpami. Popatrz choćby na przypadek z hashami. Zakres znaków będzie stosunkowo niewielki, a-f0-9, ale popatrz jak długo takie podejście będzie go ustalało i jak wiele znaków znajdzie się dodatkowo w tym "nadzbiorze".

Kacper: Szybszy(?) blind sql injection

nospam@example.com (Kacper) — Mon, 20 Jun 2011 18:55:03 +0200

"Natomiast zastanawiam się, czy jakimiś mega-sprytnymi regexpami nie można by ustalić plus-minus zbioru znaków jakie występują w całym ciągu. Any ideas? ;>" Jakimiś mega-sprytnymi chyba nie, ale można po prostu kolejno sprawdzić: '^a+$' '^[ab]+$' '^[abc]+$' '^[abcd]+$' '^[abcde]+$' ... '^[abcdefghijklmnopqrstuvwxyz0123456789]+$' jak w końcu zwróci true, poznasz zbiór znaków ;-)

Gynvael Coldwind: Szybszy(?) blind sql injection

nospam@example.com (Gynvael Coldwind) — Mon, 20 Jun 2011 18:06:59 +0200

Hmm... w zasadzie większe pole do popisu jest przy analizie więcej niż jednej litery. Np. możnaby spróbować zawężyć zbiór znaków, etc. Przykładowo, jeśli nie ma się pojęcia co może być w kolumnie to zazwyczaj trzeba szukać ASCII 32-126 włącznie. Więc wysyłając na początku kilka zapytań regexpowych dla całego ciągu typu [A-Za-z] a potem [a-z] pozwoliłoby znacznie zwężyć przedział w którym się szuka. Nie wiem czy możnaby/wartoby schodzić poniżej [a-z] z zapytaniami natomiast. Ofc, implicit cały czas chodzi o prawdopodobieństwa. Natomiast zastanawiam się, czy jakimiś mega-sprytnymi regexpami nie można by ustalić plus-minus zbioru znaków jakie występują w całym ciągu. Any ideas? ;> Cheers,

Paweł Goleń: Szybszy(?) blind sql injection

nospam@example.com (Paweł Goleń) — Mon, 20 Jun 2011 10:30:52 +0200

Moje wyniki mogłyby wyglądać nieco lepiej, gdybym uwzględnił pełny zakres znaków (duże i małe litery, cyfry, znaki specjalne). Wówczas różnica wynikająca z szybszego zawężania przedziału, w którym szukane jest rozwiązanie prawdopodobnie byłaby bardziej widoczna, niż dla wykorzystanego przeze mnie w eksperymencie przedziału [a-z]. Masz rację, wynik końcowy (ilość wymaganych zapytań) mocno zależy od tego, czy prawdopodobieństwo wystąpienia określonego znaku jest zgodne z "rzeczywistym" prawdopodobieństwem dla danych znajdujących się w atakowanej bazie. W niekorzystnych przypadkach wydajność takiego "zmodyfikowanego" podejścia może okazać się dużo niższa, niż podejścia "klasycznego".

mm: Szybszy(?) blind sql injection

nospam@example.com (mm) — Mon, 20 Jun 2011 10:23:54 +0200

Ciekawa analiza. Wg mnie Twoje wyniki potwierdzają, że nie warto bawić się w prawdopodobieństwa. W rzeczywistości wiele nazw będzie mieszanką pol/eng a do tego dojdą skróty, w których często brak popularnych samogłosek i jeśli już różnica jest minimalna to przy zwiększeniu pomyłki w określaniu prawdopodobieństwa występowania znaków będzie jeszcze gorzej.

Paweł Goleń: Szybszy(?) blind sql injection

nospam@example.com (Paweł Goleń) — Mon, 20 Jun 2011 10:21:43 +0200

Bo ja wiem, czy taki dobry? Czasami mam takie pomysły na nikomu nie potrzebne eksperymenty, które są w stanie zainteresować jakiś ułamek społeczeństwa :) Tak zupełnie z innej beczki - umiejętność (kiepskiego) programowania pozwala czasem na stworzenie symulacji ciekawych problemów z "prawdziwego życia", których wyniki pozwalają podjąć decyzję (czy lepszą - kwestia dyskusyjna) w naszym świecie specjalizującym się w robieniu wody z mózgu. Choćby takie "trywialne" zagadnienie jak wybór najlepszej oferty abonamentu z uwzględnieniem własnej specyfiki korzystania z telefonu :)

Gynvael Coldwind: Szybszy(?) blind sql injection

nospam@example.com (Gynvael Coldwind) — Mon, 20 Jun 2011 00:01:42 +0200

O kurcze, good stuff ;) Planujesz powtórzyć ekspryment dla wersji z wykorzystaniem kontekstu (tj. prawdopodobieństwo wystąpienia znaku X po znaku Y)? Sądzę, że tutaj rezultat byłby lepszy. Hmm nie jestem pewien czy słownik języka polskiego jest dobrym źródłem do stworzenia tablicy statystyk występowania danego znaku. Raczej słownik ograniczony do języka potocznego i w użytku codziennym byłby bardziej adekwatny imo (chodzi o pominięcie słów bardzo rzadko używanych/archaicznych/bardzo specialistycznych). Ale z drugiej strony... pewnie wyniku i tak by to za bardzo nie zmieniło. Jestem bardzo ciekaw kolejnego postu z tej serii ;> Cheers!