Ab der Version 11g der Oracle Datenbank ist der Prozess für die Authentifizierung so definiert: Der Client verbindet sich zum Server und schickt seinen Benutzernamen. Daraufhin generiert der Server eine verschlüsselte Server-Session-ID, deren Schlüssel der sogenannte Passwort-Hash ist. Passwort-Hash und Passwort-Salt überträgt der Server zum Client, der wiederum anhand des Passwort-Salts und seines eigentlichen Passworts versucht, einen Passwort-Hash zu erzeugen. Mit diesem kann er dann die Server-Session-ID entschlüsseln. Zum Schluss generiert der Client eine Client-Session-ID, die er mit AES verschlüsselt. Der Schlüssel, der Client-Password-Hash, beinhaltet sowohl die Server-Session-ID als auch die Client-Session-ID. Diese werden genutzt, um das eigentliche Passwort zu verschlüsseln. Zuletzt werden verschlüsseltes Passwort sowie Client-Session-ID an den Server geschickt.
So verläuft eine Authentifizierung normalerweise, wenn alles glatt geht. Wenn ein Angreifer es auf eine Oracle-Datenbank in der Version 11.1 oder 11.2 abgesehen hat, dann macht ihm dieses Protokoll die Arbeit einfacher: „Es handelt sich um ein größeres Problem“, meint der Sicherheitsexperte Alexander Kornbrust auf Nachfrage von DOAG Online. Oracle schicke den Passwort-Salt und den verschlüsselten Passwort-Hash des Benutzers zu jedem Client, der angebe, ein Datenbank-Benutzer zu sein, so Kornbrust.
Dadurch könnten Angreifer beispielsweise herausfinden, ob ein Benutzername in der Datenbank überhaupt existiert. „Schickt man den Benutzernamen XYZ zur Datenbank, dann gibt es zwei Möglichkeiten: Entweder antwortet Oracle – in dem Fall existiert der Benutzer. Wird kein Salt geschickt, existiert der Benutzer nicht.“
Wenn der Server nun antwortet und Passwort-Hash und -Salt schickt, dann kann sich der Hacker alle Zeit der Welt lassen, um das Passwort zu knacken. „Das große Problem an diesem Angriff ist, dass er keine Spuren hinterlässt. Er kann also nicht auditiert werden“, erklärt der Experte.
Es seien nur die Datenbanken 11.1 und 11.2 betroffen, bestätigt Alexander Kornbrust. Die Lücke ist im vergangenen Jahr mit dem Patch-Set 11.2.0.3 geschlossen worden. Jedoch hat es Oracle nicht für nötig gehalten, die Sicherheitslücke in einem Critical Patch Update (CPU) zu stopfen. Ein Schutz gegen mögliche Angriffe dieser Art sei die Verwendung des Oracle 10g DES Algorithmus, meint Kornbrust. Mit seinem Team versuche er derzeit, das Problem nachzustellen.
