| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | Jan » | |||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
Das Jahr 2007 neigt sich dem Ende, daher nur noch ein letztes Foto:
Gleich im neuen Jahr geht es weiter, ich danke allen treuen Lesern (und auch den untreuen), wünsche einen guten Rutsch ins neue Jahr und freue mich, auch 2008 diverse Themen in der IT-Security kommentieren zu können.
Die aufgelegten Folien will ich kommentarlos als Fotobeweis dokumentieren 🙂
Tim Pritlove hat dann zum Ende noch ein paar Statistiken geliefert:
Das war’s, nächstes Jahr, gleiche Zeit, gleicher Ort.
Alexander Kornbrust ist neben David Litchfield vermutlich der wichtigste Oracle Sicherheitsexperte den wir haben. Wenn von ihm ein Vortrag zu Oracle Security kommt, dann kann man eigentlich immer etwas wichtiges erwarten.
Zu Beginn gab es einen kurzen Abriss zu alten Lücken, insbesondere PL/SQL-Injecion-Fehler. Hier hat Oracle in den letzten Jahren über 1000 Fehler behoben und verwendet inzwischen einen Fortify-Sourcecode-Scanner um weitere Lücken zu erkennen. Das Spiel heißt jetzt nicht mehr „Hacker gegen Oracle“ sondern „Hacker gegen Fortify“. Dummerweise ist der PL/SQL-Code der nicht von Oracle ist weiterhin dramatisch schlecht da die Entwickler in den Unternehmen nur auf ihre Business-Logik achten und teilweise noch nie von SQL-Injection gehört haben. Eine einzige Lücke reicht einem Angreifer jedoch aus um die komplette Datenbank zu übernehmen.
Eie weitere Fehlerklasse hat David Litchfield auf der Black Hat DC 2007 vorgestellt, dort nutzte er eine Lücke im Cursor aus die jedoch inzwischen behoben ist. Der Hack zeigt jedoch, dass weiterhin mit Lücken zu rechnen ist und immer mehr Angriffe automatisiert werden.
Ein Thema mit dem sich Alexander als erster intensiv beschäftigt hat sind „Database Rootkits“. Dabei werden einzelne Einträge wie Benutzer und Passwörter oder Jobs in der Datenbank versteckt. Diese Rootkits haben darüber hinaus den Vorteil, plattformunabhängig und nur datenbankspezifisch zu sein. Eine Variante ist die Modifikation der Database-Views. Die meisten Tools verwenden Views um auf die Inhalte von Tabellen zu kucken. Ein Eintrag kann so in einem View verborgen werden während er in der Tabelle selbst weiter enthalten ist. Es gibt inzwischen sogar kommerzielle DB-Rootkits, z.B. von Argeniss, inzwischen von Gleg aufgekauft. Von Paul Wright (PDF) gibt es ebenfalls ein Rootkit-Whitepaper, außerdem eine neue Methode von David Litchfield, der im Memory (PPT) einzelne Funktionen patcht.
Die wichtigsten Probleme aktuell sind:
Die Listener sind ab 10g automatisch geschützt, die Hauptprobleme werden weiterhin Patches sein, da viele Anwender nicht kurzfristig oder regelmäßig Patches einspielen können.
Eine weitere neue Funktion mit Missbrauchspotential ist die Transparent Data Encryption (TDE) die auf jeder neuen Oracle-Installation vorhanden ist und nicht deinstalliert werden kann (jedoch zur Nutzung eine eigene 10.000 USD/CPU Lizenz verlangt). Wenn die TDE eingesetzt wird, hilft sie dem Angreifer, relevante Daten zu finden da nur wichtige Sachen verschlüsselt sind (und die Entschlüsselung beim Query ja transparent erfolgt). Wenn sie nicht eingesetzt wird, gibt es ganz neue Erpressungsmethoden. Einfach die TDE aktivieren und kritische Daten verschlüsseln. Das passiert (da transparent) unsichtbar für den Nutzer. Nach einem Reboot bzw. Neustart der Datenbank ist dann der Schlüssel weg und das Unternehmen zahlt sicher gerne für das fehlende Passwort.
Weitere Themen waren Skripten in Clients für SQL*Plus, die z.B. beim Starten des Oracle-Clients automatisch nach der Anmeldung ausgeführt werden (quasi wie ein Trojaner) sowie Shellcode in Tablenamen, z.B. wenn ein Table „!rm -rF /“ heißt 🙂 Cooles Zeug.