Erkennung von Datenbank- Angriffen über Webserver und automatische Gegenmaßnahmen (am Beispiel von einer Oracle RDBMS)

Transkript

1 Erkennung von Datenbank- Angriffen über Webserver und automatische Gegenmaßnahmen (am Beispiel von einer Oracle RDBMS)

2 Agenda Einführung Typischer Angriff auf einen Webserver Erkennung des SQL Injection Angriffes Gegenmaßnahmen Zusammenfassung

3 Einführung Webanwendungen werden regelmäßig aus dem Internet angegriffen (erfolgreich/nicht erfolgreich). Eine Vielzahl der Angreifer verwendet dabei automatisierte Werkzeuge, die oft nur geringes Wissen erfordern, aber dennoch extrem schnell durchgeführt werden können. Manuelle Angriffe sind normalerweise etwas langsamer, werden aber mit der identischen Strategie ausgeführt. Im Falle eines Angriffs mit Hilfe eines Werkzeugs können Daten in weniger als 2 Minuten aus der Datenbank extrahiert werden.

4 Einführung Die folgende Vorgehensweise wird am Beispiel einer Oracle Datenbank gezeigt. Das Konzept kann aber auch in anderen DB Derivaten wie MSSQL oder MySQL (mit Anpassungen) implementiert werden. Wichtig!!! Bei dem hier vorgestellten Konzept ist es NICHT notwendig, die Anwendung/Verfahren anzupassen, da die Lösung für die Anwendung transparent ist.

5 Typisches Vorgehen bei einem SQL Injection Web Angriff 1. Verwendung eines Tools (z.b. Havij, Netsparker, Matrixay, Pangolin, SQLMap, ), um eine gesamte Webseite zu scannen und SQL Injection Lücke zu finden (via Fehlermeldung) 2. Metadaten sammeln(tabellen, Spalten, Benutzer, ) 3. Tabelleninhalte extrahieren 4. (Privilegien eskalieren)

6 Vielzahl von (automatischen) SQL Injection Tools existiert

7 Beispiel 1. SQL Injektion Lücke finden und Exploit erstellen

8

9

10

11

12 2. (Meta-)Daten Erheben

13

14 3. Daten extrahieren

15

16

17 4. Privilegien eskalieren, Hintertüren einbauen, Entkommen auf das Betriebssystem,...

18 Und die Daten sind weg (bzw. kopiert)... (oft in weniger als 2 Minuten)

19 Kann auf einen solchen SQL Injektion Angriff realistisch innerhalb von 2 Minuten reagiert werden?

20 Jein! Zeit für menschliche Reaktion ist zu langsam Vorgehen bei einem Angriff in der Regel nicht vorab definiert Seiteneffekte auf andere Systeme möglich. Verantwortlicher Manager würde Datenbank nicht abschalten Automatische Reaktion auf den Angriff erlaubt sehr schnelle Reaktionszeiten

21 Was kann man gegen SQL Injection-Angriffe unternehmen?

22 Ansatz Ein SQL Injection Angriff besteht aus einer Vielzahl von unterschiedlichen Schritten (Finden einer SQL Injection, Enumeration, Daten abziehen, Privilegien Eskalation). Der Schutz vor diesen Angriffen besteht aus 2 Teilen 1. Erkennung der verschiedenen Stufen eines Angriffs 2. Entsprechende Gegenmaßnahmen, die automatisch ausgeführt werden

23 Erkennung (Schichten) Die Erkennung eines SQL Injection Angriffs kann auf unterschiedlichen Ebenen stattfinden. Während eine Web Application Firewall (WAF) bzw. der Webserver Angriffe architekturbedingt nur teilweise erkennen kann. Ist die Angriffserkennung in der Datenbank die sinnvollste Option, da man dort SQL Fehler abfangen und interpretieren kann. Dadurch wird die Anzahl der False-Positives fast auf 0 reduziert.

24 Erkennung von SQL Injection Angriffen Finden von SQL Injection Fehlern (Prio 1) Mit Hilfe eines Error Triggers (Oracle) können für SQL Injection typische Fehler (z.b. Quoted string not properly terminated) gefunden werden Enumeration (Prio 2) Nachdem eine Lücke gefunden und ein Exploit identifiziert wurde, werden nun interessante Daten gesucht. Dabei liest man bspw Tabellen oder Spaltennamen (password, creditcard,...) aus. Solch ein Zugriff wird normalerweise nicht von einer Application ausgeführt, kann aber überwacht werden (z.b. View ALL_TAB_COLUMNS mit Alarm-Funktion) Download Data (Prio 3) Mit sogenannten Honey oder Fake Tables (z.b. myusers) oder entsprechenden Funktionen kann das System erkennen, ob Daten abgezogen werden und auch hier reagieren.

25 Typischer SQL Injection Angriff I Original SQL Befehl select custname, custid, custorder from customer; Erweiterter SQL Befehl des Angreifers select custname, custid, custorder from customer union select username, null, null from all_users;

26 Typischer SQL Injection Angriff II

27 Typischer SQL Injection Angriff III

28 Typischer SQL Injection Angriff IV

29 Typischer SQL Injection Angriff V Typische Fehlermeldung: ERROR at line 1: ORA-01789: query block has incorrect number of result columns è Angreifer fügt so lange NULL Werte hinzu, bis ein korrektes SQL Statement erzeugt wird.

30 Typischer SQL Injection Angriff VI

31 SQL Injection Fehler Codes Oracle - I Error code Error Message Typical Command ORA ORA ORA invalid SQL statement missing left parenthesis missing right parenthesis ORA invalid character e.g. PHP MAGIC_QUOTES_GPC activated and attempt to inject a single quote ORA ORA ORA ORA ORA missing comma invalid relational operator FROM keyword not found where expected SQL command not properly terminated missing WITH keyword ORA insufficient privileges Attempted privilege escalation ORA divisor is equal to zero Blind SQL Injection attempt (e.g. sqlmap) ORA outer join operator not allowed in operand of OR or IN ORA invalid number Enumeration with rownum and current rownum does not exist

32 SQL Injection Fehler Codes Oracle - II Fehlernr Fehlermeldung Auslöser ORA comment not properly terminated inline comment, e.g optimizer hint is not properly terminated ORA quoted not properly terminated single quote not properly ORA ORA ORA query block has incorrect number of result columns expression must have same datatype as corresponding network access denied by access control list terminated Attempt to use UNION SELECT Attempt to use UNION SELECT Oracle ACL has blocked the usage of UTL_INADDR (or similar) ORA Host %S unknown Attempted SQL Injection via utl_inaddr ORA Class does not exist Attempted utl_inaddr attempt but Java is not installed ORA XML parsing failed SQL Injection attempt via xmltype ORA Error occurred in XML processing SQL Injection via extractvalue

33 Oracle Error Sample code Download Code:

34 CREATE OR REPLACE TRIGGER after_error AFTER SERVERERROR ON DATABASE DECLARE sql_text ORA_NAME_LIST_T; v_stmt CLOB; -- SQL statement causing the problem n NUMBER; -- number of junks for constructing the sql statement causing the error v_program VARCHAR2(64); v_serial number; v_sid number; BEGIN -- Version 1.00 select program,serial#,sid into v_program,v_serial,v_sid from v$session where sid=sys_context('userenv', 'SID'); -- construct the sql text n := ora_sql_txt(sql_text); -- IF n >= 1 THEN FOR i IN 1..n LOOP v_stmt := v_stmt sql_text(i); END LOOP; END IF; -- FOR n IN 1..ora_server_error_depth LOOP

35 IF (lower(v_program) = 'iis.exe') -- add your own application server and (ora_server_error(n) in ('942','900','906','907','911','917','920','923','933','970','1031','1476','1719','1722','1742','1756','17 89','1790','19202','24247','29257','29540','31011')) THEN -- Potential attack was detected Angriff mitloggen an Verantwortlichen versenden (DBA/MoD) -- send_ (e.g. via utl_smtp ) Benutzer sperren execute immediate ('ALTER USER /* Error_Trigger */ "' sys_context('userenv','session_user') '" account lock'); Session beenden execute immediate ('ALTER SYSTEM /* Error_Trigger */ KILL SESSION ''' v_sid ',' v_serial ''' account lock'); alter system kill session 'session-id,session-serial' END IF; END LOOP; -- END after_error; /

36 Was ist sinnvoll? Service nicht verfügbar oder Daten werden dupliziert und veröffentlicht

37 Weitere Wege, um SQL Injektion Angriffe zu erkennen

38 Weitere Möglichkeiten Fake-Tabellen (CREDITCARD) oder Fake-Funktionen (decrypt), deren Zugriff überwacht wird Anlage von eigenen Views (ALL_USERS, ALL_TAB_COLUMNS, ) im Schema der Datenbank, die falsche Daten zurückliefern Privilegien-Eskalation bzw. DDL Befehle vom Application Server Verwendung von bisher nicht genutzten Packages, via 3rd-party- Lösung Ungewöhnliche Fragmente in SQL Befehlen (or 1=1--), via 3rdparty-Lösung Whitelisting von SQL Befehlen auf kritische Tabellen (z.b. Zugriff auf Benutzer-Tabelle), via 3rd-party-Lösung

39 Zusammenfassung SQL Injection Angriffe aus dem Web können zuverlässig, d.h. mit Bordmitteln (=keine Lizenzkosten) erkannt werden, ohne dass die Anwendung angepasst werden muss 3rd-party-DB-Security-Lösungen erlauben zusätzlichen Schutz Schwierigstes Problem bleibt die Definition des Vorgehens bei der Erkennung eines Angriffes. Dies ist ein organisatorisches Problem. Dilemma: Anwendung/Service stoppen oder Daten verlieren

40 F & A?

41 Danke Kontakt: Red-Database-Security GmbH Eibenweg 42 D Heusenstamm Deutschland