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

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

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

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.

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.

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)

Vielzahl von (automatischen) SQL Injection Tools existiert

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

2. (Meta-)Daten Erheben

3. Daten extrahieren

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

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

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

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

Was kann man gegen SQL Injection-Angriffe unternehmen?

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

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.

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.

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;

Typischer SQL Injection Angriff II http://myserver:8889/reports/rwservlet?report=sqlinject3.rdf+use rid=scott/tiger@ora9206+destype=cache+desformat=html

Typischer SQL Injection Angriff III

Typischer SQL Injection Angriff IV

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.

Typischer SQL Injection Angriff VI

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

SQL Injection Fehler Codes Oracle - II Fehlernr Fehlermeldung Auslöser ORA-01742 comment not properly terminated inline comment, e.g optimizer hint is not properly terminated ORA-01756 quoted not properly terminated single quote not properly ORA-01789 ORA-01790 ORA-24247 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-29257 Host %S unknown Attempted SQL Injection via utl_inaddr ORA-29540 Class does not exist Attempted utl_inaddr attempt but Java is not installed ORA-31011 XML parsing failed SQL Injection attempt via xmltype ORA-19202 Error occurred in XML processing SQL Injection via extractvalue

Oracle Error Sample code Download Code: http://www.red-database-security.com/bsi/sqlinjection.zip

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

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 -- 1. Angriff mitloggen -- 2. Email an Verantwortlichen versenden (DBA/MoD) -- send_email (e.g. via utl_smtp ) -- 3. Benutzer sperren execute immediate ('ALTER USER /* Error_Trigger */ "' sys_context('userenv','session_user') '" account lock'); -- 4. 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; /

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

Weitere Wege, um SQL Injektion Angriffe zu erkennen

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

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

F & A?

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