Author Archive

DOAG Präsentation – Best of Oracle Security 2007

Mittwoch, November 28th, 2007

Ich habe gerade einige Präsentationen zum Thema DOAG 2007 – „Best of Oracle Security 2007“ (dt). und Deepsec 2007 – „Retrieving Sensitive Information from Oracle Databases“ (engl.) hochgeladen.

Eine Liste unserer Präsentationen finden Sie hier.

Vertragsunterzeichnung mit Red Database Security auf der DOAG

Mittwoch, November 28th, 2007

Vertragsunterzeichnung mit Red Database Security auf der DOAG

RDS - Opitz Vertrag

Bernhard Opitz, OPITZ CONSULTING mit Alexander Kornbrust, Red Database Security Mit Unterschrift und Händedruck besiegelten Bernhard Opitz, Geschäftsführung OPITZ CONSULTING und Alexander Kornbrust, Geschäftsführer Red Database Security die neue Partnerschaft: Im offiziellen Rahmen der 20. Deutsche ORACLE-Anwenderkonferenz in Nürnberg wurde der Kooperationsvertrag unterschrieben. In dem mehrere Seiten umfassenden Dokument sind die Bereiche der Zusammenarbeit und die jeweiligen Zuständigkeiten detailliert beschrieben und festgelegt worden.

Zukünftig wird es in enger Zusammenarbeit beider Unternehmen folgende Angebote für unsere Kunden geben:

* CPU-Review: Ergänzend zum vierteljährlich erscheinenden Critical Patch Update von Oracle werden die enthaltenen Fixes bewertet und kommentiert. CPU-Review wird als elektronisches Abonnement angeboten.
* Schulungen im Bereich „Oracle Security“ für Datenbankadministratoren, Software-Entwickler und das Management
* Durchführung von Tool-gestützten Security-Checks

Über unseren neuen Partner:
OPITZ CONSULTING wurde 1990 als Gesellschaft für Organisationsberatung und Projektabwicklung gegründet. Das Unternehmen verfügt heute über eine Zentrale in Gummersbach und Niederlassungen in Bad Homburg, Gummersbach, Hamburg und München. Die Gründer hatten die Vorstellung, Organisationsberatung und Durchführung von IT-Projekten aus einer Hand anzubieten – beginnend mit der Geschäftsprozessanalyse über die Realisierungskonzeption und anschließende Realisierung bis hin zur Betreuung der Lösungen während des gesamten Lifecycles. Somit ein ganzheitlicher Ansatz, für den der Slogan „Solution Engineering for your Business“ geprägt wurde.

D.o.S. Exploit für Oracle 10.2.0.1/10.2.0.2 auf Bugtraq veröffentlicht

Samstag, November 3rd, 2007

Gestern hat ein anonymer Poster (oraclefun@hushmail.com) einen Exploit für XDB_PITRIG_PKG.PITRIG_DROPMETADATA in Oracle 10.2.0.1/10.2.0.2 auf der Sicherheits Mailingliste Buqtraq veröffentlicht, ohne jedoch Erklärungen über betroffene Versionen zu veröffentlichen. Nach einigen Tests gegen verschiedene Datenbank-Versionen habe ich herausgefunden, dass nicht gepatchte Oracle 10.2.0.1 und 10.2.0.2 Datenbanken sofort abstürzen.

Um diesen Exploit laufen zu lassen sind lediglich „Create Session“-Privilegien notwendig. 10.2.0.3 ist nicht davon betroffen.

Erwähnenswert ist weiterhin, dass dieser Exploit IDS Evasion Techniken verwendet und damit viele der üblichen netzwerkbasierten IDS Systeme austrickst.

Oracle 9i Rel. 1, 9i Rel. 2, 10g Rel.1 und 11g sind ebenfalls nicht betroffen und werfen Fehlermeldungen.
######### 9.2.0.8 , 10.1.0.5 #########
ERROR at line 22:
ORA-06550: line 22, column 1:
PLS-00201: identifier ‚XDB.XDB_PITRIG_PKG‘ must be declared
ORA-06550: line 22, column 1:
PL/SQL: Statement ignored
#########

######### 10.2.0.3 or 11g #########
ERROR at line 1:
ORA-29329: Table not of type XMLType
ORA-06512: at „XDB.XDB_PITRIG_PKG“, line 127
ORA-06512: at line 22
#########

Joxean Koret über Oracle Database Vault: Design Failures

Montag, Oktober 29th, 2007

Joxean Koret hat ein Whitepaper zum Thema Design Fehler in Oracle Database Vault veröffentlicht.

Joxean erklärt verschiedene Möglichkeiten, Oracle Database Vault (DBV) auf Betriebssystemebene / Dateisystemebene (export, modifzierte Bibliotheken) zu umgehen und sieht dies als Design Fehler von DBV. Meines Wissens war es nie ein Ziel von DBV, die Datenbank von OS-Ebene zu schützen, auch wenn das manchmal von Oracle Sales anders verkauft wird.

DBV ist ein Framework, mit dem man zusammen mit Komponenten wie TDE, ASO, …, ein sichereres Datenbank System aufbauen kann. Dazu muss natürlich die gesamte Architektur wie z.B. Backup/Recovery, Anwendungen mit betrachtet werden.

Inguma – Freies Oracle Penetration Toolkit von Joxean Koret

Samstag, Oktober 20th, 2007

Ich bin gerade zurück von der kleinen, aber feinen Security Konferenz 0sec in Bern, auf der ich zu dem Thema „Latest Trends in Oracle Security“ gesprochen habe.

Joxean Koret hat die Version 0.05 seines freien Penetration Toolkit  „Inguma“ veröffentlicht. Der Name Inguma kommt von dem baskischen Gott der Träume. Wer da wohl schon träumen soll… DBA’s sicherlich nicht…

Inguma, geschrieben in Phython, unterstützt verschiedene Systeme (z.B.. Oracle, SQL Server, SSH, Firewalls, …). Die folgenden Features von Inguma sind Oracle spezifisch:

* Exploit für die Lücke in SYS.LT.FINDRICSET (Oracle CPU Okt. 2007).
* Modul „bruteora“ hinzugefügt, um Oracle Server zu bruteforcen.
* Tool, um MD5 Hashes via Rainbow-Tables zu knacken.
* Modul „sidguess“, um die SID einer Oracle Datenbank zu erraten.
* Password Cracker für Oracle11g.
* Erweiterung des bisherigen Oracle PL/SQL Fuzzer.

Hier ist ein Screenshot von Inguma unter Backtrack 2.

Inguma Screenshot 1

Gut gemacht Joxean.

Oracle CPU Oktober 2007 – 14 Fehler von Red-Database-Security gefixt (updated)

Dienstag, Oktober 16th, 2007

Oracle hat gerade den Critical Patch Update für Oktober veröffentlicht. Es wurden insgesamt 51 Fehler in verschiedenen Produkten korrigiert. In der Datenbank werden insgesamt 27 Lücken beseitigt.

14 der Fehler wurden von Red-Database-Security gemeldet. Wie üblich sind die Fehler von den üblichen Verdächtigungen (David, Esteban, Joxean und mir). Aus Österreich hat Johannes Greil Fehler gemeldet. Johannes hatte schon 2005 Fehler in Oracle Portal gemeldet.

Oracle korrigiert insgesamt 11 Fehler im Workspace Manager, 3 in Oracle Text und 3 in Oracle Spatial. Weiterhin werden Fehler in Advanced Queueing, XMLDB, OID und ASO) korrigiert. Auch gibt es 2 Fehler in Import/Export. Der Import Fehler (von mir letztes Jahr gemeldet) ist der kritischste Fehler mit einen Rating von 6.5 (CVSS 2.0 rating) und betrifft alle Versionen von Oracle. Einige von unseren Fehler (Database Vault (DB21) und Enterprise Manager (EM01)) sind remote ohne Benutzerkennung ausnutzbar.

Die Fehler in der Datenbank (AFAIK) sind SQL Injection (Workspace Manager, Spatial), Buffer Overflows, Privilegien Eskalation.

Interessant ist auch, dass Joxean Koret zumindestens einen seiner Fehler an Tipping Point verkauft hat („Joxean Koret working with Tipping Point’s Zero Day Initiative“). Für diejenigen, die Tipping Point nicht kennen:

Tipping Point ist ein Hersteller von IDS/IPS Systemen, die Sicherheitslücken in bekannteren Produkten (Oracle, MS, SAP, …) aufkaufen und diese dann, bevor die Patches erhältlich sind, in ihr IDS/IPS integrieren. Ein großer Schutz ist jedoch nicht zu erwarten, wenn 95% der Fehler nicht entdeckt werden….

Mehr Details bald.

SYSDBA Backdoor

Montag, Oktober 15th, 2007

Paul Wright hat ein Whitepaper „Oracle SYSDBA Backdoor“ veröffentlicht. Dort zeigt Paul, wie man einen neu angelegten SYSDBA Account so versteckt, dass er nicht mehr in den Oracle Standardviews angezeigt wird. Dazu ist es zwar notwendig, in der Oracle Binärdatei die  View GV$PWFILE zu patchen. Sobald dies aber getan ist, wird nach dem Neustart der Datenbank der bisher angezeigte SYSDBA Account nicht mehr in der View v$pwfile_users angezeigt. Lediglich die View X$KZSRT, die jedoch nur als SYSDBA verwendet werden kann, zeigt noch den versteckten Benutzer.

Paul verwendet hier einige der Ideen (View verändern, Binärdatei patchen), die ich letztes Jahr auf der BlackHat 2006 in meinem Vortrag „Oracle Rootkits 2.0“ gezeigt habe. Die Idee SYSDBA Benutzer zu verstecken ist sehr interessant. Das größte Problem ist wahrscheinlich das Patchen der Binärdateien, da das Herunterfahren einer Produktionsdatenbank recht auffällig ist.

Paul empfiehlt (wie ich bereits letztes Jahr) in kritischen Umgebungen Checksummen-Programme wie Tripwire, um Änderungen auf Betriebssystemebene anzuzeigen.

Pete empfiehlt den Parameter „remote_login_passwordfile = NONE“ zu setzen, was oftmals jedoch nicht möglich ist. Den wohl einfachsten Test, welche SYSDBA Benutzer existieren bzw. ob bereits solch eine Hintertür installiert ist, kann man unter Unix mit dem strings Kommando machen:

Oracle Oracle Password File

Interessant ist hierbei noch, dass der Benutzer INTERNAL auf in Oracle 11g immer noch existiert. Offiziel war dieser ja mit Oracle 9i „verschwunden“.

Oracle CPU Oktober 2007 – Vorankündigung

Sonntag, Oktober 14th, 2007

Nächste Woche Dienstag ist es wieder so weit. Oracle veröffentlicht den letzten Oracle CPU Oktober 2007 in diesem Jahr. Diesmal werden insgesamt 51 Sicherheitsfehler in den verschiedenen Oracle Produkten korrigiert. Davon betreffen 27 der 51 Fehler die Oracle Datenbank. 5 davon sind remote ausnutzbar, aber zumindestens unsere Findings nicht besonders kritisch.

Am Freitag hat Oracle uns bereits mitgeteilt, dass diesmal (wahrscheinlich) 14 unserer Fehler in der Datenbank korrigiert werden, darunter auch einige die Remote ausnutzbar sind. Damit sind mehr als 50% aller gemeldeten Fehler in der DB von Red-Database-Security gefunden worden. Auch einer der Fehler von uns in Database Vault wird korrigiert.

Mehr Informationen gibt es nach der Analyse bzw. auf den beiden Seminaren der Oracle University : „Hacking für Oracle DBA’s

Sicherheitslücken in Oracle Database Vault

Donnerstag, Oktober 4th, 2007

Sven Vetter schreibt in seinem Technik-Blog, dass es per dynamischen SQL sehr einfach möglich sei, Database Vault auszutricksen. Das wundert mich nicht, da wir schon vor Monaten Sicherheitslücken in Database Vault an Oracle secalert gemeldet haben. Nachträglich solch ein Konzept einzuführen, ist natürlich nicht einfach und vor allem nie fehlerfrei. Die aktuelle Version dient wohl eher dazu, Know-How aufzubauen und vor allem die internen Prozesse, wie z.B. die DBAs arbeiten, an das Produkt anzupassen.

Vielleicht erfahren wir von Sven seinem Vortrag auf der DOAG mehr über diese Lücken.

Weiterhin schreibt Sven, dass „Es sind zu viele Security Lücken vorhanden, die das Lesen und Ändern von vertraulichen Daten als Datenbank- oder Betriebssystemadministrator zulassen – genau das aber verspricht dieses Produkt zu unterbinden„.
Dies ist so nicht richtig. Oracle schreibt dazu: „Oracle Database Vault can prevent highly privileged users, including powerful application DBAs and others, from accessing sensitive applications and data in Oracle databases outside their authorized responsibilities„. Oracle spricht nicht von Betriebssystemadministratoren.

Database Vault wurde NUR dazu entworfen, einen Benutzer mit DBA Berechtigungen OHNE Betriebssystemzugriff (direkt bzw. indirekt (z.B. dbms_scheduler)) einzuschränken (z.B. select any table oder Passwort Änderungen). Sobald man Betriebssystemzugriff (erlangt) hat, ist es trivial, Database Vault auszutricksen/ zu umgehen, da man beispielsweise als Betriebssystembenutzer Database Vault einfach ausschalten kann (wird für das Einspielen der CPUs benötigt). Dies ist aber keine Lücke, sondern Teil der Architektur von Database Vault.

Oracle SQL Injection Cheat Sheet

Dienstag, Oktober 2nd, 2007

Die folgende Url enthält ein cheat sheet für Oracle SQL Injection. Nicht vollständig , einige statements sind zu kompliziert. (z.B. SELECT table_name FROM all_tables WHERE TABLESPACE_NAME=’USERS‘ or SELECT username, FROM all_users UNION SELECT name, password FROM sys.user$, better: SELECT name, password FROM sys.user$ where type#=1).