CVE-2022-47966 - RCE in zahlreichen ManageEngine-Produkten

TL;DR: Vierundzwanzig ManageEngine-Produkte sind anfällig für einen Pre-Auth-RCE. Von den Diensten, die Censys identifizieren konnte, melden 70 % eine anfällige Softwareversion.

Wenn Sie eines der vielen ManageEngine-Produkte einsetzen und die SAML SSO-basierte Authentifizierung aktiviert haben, aktuell oder in der Vergangenheit, aktualisieren Sie es sofort!

Einführung

Am 10. Januar 2023 wurden Details über eine Sicherheitslücke bekannt, die vierundzwanzig verschiedene ManageEngine-Produkte betrifft und zu einer Remotecodeausführung (RCE) vor der Authentifizierung führen kann, wenn die SAML-Authentifizierung jemals aktiviert wurde. Diese anfälligen Produkte verwenden eine seit zehn Jahren veraltete Version des Open-Source-Projekts "Apache Santuario". Diese Sicherheitslücke wurde CVE-2022-47966 zugeordnet.

ManageEngine ist ein Unternehmen, das eine breite Palette von Produkten entwickelt, vom Identitätsmanagement bis hin zu IT-Ticketing- und Supportsystemen. Diese Produkte finden sich in fast jeder Branche, die Technologie einsetzt: Das Bildungswesen, der Einzelhandel, die Fertigungsindustrie, das Gesundheitswesen und viele mehr. Die Art von Daten, die ein Angreifer aus einem kompromittierten System exfiltrieren kann, könnte genutzt werden, um sich innerhalb eines Unternehmens weiterzuentwickeln.

Wir haben herausgefunden, dass von allen ManageEngine-Produkten, die Censys identifizieren kann, 67 % der Hosts im Internet eine Version der Software ausführen, die möglicherweise für diesen Exploit anfällig ist. Wir verwenden das Wort "möglicherweise", weil ein Administrator die SAML SSO-Authentifizierung für den Dienst aktivieren muss (oder in einigen Fällen irgendwann in der Vergangenheit aktiviert hat), und Censys keine Möglichkeit hat, festzustellen, ob dies der Fall ist (wir sehen nur die HTTP-Antwort).

Bei diesem Problem handelt es sich um ein einfaches Exploit, das von Komplexität, Geschichte und technischer Raffinesse umhüllt ist. Bevor wir jedoch auf die Details der Sicherheitslücken im Internet eingehen, möchte ich den allgemeinen Ablauf einer SAML-SSO-Authentifizierungsanfrage beschreiben, damit wir die richtigen Werkzeuge haben, um zu verstehen, warum diese Sicherheitslücke auftritt und warum sie so leicht ausgenutzt werden kann.

(SAML SSO Fluss über SalesForce)

Wenn ein Benutzer versucht, sich bei einer Webanwendung anzumelden, die SAML-basierte SSO-Authentifizierung verwendet, antwortet der Webserver im Allgemeinen mit einer SAML-Anfrage. Der Browser des Benutzers leitet diese Anfrage dann an einen "Identitätsanbieter" weiter (der von der Webanwendung definiert wird und sich in der Regel auf einem anderen Server befindet); dieser Identitätsanbieter analysiert dann diese SAML-Anfrage und authentifiziert den Client (in der Regel durch Eingabe eines Benutzernamens und eines Passworts). Sobald sich der Benutzer bei diesem Identitätsanbieter authentifiziert hat, erzeugt der Identitätsanbieter eine SAML-Antwort, die an den Browser des Clients zurückgesendet wird. Der Browser des Kunden wiederum sendet diese SAML-Antwort an die ursprüngliche Webanwendung. Die Webanwendung muss nun überprüfen, ob die SAML-Antwort gültig und rechtmäßig ist und vom Identitätsanbieter stammt.

Dieser allgemeine Ablauf der SAML SSO-Authentifizierung bedeutet, dass ein Benutzer den Inhalt einer SAML-Antwort des Identitätsanbieters ändern und manipulieren kann, bevor sie an die Webanwendung zurückgesendet wird. In den meisten Fällen werden Manipulationen von der Webanwendung leicht erkannt, da die Antwort eine kryptografisch signierte Signatur enthält, die die Richtigkeit des Inhalts bestätigt(XMLDSIG). Und hier fangen die Dinge an, seltsam zu werden.

Um diese Nachrichtenvalidierung durchzuführen, verwenden ManageEngine-Produkte die Open-Source-API "Apache Santuario", die die Komplexität der XMLDSig-Spezifikation und den Prozess der Überprüfung des "Signature"-Abschnitts einer SAML-Antwort handhabt. In älteren Versionen dieser API gab es einen Fehler, der dazu führte, dass bestimmte Elemente dieses Signaturabschnitts verarbeitet und dekodiert wurden, bevor die Gültigkeit der gesamten "Signature"-Nachricht überprüft wurde.

Eines der Elemente im Abschnitt "Signatur", das vor der Validierung ausgeführt wird, umfasst die Möglichkeit, XSLT-basierte Transformationen (ein Turing-komplettes System zur Umwandlung eines Datentyps in einen anderen) an der Eingabe vorzunehmen. Und da ein Benutzer die SAML-Antwort ändern kann, bevor sie an die Webanwendung zurückgesendet wird, kann ein Angreifer eine XSLT-Injektion auf der Serverseite durchführen. Ein böswilliger Client kann eine XSLT-Nutzlast konstruieren, damit die Java-Laufzeitumgebung vom Server geladen und zur Ausführung eines Prozesses verwendet werden kann.

Wenn Sie sich für die Details dieser Schwachstelle und die bisherigen Untersuchungen zu diesem Thema interessieren, empfehlen wir Ihnen einen Beitrag des ursprünglichen Forschers(Archivlink). Dieser Link ist ein guter Ausgangspunkt für weitere Informationen über XSLT-Injection-Schwachstellen.

Ein Proof-of-Concept-Exploit wurde auf Github veröffentlicht, und die Ausnutzung der Schwachstelle ist äußerst trivial. Rapid7 hat berichtet, dass diese Schwachstelle in freier Wildbahn ausgenutzt wurde, und hat in seinem Blog mehrere Hinweise auf eine Kompromittierung veröffentlicht.

Censys Fundstücke

Obwohl sich die Empfehlung auf vierundzwanzig verschiedene ManageEngine-Produkte bezieht, konnte Censys online nur Verweise auf neun der Produkte finden und nur bei sieben die laufende Version ermitteln. Aus diesem Grund werden wir nur auf die Details der Produkte eingehen, die wir mit einer Versionsnummer verknüpfen konnten. Sie können alle gemeldeten Produkte in der Censys Suche mit dieser Abfrage finden .

Bevor wir auf die Einzelheiten der Versionen eingehen, hier eine Aufschlüsselung dieser Produkte nach Ländern, wobei die Vereinigten Staaten mit über tausend einzelnen Hosts den ersten Platz einnehmen.