Apache Unomi ist eine Java Open Source-Kundendatenplattform, ein Java-Server, der entwickelt wurde, um Kunden-, Leads- und Besucherdaten zu verwalten und Kundenerlebnisse zu personalisieren. Unomi verwendet man, um Personalisierung und Profilverwaltung in sehr unterschiedlichen Systemen wie CMS, CRMs, Issue Trackers, nativemobile Anwendungen usw. zu integrieren. Unomi wurde als Top-Level Apache-Produkt im Jahr 2019 angekündigt, mit hoher Skalierbarkeit und einfacher Integration.
Da Unomi eine Fülle von Daten enthält und enge Integrationen mit anderen Systemen aufweist, was es zu einem sehr begehrten Ziel für Angreifer macht, analysierte das Checkmarx Security Research Team die Plattform, um potenzielle Sicherheitsprobleme aufzudecken. Die Ergebnisse sind im Folgenden detailliert aufgeführt.
Apache Unomi erlaubte Angreifern, remote malicious requests (böswillige Anforderungen) mit MVEL- und OGNL-Expressions zu senden, die beliebige Klassen enthalten könnten, was zu Remote Code Execution (RCE) mit den Berechtigungen der Unomi-Anwendung führte. MVEL- und OGNL-Expressions werden von verschiedenen Klassen innerhalb verschiedener interner Pakete des Unomi-Pakets ausgewertet, sodass sie zwei separate Schwachstellen aufweisen. Diese Schwachstellen können über einen öffentlichen Endpunkt genutzt werden, der öffentlich gehalten werden sollte, damit die Anwendung ordnungsgemäß, ohne Authentifizierung und ohne Vorkenntnisse des Angreifers funktioniert.
Beide Schwachstellen, die als CVE-2020-13942 bezeichnet werden, haben einen CVS-Score von 10,0 (kritisch), da sie zu einer vollständigen Gefährdung der Vertraulichkeit, Integrität und Zugänglichkeit des Unomi-Dienstes führen und den Zugriff auf das zugrunde liegende Betriebssystem ermöglichen.
Unomi bietet eine eingeschränkte API, die das Abrufen und Bearbeiten von Daten ermöglicht, zusätzlich zu einem öffentlichen Endpunkt, an dem Anwendungen Benutzerdaten hochladen und abrufen können. Unomi lässt komplexe Conditions in den Anforderungen an seine Endpunkte zu.
Unomi-Conditions basieren auf Ausdruckssprachen (EL), wie OGNL oder MVEL, damit Benutzer komplexe und granulare Abfragen erstellen können. Die EL-basierten Conditions werden vor dem Zugriff auf Daten im Speicher ausgewertet.
In den Versionen vor 1.5.1 waren diese Ausdruckssprachen überhaupt nicht eingeschränkt. Das machte Unomi über Expression Language Injection anfällig für RCE. Ein Angreifer konnte beliebigen Code und Betriebssystembefehle auf dem Unomi-Server ausführen, indem er eine einzelne Anforderung sendete. Diese Sicherheitsanfälligkeit wurde als CVE-2020-11975 klassifiziert und behoben. Aufgrund weiterer Untersuchungen durch das Security Research Team wurde jedoch festgestellt, dass die Korrektur nicht ausreicht und trivial umgangen werden kann.
Der Patch für CVE-2020-11975 führte SecureFilteringClassLoader ein, der die in den Experessions verwendeten Klassen mit einer Zulassungsliste und einer Blockliste überprüft. Der SecureFilteringClassLoader geht davon aus, dass jede Klasse in MVEL- und OGNL-Expressions mit der loadClass()-Methode der ClassLoader-Klasse geladen wird. Der SecureFilteringClassLoader überschreibt die ClassLoader loadClass-Methode und führt die Allowlist- und Blocklistenprüfungen ein. Diese Annahme war falsch. Es gibt mehrere Möglichkeiten, eine andere Klasse als das Aufrufen der loadClass()-Methode zu laden, was zur Umgehung der Sicherheitssteuerung führt und Unomi für RCE offen lässt.
Erstens verwenden die MVEL-Ausdrücke in einigen Fällen bereits instanziierte Klassen, wie Runtime oder System, ohne loadClass() aufzurufen. Dies führt in der neuesten Version von Unomi (1.5.1) dazu, dass die Auswertung von MVEL-Expressions innerhalb der Bedingung erlaubt ist, die beliebige Klassen enthält.
Die folgende HTTP-Anforderung hat eine Bedingung mit einem Parameter, der einen MVEL-Ausdruck enthält (script::Runtime r = Runtime.getRuntime(); r.exec(‚touch /tmp/POC‘);). Unomi analysiert den Wert und führt den Code nach skript:: als MVEL-Ausdruck aus. Der Ausdruck im folgenden Beispiel erstellt ein Runtime-Objekt und führt einen „touch“-OS-Befehl aus, der eine leere Datei im Verzeichnis /tmp
Zweitens gibt es eine Möglichkeit, Klassen innerhalb von OGNL-Ausdrücken zu laden, ohne den loadClass()-Aufruf auszulösen. Die folgende HTTP-Anforderung ruft Runtime ab und führt einen OS-Befehl mithilfe der Java-Reflections-API aus.
Das mag beängstigend aussehen, aber es ist einfach Runtime r = Runtime.getRuntime(); r.exec(„touch /tmp/POC“); mit der Reflections-API geschrieben und in die OGNL-Syntax eingefügt.
Beide vorgestellte Ansätze umgehen erfolgreich die in Version 1.5.1 eingeführte Sicherheitskontrolle, wodurch sie an zwei verschiedenen Stellen anfällig für RCE ist.
Unomi kann in verschiedene Datenspeicher- und Datenanalysesysteme integriert werden, die sich normalerweise im internen Netzwerk befinden. Die Sicherheitsanfälligkeit wird über einen öffentlichen Endpunkt ausgelöst und ermöglicht es einem Angreifer, OS-Befehle auf dem anfälligen Server auszuführen. Der anfällige öffentliche Endpunkt macht Unomi zu einem idealen Einstiegspunkt in Unternehmensnetzwerke. Die enge Integration mit anderen Diensten macht es auch zu einem Sprungbrett für weitere Bewegungen innerhalb eines internen Netzwerks.
Nachdem die Schwachstellen entdeckt und validiert wurden, wurde Apache über die Ergebnisse informiert. Checkmarx arbeitete während des gesamten Behebungsprozesses mit Apache zusammen, bis alles entsprechend gepatcht wurde.
Um mehr über diese Arten von Sicherheitsanfälligkeiten zu erfahren, haben OWASP und CWE Beschreibungen, Beispiele, Konsequenzen und zugehörige Steuerelemente, in den folgenden Links aufgezeigt:
https://owasp.org/www-community/vulnerabilities/Expression_Language_Injection
https://cwe.mitre.org/data/definitions/917.html
