Rozpatrzmy prostą funkcję zaprezentowaną poniżej:

void VulnFunc(char *ptr)
{
  char buffer[32];
  int i;

  for(i=0;(*ptr)!='&';i++)
    buffer[i]=*(ptr++);

  //dalsze instrukcje działające na buforze, nie zmieniające jego
  //zawartości, przykładowo liczące wartość skrótu MD5 z zawartości
  //bufora, nieistotne jeśli chodzi o atak buffer overflow
}

Możemy łatwo wyobrazić sobie i podać zadanie tej funkcji, która pobiera pewne dane, kopiuje je do bufora oraz wykonuje z jego pomocą pewne operacje. Łatwo możemy wskazać widoczny od razu błąd: dane kopiujemy do bufora bez sprawdzania czy go nie przepełnimy. Warunkiem zakończenia kopiowania jest natrafienie na znak &. Właśnie taki błąd, o ile możemy podać dowolne dane wejściowe może zostać wykorzystany.

Nim przejdziemy do preparowania odpowiedniego ciągu znaków będących exploitem obejrzyjmy stos podczas normalnego wywołania funkcji, zaprezentowany na rysunku nr 1.

Stos podczas normalnego wywołania funkcji

W lewej części rysunku przedstawiona jest zawartość pamięci wykorzystywanej na stos. Wyróżnione na czerwono obszary to zmienna i oraz bufor, z przepisaną zawartością, w tym przypadku tekstem „Ala”. Wyróżniony na niebiesko fragment to wskaźnik ptr przekazywany jako parametr. Wszystkie te informacje można skonfrontować z zawartością zmiennych podczas wykonania programu zaprezentowanych po prawej stronie rysunku.

Wróćmy na chwilę do wyróżnionego na niebiesko adresu, będącego parametrem. W takim przypadku nasze zainteresowanie powinny dotyczyć 32 bitowy adres znajdujący się bezpośrednio przed nim. Adres ten, jest adresem powrotu z funkcji. Jeśli uda nam się go zmienić, w momencie powrotu z funkcji … wykonamy inny kod, nieprzewidziany przez programistę.

Aby prześledzić taki przypadek rozpatrzmy sytuację, kiedy do funkcji zostanie podany ciąg znaków postaci (liczby hexadecymalne):


0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x83,0xec,0x80,0xbe,
0xe6,0x10,0x41,0x00,0x68,0x41,0x6c,0x61,0x00,0x8b,0xdc,0x6a,0x40,0x53,
0x53,0x33,0xc0,0x50,0xff,0xd6,0xff,0x15,0xe6,0x6c,0x41,0x00,0x68,
0xfd,0x12,0x00,0x26

… i podobnie jak w poprzednim wywołaniu funkcji prześledźmy zawartość stosu.

Stos przy próbie ataku

Na zaprezentowanym rysunku możemy zaobserwować, że do bufora zostało przepisane dużo więcej danych niż poprzednio. Dokładnie 44 bajty (wartość hexadecymalna 2c w obszarze pamięci zmiennej i). Wartość ta jest większa niż zadeklarowany na 32 bajty bufor. Jednak co najważniejsze, czy – powinniśmy powiedzieć – najgroźniejsze, został nadpisany adres powrotu z funkcji (fragment wyróżniony na niebiesko), gdzie teraz znajdują się instrukcje które zostaną wykonane przez program. Pamiętając iż zmienne na maszynach z procesorem Intel są przechowywane „od końca” możemy odkodować adres powrotu. Skok nastąpi do instrukcji znajdującej się pod adresem 0×0012fd68. Jeśli przyjrzymy się dokładnie obszarowi pamięci stosu, możemy zauważyć, że skoczymy w zaprezentowany na rysunku obszar pamięci. Dokładniej wykonanie nowego kodu zaczniemy od instrukcji o kodzie 0×90. Dalej możemy zaobserwować jeszcze kilka instrukcji o tym samym kodzie. Taka sekwencja jest często spotykana w exploitach. Kod 0×90 ma instrukcja NOP – no operation. Instrukcja która nic nie robi, ale ma długość jednego bajta. Taka sekwencją zwana poduszeczką NOP ( jest przydatna, jeśli okazało by się, iż nie trafimy dokładnie w początek kodu exploita). Dalszą analizę tego kodu zostawmy na później … i zobaczmy co się stanie jak wykonamy ten kod. Wyniki przedstawia rysunek.

Wykonanie kodu

Co robi kod na stosie … trochę assemblera

Znaczenie instrukcji o kodzie 0×90 zostało już wyjaśnione wcześniej, teraz przyjrzyjmy się reszcie kodu.
. . .

Co robi ten kod? Pierwsza instrukcja odejmuje 128 od rejestru esp – stack pointer, robiąc miejsce na stosie dla dalszego kodu. W dalszej części przypisujemy do rejestru esi adres funkcji MessageBox. Później odkładamy 5 wartości na stos, najpierw pewne dane, które już wcześniej widzieliśmy na stosie (co dokładnie … zostawiam czytelnikowi do zgadnięcia). Nim odłożymy kolejne 4 wartości zapamiętujemy zawartość rejestru esp w rejestrze ebx. Adres ten odpowiada początkowi stosu, czyli aktualnie danym załadowanym na stos przed chwila. W dalszej części odkładamy na stos liczbę 0×40, dwa razy wskaźnik wskazujący na pewne dane znajdujące się na stosie oraz wartość 0. Potem dokonujemy wywołania funkcji MessageBoxA. Co robiliśmy wcześniej na stosie? – odkładaliśmy parametry – handle do okna (0 – NULL, czyli okno bez powiązania z innym oknem), dalej dwa razy wskaźnik na zawartość okna i jego tytuł (czy już wiadomo jakie dane były wkładane na stos? ) i na końcu typ okna, w naszym przypadku okno informacyjne. Na uwagę zasługuje jeszcze ostatnia wartość – 0×26 czyli w reprezentacji ASCII znak & – warunek stopu pętli kopiującej dane do bufora.

Oczywiście zaprezentowany w tym przykładzie kod nie robi nic groźnego, jedynie wyświetla okienko. Jednak mając więcej miejsca na stosie można spreparować naprawdę groźną funkcję. Ale to już temat na kolejny wpis …

Kilka wyjaśnień

Wykorzystywane w przykładowym kodzie exploita adresy zostały wcześniej odkryte poprzez analizę kodu działającego programu za pomocą debuggera. Architektura systemu Windows (no może z wyjątkiem Visty i dalszych) powoduje, że w tym samym środowisku (te same zainstalowane programy) wykonujący się program zawsze będzie posiadał te same adresy funkcji oraz stosu. Dzięki temu w środowisku testowym można je poznać … i wykorzystywać do ataku na inne identyczne lub podobne (patrz poduszeczkę NOP) systemy. Analogicznie ma się sprawa z adresem wykorzystywanej funkcji MessageBoxA.

Wykorzystanie podatności wstrzyknięcia (ang. Injection Flaw) jest częstą przyczyną włamań do aplikacji internetowych. Problemy związane z bezpieczeństwem aplikacji dotyczące wstrzyknięcia niepoprawnych danych na stronach z polami testowymi są powszechne (w szczególności ataki typu Cross Site Scripting, XSS). Jednak możliwość wykorzystania podatności wstrzyknięcia na stronach bez pól tekstowych nie jest już tak oczywista.

Injection Flaw

Rozpatrzmy prostą funkcjonalność aplikacji obsługującej sklep internetowy, służącą do przedstawienia statusu złożonych zamówień. Przykładowy wygląd takiej aplikacji przedstawiony jest na rysunku 1.

Jak można przypuszczać, informacja uzyskana od użytkownika, związana z wyborem interesującego statusu przesyłki służy do sparametryzowania zapytania SQL do bazy danych. Z dużym prawdopodobieństwem można założyć, że wykorzystane zapytanie SQL będzie zbliżone do zapytania w następującej postaci:

SELECT id, towar, adres FROM zamowienia WHERE klient_id = ...
and status = ...

Jeśli założy się, że programista aplikacji kleił ręcznie zapytanie oraz nie zapewnił walidacji dostarczanych danych, łatwo można się domyśleć jaki tekst trzeba umieścić w zapytaniu aby uzyskać informację o wszystkich zamówieniach.

Rozważyć można sytuację, kiedy zamiast spodziewanego identyfikatora statusu podstawiony zostanie fragment zapytania SQL postaci:

4 or 1=1

W takim przypadku warunek w zapytaniu będzie zawsze prawdziwy, co w efekcie spowoduje wyszukanie wszystkich rekordów z tabeli.

Ponieważ aplikacja wysyła dane użytkownika za pomocą metody GET, w wysyłanym URLu możemy zaobserwować wszystkie parametry. Wystarczy, że w odpowiednim miejscu zostanie wklejony spreparowany fragment danych a cały URL ponownie wysłany. Na rysunku 2 można zaobserwować wynik wykonania za pomocą zwykłej przeglądarki takiego złośliwego zapytania.

Jak można było się spodziewać, w wyniku tego zapytania została ujawniona cała zawartość tabeli. W tym przypadku poznano wszystkich adresatów do których sklep wysłał paczki. Jednak jeśli byłby to system bankowy i “dziurawa” funkcjonalność dotyczyłaby kodów jednorazowych – ujawnione zostałyby adresy, pod które zostały one wysłane. Jeśli w tablicy znajdowały by się adresy mailowe, to ich poznanie mogło by posłużyć do wysyłania SPAMu lub wiadomości związanych z phishingiem. Taki atak byłby o tyle groźny, że dotyczył rzeczywistych klientów danej organizacji.

W omawianym powyżej przykładzie aplikacja wykorzystywała do komunikacje metodę GET, więc atak można przeprowadzić nawet za pomocą przeglądarki. Jednak wykorzystanie metody POST, chociaż ukrywa część informacji przed zwykłym użytkownikiem oraz umożliwia szyfrowanie przesyłanych danych w przypadku protokołu HTTPS, nie jest zabezpieczeniem (patrz paradygmat security by obscurity). W takim przypadku pomocne może być narzędzie WebScarab. WebScarab jest specjalnym rodzajem serwera proxy. Każde żądanie przechodzące przez niego jest przechwytywane i może zostać dowolnie zmodyfikowane. Program ten jest często wykorzystywany przy testach bezpieczeństwa aplikacji webowych.

Jak przeprowadzić atak wykorzystując program WebScarab

Pierwszym krokiem jest ustawienie proxy w używanej przeglądarce na adres wykorzystywany przez program WebScarab (standardowo nasłuchuje na porcie 8008). Następnym krokiem jest wejście na stronę, której ewentualne podatności chcemy sprawdzić. Podczas wywołania zapytania zostanie ono przechwycone i zaprezentowane użytkownikowi. W tym miejscu można dokonać dowolnych modyfikacji nagłówków a także danych przesyłanych za pomocą metody POST. Przykład takiej modyfikacji dobrze znanym fragmentem zapytania SQL zaprezentowany jest na rysunku 3.

Efekt przeprowadzonych działań widoczny jest na rysunku 4.

Zgodnie z oczekiwaniami po zatwierdzeniu zmiany dokonanej w programie WebScarab uzyskany zostaje dostęp do wszystkich danych znajdujących się w tabeli.

Podsumowanie

Jak można zabezpieczyć się przed tego typu atakiem

• Nie kleić ręcznie zapytań, zamiast tego skorzystać ze specjalnych funkcji lub obiektów służących do tego (ale nie zawsze się da, np. zapytanie XPath). Dla przykładu, w JDBC mamy do dospozycji PreparedStatement:

  . . .
  PreparedStatement ps;
  c = ds.getConnection();
  ps = c.prepareStatement("SELECT id, towar, adres FROM zamowienia
     WHERE klient_id = ? and status = ?");
  ps.setString(1, klient_id);
  ps.setString(2, status);
  ps.execute();
  . . .
  

• Nie ufać w żadne dane wysłane od klienta, zawsze dokonywać walidacji albo choćby procesu escapowania danych

  . . .
  
  try {
     Integer val = null;
     val = val.parseInt(request.getParameter("status"));
     if (val <= 0 || val > 4)
        throw new NumberValidationException(); //własna klasa wyjątku
     . . .
  } catch(NumberFormatException ex) {
     out.println("Parameter problem, try once again");
  } catch(NumberValidationException ex) {
     out.println("Parameter problem, try once again");
  } catch(...) ...
  

]]> http://blog.sages.com.pl/2010/03/atak-wstrzykniecia-na-stronach-bez-pol-tekstowych/feed/ 0