Kritische RCE-Schwachstelle in ForgeRock OpenAM wird aktiv angegriffen

  • Die Angriffe werden durch eine ungepatchte Sicherheitslücke in ForgeRocks Access Management ermöglicht, einer beliebten Plattform, die als Front-End für Web-Apps und Remote-Access-Setups dient.

    Angreifer nutzen aktiv eine kritische Schwachstelle in der beliebten Access Management-Plattform des Digital-Identity-Management-Unternehmens ForgeRock aus, die eine Remote-Code-Ausführung (RCE) vor der Autorisierung ermöglicht.

    Access Management, eine kommerzielle Plattform für die Zugangsverwaltung, basiert auf der Open-Source-Zugangsverwaltungsplattform für Webanwendungen OpenAM. Die Plattform dient in vielen Unternehmen als Front-End für Webanwendungen und Remote-Zugriffseinrichtungen.

    Am Montagmorgen warnte die Cybersecurity and Infrastructure Security Agency (CISA), dass die Sicherheitslücke es Angreifern ermöglichen könnte, Befehle im Kontext des aktuellen Benutzers auszuführen. Die Schwachstelle findet sich in Access Management Versionen unterhalb von 7.0, die auf Java 8 laufen. Das bedeutet, dass die Versionen 6.0.0.x, 6.5.0.x, 6.5.1, 6.5.2.x und 6.5.3, sowie ältere, nicht unterstützte Versionen betroffen sind.

    [Blocked Image: https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg]

    Ebenfalls am Montag erklärte ForgeRock in einem aktualisierten Sicherheitshinweis, dass die Schwachstelle nicht Access Management 7 und höher betrifft.

    Ein Exploit für die kritische Schwachstelle im Kern der Sache – CVE-2021-35464 – wurde erstmals von Michael Stepankin, einem Forscher für die Cybersicherheitsfirma PortSwigger, am 29. Juni gemeldet. In seinem Bericht erklärte Stepankin, dass er eine neue Ysoserial-Deserialisierungs-Gadget-Kette speziell für den Exploit erstellt hat.

    Wie auf GitHub beschrieben, ist Ysoserial ein Proof-of-Concept-Tool zur Erzeugung von Payloads, die unsichere Java-Objekt-Deserialisierung ausnutzen. Die Serialisierung ist ein Mechanismus zur Umwandlung des Zustands eines Objekts in einen Byte-Stream. Die Deserialisierung wiederum ist der umgekehrte Prozess: Das ist der Mechanismus, bei dem der Byte-Stream verwendet wird, um das eigentliche Java-Objekt im Speicher neu zu erzeugen, das zur Persistenz des Objekts verwendet wird.

    Was für ein Dinky PoC

    In seinem Beitrag fasst Stepankin den Fehler als RCE zusammen, der “dank unsicherer Java-Deserialisierung im Jato-Framework, das von OpenAM verwendet wird, möglich ist.” Der Proof of Concept (PoC) erfordert diese einzelne GET/POST-Anfrage zur Codeausführung:

    GET /openam/oauth2/..;/ccversion/Version?jato.pageSession=<serialized_object>

    Er sagte, dass ein Angreifer, der eine solche Anfrage bastelt, sie an einen exponierten, entfernten Endpunkt senden kann, um einen RCE durchzuführen.

    Der Forscher entdeckte die Sicherheitslücke, als er sich mit OAuth-Schwachstellen befasste. OAuth ist ein offener Standard für die Zugriffsdelegation, der häufig verwendet wird, um sich bei Diensten anzumelden, ohne ein Passwort einzugeben, indem man den Anmeldestatus bei einem anderen, vertrauenswürdigen Dienst oder einer Website verwendet. Beispiele hierfür sind die “Anmeldung bei Google” oder “Anmeldung bei Facebook”, die viele Websites verwenden, anstatt Besucher aufzufordern, ein neues Konto zu erstellen. Diese “Sign in”- oder “Log in”-Aufforderungen werden als Zustimmungsaufforderungen bezeichnet.

    Vor einem Jahr warnte Microsoft, dass Angreifer vor dem Hintergrund der weit verbreiteten Remote-Arbeit und der verstärkten Nutzung von Collaboration-Apps anwendungsbasierte Angriffe, die OAuth 2.0 ausnutzen, ausweiten.

    Mit Hilfe einiger Skripte entdeckte Stepankin alle Server, die auf den URI “/well-known/openid-configuration” antworten, und überprüfte deren Konfiguration. Er beschloss, sich auf “wirklich folgenschwere” Schwachstellen zu konzentrieren: Daher konzentrierte er sich auf Systeme, die entweder Open-Source sind oder zum Herunterladen und Dekompilieren zur Verfügung stehen. “ForgeRock OpenAm war ein solches System, das ich im Rahmen des Bug Bounty gefunden habe”, schrieb er. “Es erschien mir als eine monströse Java-Enterprise-Anwendung mit einer riesigen Angriffsfläche, also entschied ich mich, einen tieferen Blick darauf zu werfen.”

    Seine Erkenntnisse aus dem Kampf gegen das Java-Monster:

    • Quellcode-Analyse und lokale Tests sind unerlässlich, um Probleme wie dieses zu finden.
    • URLDNS und JRMPClient Gadget-Ketten sind die universellsten für das Testen der Deserialisierung in Java.
    • Selbst in Lösungen, die für die Authentifizierung ausgelegt sind, finden Sie eine große Angriffsfläche, die ohne jegliche Auth.
    • Automatische Quellcode-Analyse-Tools sind nicht ausreichend, wenn sie Abhängigkeiten nicht abdecken.
    • Java Deserialisierung rockt.

    Keine Patches verfügbar

    Zum 29. Juni, dem Datum, an dem Stepankin seine Erkenntnisse veröffentlichte, waren keine Patches verfügbar. In seinem Advisory forderte ForgeRock die Benutzer auf, einen Workaround anzuwenden, der “sofort” angewendet werden sollte, um den Einsatz zu sichern, und wies darauf hin, dass die Workarounds für alle Versionen geeignet sind, auch für ältere, nicht unterstützte.

    Stepankin merkte an, dass die Schwachstelle in ForgeRock AM Version 7.0 gepatcht wurde, “indem der Endpunkt ‘/ccvesion’ komplett entfernt wurde, zusammen mit anderen Legacy-Endpunkten, die Jato verwenden.”

    Er erwähnte dieses große “aber”: “Das Jato-Framework wurde seit vielen Jahren nicht mehr aktualisiert, so dass alle anderen Produkte, die darauf angewiesen sind, immer noch betroffen sein können.”

    Der Forscher merkte auch an, dass der Fehler keine Instanzen betrifft, die mit Java Version 9 oder neuer laufen, “da Jato Klassen benötigt, die in Java 9 entfernt wurden. Das ist einer der Gründe, warum ForgeRock AM Versionen vor 7, wie 6.5, immer noch auf Java 8 laufen”, fuhr er fort.

    Upgrade oder Workaround

    Benutzer müssen ein Upgrade auf Version 7.x durchführen oder eine der beiden Umgehungslösungen anwenden, die ForgeRock in seinem Advisory zur Verfügung stellt.

    CISA empfiehlt diese Schritte für Benutzer von Access Management, um ihre Plattformen gegen die aktiven, laufenden Exploits zu sichern:

    • Lesen Sie den ForgeRock Security Advisory und den Australian Cyber Security Centre Alert;
    • Prüfen Sie auf anfällige Instanzen der Access Management-Software (siehe die technische Folgenabschätzung von ForgeRock); und
    • Setzen Sie vorrangig ein Update auf Access Management Version 7 ein oder wenden Sie den Workaround dringend an.

    Schmackhafte Ziele

    Marcus Hartwig, Manager of Security Analytics bei der Cybersecurity-Firma Vectra, erklärte am Montag gegenüber Threatpost, dass Identitäts- und Zugriffsmanagement-Plattformen (IAM) wie OpenAM “immer reife Ziele für Angreifer sind, da sie Angreifern den Zugriff auf mehrere nachgelagerte Anwendungen ermöglichen, die mit der Lösung föderiert sind.”

    Außerdem, so Hartwig in einer E-Mail, “selbst wenn das kompromittierte Konto keinen Zugriff auf eine bestimmte Anwendung hat, unterstützen viele IAM-Lösungen die Erstellung neuer nachgelagerter Konten auf Anwendungen über Protokolle wie SCIM, was es Angreifern weiter ermöglicht, ihre Angriffe voranzutreiben.”

    Er sagte, dass es für Unternehmen, die IAM-Lösungen für SSO in nachgelagerten Anwendungen einsetzen, “von größter Wichtigkeit” ist, “das Konto-Verhalten in ihrer Umgebung zu überwachen, um Angriffe zu erkennen, die die präventive Sicherheit umgehen, auf die sich Access-Management-Lösungen konzentrieren.”

    Schauen Sie sich unsere kostenlosen kommenden Live- und On-Demand-Webinar-Events an – einzigartige, dynamische Diskussionen mit Cybersecurity-Experten und der Threatpost-Community.

    Einige Teile dieses Artikels stammen aus:
    threatpost.com