In diesem Blog-Beitrag zeigen wir, wie sich scheinbar unbedeutende Besonderheiten der kryptografischen Implementierung auf die Sicherheit des Produkts auswirken. Durch das Ausnutzen dieser Sicherheitslücke konnten wir beliebige Authentifizierungstoken herstellen, die es uns ermöglichen, sich als beliebiger Benutzer auszugeben und somit die Hauptfunktionalität von OAM zu brechen.
Der Oracle Access Manager (OAM) ist die Komponente der Oracle Fusion Middleware, die die Authentifizierung für alle Arten von Webanwendungen handhabt. In typischen Szenarien ist der Webserver, der Zugriff auf die Anwendung bereitstellt, mit einer Authentifizierungskomponente (dem Oracle WebGate) ausgestattet. Wenn ein Benutzer eine geschützte Ressource vom Webserver anfordert, leitet er diesen an einen Authentifizierungsendpunkt des OAM um. Der OAM authentifiziert dann den Benutzer (z.B. mit Benutzername und Passwort) und leitet ihn zurück an die Webanwendung. Da die gesamte Authentifizierung von einer zentralen Anwendung gehandhabt wird, muss sich ein Benutzer nur einmal authentifizieren, um auf beliebige durch den OAM (Single Sign-On) geschützte Anwendungen zuzugreifen.
Während eines Forschungsprojekts haben wir festgestellt, dass ein vom OAM verwendetes kryptografisches Format einen schwerwiegenden Fehler aufweist. Durch das Ausnutzen dieser Sicherheitslücke konnten wir einen Sitzungstoken erstellen. Wenn ein WebGate dieses Token erhält, akzeptiert es dies als legitime Form der Authentifizierung und erlaubt den Zugriff auf geschützte Ressourcen. Darüber hinaus kann ein Angreifer ein Sitzungs-Cookie für einen beliebigen Benutzernamen erstellen, sodass sich dieser als beliebiger Benutzer authentifizieren kann.
Wer war betroffen?
Beide aktuell unterstützten Versionen, 11g und 12c, waren von dieser Sicherheitslücke betroffen – das hier beschriebene Szenario wurde nur mit Version 12c verifiziert. Ein einfaches Google Dork zum Auffinden von OAM-Installationen liefert ca. 11.800 Ergebnisse, von denen einige auf bekannte Organisationen verweisen (einschließlich Oracle selbst). Das sind nur die im Internet erreichbaren Installationen.
Wir haben diese Sicherheitslücke sofort nach der Identifizierung im November 2017 an Oracle gemeldet. Oracle reagierte zügig und stellte im April 2018 eine Korrektur mit dem neuesten Critical Patch Update (CPU) bereit. Da dieser Patch im regulären Update-Zeitplan von Oracle enthalten war, ist davon auszugehen, dass OAM-Administratoren den Patch inzwischen angewendet haben. Wenn dies für Ihre Organisation nicht der Fall ist, ist es jetzt höchste Zeit!
Darüber hinaus ist es ratsam, Protokolle und Logs auf ein bestimmtes Muster hin zu analysieren: Ein erfolgreicher Angriff verursacht nämlich eine große Anzahl von Entschlüsselungsfehlern, die aus einem fehlerhaften Padding resultieren (javax.crypto.BadPaddingException).
Dies ist nur eine Kurzfassung der Schwachstelle. Weitere Informationen zu betroffenen Versionen, Kontakt-Timeline usw. finden Sie im zugehörigen Advisory (Englisch) bzw. im englischen Blog Beitrag.