Sanftes Härten

Sanftes Härten
Inhalt
¡  Einführung
¡  Beispiele
¡  Zusammenfassung
Einführung
Das Härten von Datenbanken ist sehr einfach.
Sie müssen nur ein paar wenige schwache Passworte
ändern, Public Privilegien entfernen, Einstellungen
ändern, Password Alterung einführen, Password
Verfication Functions verwenden, ….
… und schon laufen einige oder viele Ihrer
existierenden Datenbank nicht mehr….
Was sind die Ursachen?
Ursachen!
Anwendungen werden in der Regel ohne Kenntnis
von (speziellen) Härtungsmaßnahmen erstellt und
getestet.
Seiteneffekte können ohne genauere Analyse nicht
vorhergesagt werden.
Auditoren „übertreiben“ oft, z.B. alle ALL_% views von
PUBLIC entfernen (ALL_USERS, ALL_TABLES,
ALL_SOURCE, …)
Beispiel 1a
Oracle Password Verification Function:
Bei einem schwachen Password (z.B.
Password='ORACLE') liefert z.B. Oracle Beispielfunktion
die Fehlermeldung ORA-20006.
Beispiel 1b
Woher soll eine 3rd-party Anwendung die nicht standardisierten
Fehlercodes
¡ 
ORA-20001
¡ 
ORA-20002
¡ 
ORA-20003
¡ 
ORA-20004
¡ 
ORA-20005
¡ 
ORA-20006
¡ 
ORA-20007
¡ 
ORA-20008
¡ 
ORA-20009
¡ 
ORA-20011
kennen.
Beispiel 1c
Was soll die Anwendung machen, wenn vom Benutzer
ein schwaches Passwort eingegeben wurde?
Woher soll der Anwender wissen, dass das Passwort
abgelehnt wurde, wenn die Anwendung keine
Rückmeldung liefert?
Beispiel 2a
Der größte Teil der Oracle Datenbanken enthält (zumindest
einige) schwache Passworte (Default, PW=Username, InitialPassworte, Firmenspezifisch, Wörterbuch).
Diese schwachen Passworte sind mit Hilfe von Tools (bzw. z.T.
mit Skripten) sehr leicht zu finden. Die Korrektur dauert oft
Jahre, da niemand genau weiß, wer und wo diese
Passworte verwendet werden.
Einfaches Ändern führt nahezu garantiert zu Problemen mit
Anwendungen oder Benutzern.
Neue vs. Altsysteme
Die meisten Härtungsmaßnahmen (Privilegien
entfernen, Passworte, Profile, ...) sind nur bei neuen
Systemen „relativ“ einfach einzusetzen,
Für Altsysteme sind diese wegen schwer
vorhersagbarer Seiteneffekte oft nicht einsetzbar.
Um dieses Risiko für Altsysteme zu minimieren, sind
andere Ansätze (Mitigation/Linderung) sinnvoll.
Sanftes Härten
Folgende Grundsätze gibt
es beim sanften Härten
¡  Es sollte die bestmöglichste Lösung verwendet
werden, die ohne (große) Probleme einsetzbar ist
¡  1. Korrektur des Problems (Fix)
¡  2. Linderung (Mitigation)
¡  3. Monitoren/Auditing des Problems
¡  Oftmals gibt es 3rd-Party-Lösungen, die das
Problem lindern können (z.B. McAfee Database
Activity Monitoring)
Beispiel - Oracle Version
Beste Lösung:
Supportete Version (11.2.0.3) + Letzter Patch (Okt. 2012)
• 
Schlechteste Lösung:
Unsupportete Oracle Version
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
• 
• 
Ein Patchset korrigiert viele (+zukünftige) Sicherheitsfehler (z.B.
Authentication Problem/Stealth PW Cracking), ohne dass dies von
Oracle so beschrieben wurde.
McAfee Virtual Patching erlaubt den Schutz von Datenbanken ohne
Downtime (und bei alten Versionen)
Individuelle Workarounds (z.B. SQLNET.ALLOWED_LOGON_ VERSION)
können das Risiko minimieren
Beispiel - Oracle Version
Beispiel – Password Verification
Oracle APEX:
Bei der Installation von APEX generiert Oracle ein zufälliges Passwort.
Dieses ist aber in der Regel nicht komplex nicht.
Wenn eine Passwort Verification Function existiert, klappt die Anlage des
Benutzers nicht, und die Objekte von APEX werden in das SYS Schema
installiert.
• 
Empfehlung:
• 
• 
• 
Verschiedene Profile für verschiedene Oracle Gruppen (ORACLE,
DBA, TECHNICAL, ENDUSER)
Das Default-Profile sollten KEINE PW Verify Funktion verwenden, und
ein Passwort Alter von 1 Tag haben.
Beispiel – Password Verification
Beste Lösung:
Password Verification Function mit der Implementierung der Firmen/
Organisationsrichtlinie
• 
Schlechteste Lösung:
Keine Password Verification Function
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
• 
• 
Anstatt die eigene PW Verification Function zu verwenden wie die
Beispiel-Oracle-Funktion verwendet.
Anstatt schwache Passworte ablzulehnen, werden diese
mitdokumentiert. Ein Report gibt dann aus, wer gegen welche
Passwort Regel verstößt (zu kurz, zu wenig komplex, ...)
Viele Passworf Richtlinien sind nicht implementierbar.
Beispiel – Password Verification
• 
Andere Lösung:
DDL Trigger kann die Länge des Passwortes feststellen, indem die
Anzahl der * gezählt wird.
Beispiel – Password Verification Function
Beispiel – Public Privileges
• 
• 
• 
Gefährlichen Packages werden bei Angriffen oft als Hilfsfunktion
verwendet (z.B. utl_http, dbms_sql, ...).
Das Einschränken von Public-Privilegien reduziert das Risiko eines
erfolgreichen Angriffes.
Viele Anwendungen verwenden diese Packages jedoch, um
spezielle Funktionalitäten abzubilden (z.b. Börsenkurse abholen,
Emails versenden)
• 
Das Entfernen von Public Privilegien führt oft zu ungültigen
Packages (vorher DBA_DEPENDENCIES kontrollieren)
Beispiel – Public Privileges
Gefährliche Packages die an PUBLIC gegranted sind:
• 
• 
DBMS_ADVISOR
• 
DBMS_SQL
• 
DBMS_CRYPTO
• 
DBMS_XMLGEN
• 
DBMS_JAVA
• 
DBMS_XMLQUERY
• 
UTL_FILE
• 
UTL_INADDR
• 
UTL_TCP
• 
UTL_MAIL
• 
UTL_SMTP
• 
UTL_DBWS
• 
UTL_ORAMTS
• 
DBMS_JAVA_TEST
• 
DBMS_JOB
• 
DBMS_LDAP
• 
DBMS_LOB
• 
DBMS_OBFUSCATION_T
OOLKIT
• 
DBMS_RANDOM
• 
UTL_HTTP
• 
DBMS_SCHEDULER
• 
HTTPURITYPE
Beispiel – Public Privileges
Beste Lösung:
Alle gefährlichen Packages von Public entziehen und nach Patches kontrollieren,
ob diese noch entzogen sind (Oracle granted vor dem Patchen einige dieser
Packages wieder an Public)
• 
Schlechteste Lösung:
Nichts machen...
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
• 
• 
• 
3rd-party-Lösungen, können bei der ungewöhnlichen Verwendung von
Packages den zuständigen Mitarbeiter alarmieren
Audit Execute von gefährlichen Packages.
Schützen der Packages (ACLs für Netzwerk, Directory Objekte für dbms_lob/
utl_file)
Analyse der View gv$db_object_cache, zeigt Packages an, die gefährlich sind
Beispiel – Public Privileges
Beispiel – Schwache Passworte
Die meisten Datenbanken haben Kennungen mit schwachen
Passworten
• 
• 
Default-Passwort (OUTLN/OUTLN, PERFSTAT/PERFSTAT)
• 
Passwort=Benutzername
• 
Passwort=Permutation des Benutzernamens (ORACLE/ELCARO
• 
Initial-Passwort (WEBER/START123, SCHMIDT/WELCOME1)
• 
Firmenbegriffe (Produktname, Markenname, ...)
• 
Worte aus einem Wörterbuch (z.B. Schauspieler, Länder, Autos, ...)
• 
Zu kurze Passworte (<10 Zeichen)
Beispiel – Schwache Passworte
Für die unterschiedlichen Gruppen gibt es unterschiedliche
Lösungsansätze
• 
Oracle-Kennungen (OUTLN, DBSNMP, PERFSTAT, SCOTT, ...)
• 
• 
Demo-Benutzer löschen
• 
Nicht benötigte Oracle-Kennungen sperren (z.B. Outln, Perfstat)
Endbenutzer (ADMWEBER, SCHMIDT AKURZ1, ...)
• 
• 
Expiration der End-Anwender Kennungen mit schwachen
Passworten
Technische Benutzer (GRIPS, MYAPP, WEBUSER, ...)
• 
• 
Analysieren welcher technische Benutzer von welchen System/
Programmen verwendet wird. Ändern oder falls nicht möglich mit
Logon-Trigger/Überwachung schützen
Beispiel – Schwache Passworte
Anzeige, welche Programme mit welcher Kennung von welcher
Maschine verwendet werden:
------select
program, username, machine, count(*) as cnt
from sys.wrh$_active_session_history w, dba_users d
where w.user_id=d.user_id (+)
and (lower(program) not like '%oracle%(%)%')
group by program, username,machine
-------
Beispiel – Schwache Passworte
Beste Lösung:
Starke Passworte verwenden und regelmäßig ändern
• 
Schlechteste Lösung:
Aus Angst vor Problemen nichts machen
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
• 
• 
• 
Logon-Trigger, der nur Zugriffe von bestimmten IPs/Programmen
zulässt und alles andere blockt
Logon-Trigger, der nur Zugriffe von bestimmten IPs/Programmen
zulässt und ansonsten eine Nachricht verschickt (SIEM, SMS, Email, ...)
McAfee Virtual Patching erlaubt den Schutz eines Logon-Triggers,
ohne die Datenbank zu verändern
Alle Create Sessions mitauditieren
Beispiel – Weak Passwords
Beispiel – .bash_history
• 
• 
• 
Die .bash_history-Datei enthält oft Klartext-Passworte (z.B. sqlplus,
exp, ...) und Hinweise, welche Programme vom DBA verwendet
wurden.
Diese Datei gehört dem Oracle-Benutzer und kann mit Hilfe von
Funktionen wie dbms_lob, utl_file, Java, externen Tabellen, ...
gelesen werden.
Ein häufiger Angriffspunkt, um auf andere Systeme
„weiterzuspringen“, da Passworte meistens über alle Datenbanken
identisch sind.
Beispiel – .bash_history
Beste Lösung:
Keine .bash_history (und andere History-Dateien) zulassen
• 
Schlechteste Lösung:
Keine Änderung
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
.bash_history mittels eines Jobs regelmäßig bereinigen
• 
.bash_history nur für eine Session gültig lassen (darf nicht
zurückgeschrieben werden)
Beispiel – .bash_history
Beispiel – Unsicherer PL/SQL Code
• 
• 
• 
Kleinere Probleme (< 20 Findings) lassen sich meistens recht einfach
vom entsprechenden Entwickler beheben (sofern dieser noch
„greifbar“ ist)
Größere oder große Fehlermengen (z.B. 1000+) erfordern eine
strategischeres Vorgehen. So können die Fehler z.B. gewichtet und
gemäß des Gewichtes der Lücke abgearbeitet werden.
Ist eine Korrektur nicht zeitnah möglich, sollte man sich über
Workaround bzw. Monitoring/Auditing bzw. 3rd-party-Lösungen
Gedanken machen
33
Exploiting / Formula
Objecttype
OwnerPrivs
Retcode
Authid
Function/
Pack.Func
100
SYSDBA 10
Bool 0.1
Definer 1
Public
Procedure
10
DBA
Out
0.2
Invoker 0
Role
2
Else
1
User
1.5
Trigger
5
9
Resource 5
Nothing
3
Grants
5
Nothing 1
Formula:
Exploitability := objecttype * ownerPrivs * retcode * authid * grants
Sample: SYS has a vulnerable function granted to public which returns an integer
Exploitability := 100 * 10 * 1 * 1 * 5 = 5000
Sample: SYS has a vulnerable function with invokers rights granted to public which returns an integer
Exploitability := 100 * 10 * 1 * 0 * 5 = 0
Beispiel – Unsicherer PL/SQL Code
Beste Lösung:
Nur sicheren PL/SQL Code zulassen
• 
Schlechteste Lösung:
Keine Absicherung des PL/SQL-Codes
• 
Auch hier gibt es verschiedene Möglichkeiten:
• 
• 
• 
• 
Nur den kritischsten Code (Owner hat DBA-Rechte, Funktion an
Public gegranted).
McAfee Database Activity Monitoring erlaubt die Erkennung von
typischen SQL Injection Angriffen (Privilegieneskalation)
Entfernen von typischen SQL Injection Hilfsfunktionen wie
dbms_sql oder dbms_xmlquery
Beispiel dbms_xmlquery
http://soonerorlater.hu/index.khtml?article_id=517
Beispiel – unsecure PL/SQL Code
Beispiel – ALTER USER
• 
• 
• 
Viele Anwendungen fordern zu viele Privilegien.
Oftmals wird, wenn wegen des Benutzermanagements Passworte
zu ändern sind, DBA-Rechte verlangt.
Dabei werden eigentlich nur ALTER USER (und vielleicht CREATE/
DROP USER) benötigt.
• 
Diese Kennungen können jedoch auch die Passworte von SystemKennungen wie SYS/SYSTEM ändern.
Beispiel – ALTER USER
Beste Lösung:
Selbst geschriebene Prozedur, die nur Änderungen an bestimmten
Kennungen zulässt.
• 
Schlechteste Lösung:
grant DBA to username
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
Ein Before-DDL-Trigger, der das Event „ALTER USER“ überwacht
und nur Änderungen an bestimmten Benutzern (z.B. nicht SYSTEM)
zulässt (Achtung!!! „Grant connect to scott identified by
pwd“ nicht vergessen).
• 
Die Zugriffe können überwacht werden(intern/3rd-party)
Beispiel – User braucht ALTER USER
Beispiel – TNS Listener
• 
• 
• 
TNS Poisoning ist aktuell das schwerwiegenste Problem, das in
Oracle Datenbanken existiert.
Ein Angreifer ohne Authentifizierung kann beliebige Datenbanken
(seit Oracle 9) übernehmen, eigene Befehle absetzen, ...)
Seit Anfang Oktober gibt es entsprechende Metasploit/
Meterpreter-Module, die lediglich die Eingabe von IP/Port und SID
erwarten.
• 
Danach kann man alles mit der Datenbank machen (OS Befehle
ausführen, Alle Oracle-Passworte im Klartext mitprotokollieren, ...)
Beispiel – TNS Listener
Beste Lösung:
Verwendung von Listener IP Restriction und Implementierung der
Oracle Workaround (DocID: ID 1453883.1 )
• 
Schlechteste Lösung:
Nichts tun
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
Dynamic Registration deaktivieren
• 
IP Restriction verwenden
• 
Monitoring des Events „Register Listener“ im Listener.log
• 
Monitoring von „Remote Listenern“ mittlels lsnrctl status
Beispiel – TNS Listener
Design-Vorgabe
• 
System muss in der Lage sein, Angriffe von außen zu
erkennen
• 
System muss darauf entsprechend reagieren können
• 
Mechanismus muss schnell (im Fehlerfall) deaktiviert
werden können
Beispiel – Execute OS via Java
Beste Lösung:
Kein Java verwenden, da die von Java gestarteten Prozesse im
Oracle Kontext ausgeführt werden. Stattdessen dbms_scheduler
verwenden (läuft als Benutzer nobody anstatt Oracle)
• 
Schlechteste Lösung:
JAVASYSPRIV an den Benutzer granten
• 
Dazwischen gibt es einige Abstufungen:
• 
• 
Anstatt dem Benutzer zu erlauben, beliebige Befehle auszuführen,
kann dies in Java feingranular verteilt werden.
• 
Die Zugriffe können überwacht werden(intern/3rd-party)
Beispiel – Execute OS via Java
Zusammenfassung
• 
• 
• 
• 
• 
In fast allen Fällen existieren unterschiedliche
Möglichkeiten, die Datenbank zu härten.
Die beste Möglichkeit ist oftmals nicht einsetzbar.
Oracle biete viele Möglichkeiten (VPD, Trigger,
Auditing, ...), die für eine Linderung sorgen
3rd-party-Produkte erlauben es oft, Probleme
schneller/einfacher als mit Bordmitteln zu lösen
Wenn eine Lösung nicht möglich ist, kann man
immer noch den Zugriff überwachen
Fragen & Antworten?
Danke
¡  Kontakt:
Red-Database-Security GmbH
Bliesstr. 16
D-.66538 Neunkirchen
Germany