Erkennung von Datenbank-Angriffen über Webserver und

Erkennung von DatenbankAngriffen ü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)
¡
¡
Enumeration (Prio 2)
¡
¡
Mit Hilfe eines Error Triggers (Oracle) können für SQL Injection typische
Fehler (z.B. Quoted string not properly terminated) gefunden werden
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
invalid SQL statement
ORA-00906
missing left parenthesis
ORA-00907
missing right parenthesis
ORA-00911
invalid character
ORA-00917
missing comma
ORA-00920
invalid relational operator
ORA-00923
FROM keyword not found where expected
ORA-00933
SQL command not properly terminated
ORA-00970
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
e.g. PHP MAGIC_QUOTES_GPC
activated and attempt to
inject a single quote
Enumeration with rownum and
current rownum does not exist
SQL Injection Fehler Codes Oracle - II
Fehlernr
ORA-01742
Fehlermeldung
comment not properly terminated
ORA-01756
quoted not properly terminated
ORA-01789
query block has incorrect number of
result columns
expression must have same datatype
as corresponding
network access denied by access
control list
ORA-01790
ORA-24247
ORA-29257
Host %S unknown
ORA-29540
Class does not exist
ORA-31011
XML parsing failed
ORA-19202
Error occurred in XML processing
Auslöser
inline comment, e.g
optimizer hint is not properly
terminated
single quote not properly
terminated
Attempt to use UNION
SELECT
Attempt to use UNION
SELECT
Oracle ACL has blocked
the usage of UTL_INADDR
(or similar)
Attempted SQL Injection
via utl_inaddr
Attempted utl_inaddr
attempt but Java is not
installed
SQL Injection attempt via
xmltype
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-partyLö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