Im Zentrum des Falls steht nicht eine Lücke in Oracle selbst, sondern die Kombination aus einer SQL-Injection in der Anwendung und weitreichenden Rechten des Datenbankkontos. Das betroffene Suchfeld zur Autovervollständigung übergab Eingaben ungeprüft über eine Java Database Connectivity-Verbindung an Oracle. Dieses Konto hatte genug Berechtigungen, um Java-Objekte in der Datenbank zu erstellen.
Oracle bringt eine eingebettete Java Virtual Machine mit. Über die Anweisung CREATE JAVA SOURCE kann ein Benutzer Java-Code an die Datenbank übergeben, den Oracle kompiliert und als Schema-Objekt speichert. Laut Oracle-Dokumentation reicht im eigenen Schema dafür die Systemberechtigung CREATE PROCEDURE. Um aus diesem Code einen Betriebssystemprozess über Runtime.exec zu starten, ist zusätzlich eine Berechtigung zur Dateiausführung nötig, die Oracle nach eigenen Angaben nur privilegierten Administratoren vergibt.
Huntress legt nicht offen, welche Rechte das kompromittierte Konto konkret besaß oder ob die Angreifer weitere Berechtigungen hinzufügen mussten. Fest steht für das Unternehmen nur, dass die Angriffskette funktionierte und damit die nötigen Rechte sowohl zum Anlegen der Java-Objekte als auch zur späteren Befehlsausführung vorhanden waren.
Die Sicherheitsforscher verfolgen das eingesetzte Nachlade-Toolkit unter dem Namen khunt. Es bestand aus sechs Java-Objekten und mehreren khunt_*-PL/SQL-Wrappern. Ein Test mit „cmd.exe /c whoami“ über KhuntCmd lieferte laut Huntress SYSTEM zurück. Anschließend beobachtete das Unternehmen den Einsatz von PowerShell und reg.exe, um die Registry-Hives SECURITY und SYSTEM nach F:\Oracle zu kopieren. Zudem führten die Angreifer tasklist /svc aus und schrieben die Ausgabe in khunttasks.txt; außerdem kopierten sie SAM und SECURITY mit esentutl.exe.
Huntress sah, dass diese Dateien lokal bereitgestellt wurden, konnte aber nicht belegen, dass sie auch exfiltriert wurden. Einen konkreten Bedrohungsakteur nennt das Unternehmen nicht. Die schädlichen Anfragen führte Huntress auf die Adresse 178.162.151[.]229 zurück.
Technisch bemerkenswert ist, dass bei diesem Vorgehen kein klassisches Programm auf dem Dateisystem abgelegt werden musste. Eine in ein Datenbankschema kompilierte Java-Klasse ist weder ein Prozess noch eine Binärdatei oder Datei im Dateisystem. Produkte zur Endpunkt-Erkennung und -Reaktion prüfen laut Huntress die internen Vorgänge von Oracle in der Regel nicht. In der Beschreibung des Unternehmens wird die Datenbank damit von einem bloßen Abfrageziel zu einem Ausgangspunkt weiterer Angriffe.
Neu ist die Methode allerdings nicht. Huntress verweist auf Marco Ivaldis raptor_oraexec.sql aus dem Jahr 2006. Dieses Skript erzeugt ein Oracle-Quellobjekt mit Methoden zur Befehlsausführung und zum Lesen von Dateien und macht sie anschließend über PL/SQL-Wrapper für SQL nutzbar. Die khunt-Objekte folgen laut Huntress derselben Grundarchitektur. „Der Einsatz dieser Technik in realen Angriffen ist nur selten dokumentiert worden“, erklärte das Unternehmen.
Für die Suche nach diesem konkreten Toolkit empfiehlt Huntress, die Oracle-Installation nach Objektnamen zu durchsuchen, die mit Khunt beginnen, sowie SQL-Protokolle nach KHUNT%. Diese Indikatoren erfassen jedoch nur dieses Toolkit, nicht die zugrunde liegende Technik allgemein. Gegenmaßnahmen liegen laut Quelle in parametrierten Abfragen und Eingabevalidierung in der Anwendung sowie in minimalen Rechten für das darunterliegende Datenbankkonto.