muhammad-ali007/log4j_cve-2021-44228Praktische Laborübung zur Ausnutzung von Log4Shell (CVE-2021-44228) mit JNDI-Injection, LDAP-Referral-Servern und Reverse-Shell-Payloads. Enthält Erkennung, Umgehungstechniken und Anleitung zur Post-Exploitation.
Die Log4j-Schwachstelle, auch bekannt als „Log4Shell" oder „CVE-2021-44228", ist ein kritischer Sicherheitsfehler in der Apache-Log4j-Bibliothek. Log4j ist ein weit verbreitetes, auf Java basierendes Logging-Framework, das Entwicklern ermöglicht, Meldungen von Anwendungen an verschiedene Ziele zu protokollieren, wie z. B. Dateien, Datenbanken und Konsolenausgaben.
Die Schwachstelle wurde im Dezember 2021 entdeckt und hat aufgrund ihrer Schwere und ihres Ausnutzungspotenzials große Aufmerksamkeit erlangt. Sie betrifft Log4j-Versionen 2.x und in einigen Fällen sogar frühere Versionen. Die Log4j-Schwachstelle ist eine Schwachstelle zur Remote-Codeausführung (RCE), was bedeutet, dass ein Angreifer durch die Ausnutzung des Fehlers beliebigen Code auf einem Zielsystem ausführen kann. Die Schwachstelle wird durch einen Konstruktionsfehler in der Log4j-Bibliothek verursacht, der mit der Verarbeitung von Protokollmeldungen zusammenhängt, die speziell präparierte Daten enthalten.
Die Ausnutzung der Schwachstelle beruht auf der Fähigkeit, bösartigen Code in die Protokollmeldung einzuschleusen. Dies kann über verschiedene Vektoren erreicht werden, wie z. B. benutzergesteuerte Eingabefelder, HTTP-Request-Header oder andere vom Benutzer bereitgestellte Daten, die an die Protokollanweisung übergeben werden.
Wenn eine verwundbare Anwendung eine Protokollmeldung mit den speziell präparierten Daten verarbeitet, interpretiert Log4j die Daten als einen Java-Naming-and-Directory-Interface(JNDI)-Lookup. Durch die Ausnutzung dieses Verhaltens kann ein Angreifer einen Payload erstellen, der einen JNDI-Lookup auf einem vom Angreifer kontrollierten bösartigen Server auslöst. Dieser Server kann dann mit einem Payload antworten, der auf dem Zielsystem ausgeführt wird, sodass der Angreifer eine Remote-Codeausführung erreichen kann.
Die Auswirkungen der Log4j-Schwachstelle sind schwerwiegend, da Log4j in vielen Java-basierten Anwendungen weit verbreitet ist, darunter Webserver, Anwendungen und Cloud-Dienste. Die Schwachstelle ermöglicht es Angreifern, sich unbefugten Zugang zu betroffenen Systemen zu verschaffen, was möglicherweise zu Datenpannen, Systemkompromittierung und weiterer Ausnutzung der kompromittierten Umgebung führt.
Heute ist log4j Version 2.16.0 verfügbar und schließt diese Schwachstelle (JNDI ist vollständig deaktiviert, die Unterstützung für Message Lookups ist entfernt, und die neue DoS-Schwachstelle CVE-2021-45046 ist nicht vorhanden). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
Die enorme Gefahr dieser Schwachstelle liegt jedoch darin, wie allgegenwärtig das Logging-Paket ist. Millionen von Anwendungen sowie Softwareanbieter verwenden dieses Paket als Abhängigkeit in ihrem eigenen Code. Während Sie möglicherweise in der Lage sind, Ihre eigene Codebasis mit log4j zu patchen, müssen andere Anbieter und Hersteller ihre eigenen Sicherheitsupdates weiterhin nachgelagert bereitstellen. Viele Sicherheitsforscher haben diese Schwachstelle wegen ihrer enormen Angriffsfläche mit Shellshock verglichen. Wir werden diese Schwachstelle noch jahrelang sehen.
Für eine wachsende, von der Community unterstützte Liste von Software und Diensten, die für CVE-2021-44228 anfällig sind, schauen Sie sich dieses GitHub-Repository an (https://github.com/YfryTchsGD/Log4jAttackSurface)
Obwohl es eine Reihe anderer Artikel, Blogs, Ressourcen und Lernmaterialien zu CVE-2021-44228 gibt, gefallen mir (dem Autor dieser Übung) besonders diese:
Das log4j-Paket fügt Protokollen zusätzliche Logik hinzu, indem es Einträge „parst", um die Daten letztendlich anzureichern -- es kann jedoch zusätzlich Aktionen ausführen und sogar Code basierend auf den Eintragsdaten auswerten. Das ist der Kern von CVE-2021-44228. Andere Syntax könnte tatsächlich genauso ausgeführt werden, wie sie in die Protokolldateien eingegeben wird. Einige Beispiele für diese Syntax sind:
Sie kennen vielleicht bereits den allgemeinen Payload, um diese log4j-Schwachstelle auszunutzen. Das Format der üblichen Syntax, die dies ausnutzt, sieht wie folgt aus:
Diese Syntax zeigt an, dass log4j Funktionen aus „JNDI" bzw. der „Java Naming and Directory Interface" aufrufen wird. Letztendlich kann dies verwendet werden, um auf externe Ressourcen oder „Referenzen" zuzugreifen, was bei diesem Angriff als Waffe eingesetzt wird.
Beachten Sie das „ldap://"-Schema. Dies zeigt an, dass das Ziel über das LDAP-Protokoll einen Endpunkt erreicht (im Falle dieses Angriffs einen vom Angreifer kontrollierten Ort). Der Kürze halber müssen wir hier nicht alle Einzelheiten und Details von LDAP behandeln, aber wissen Sie, dass wir damit arbeiten müssen, während wir unseren Angriff verfeinern. Für den Moment wissen Sie, dass das Ziel tatsächlich eine Verbindung zu einem externen Ort herstellen wird. Dies wird durch den Platzhalter ATTACKERCONTROLLEDHOST in der obigen Syntax angezeigt. Sie, die Sie in diesem Szenario als Angreifer agieren, können einen einfachen Listener hosten, um diese Verbindung zu beobachten.
Die nächste Frage ist: Wo könnten wir diese Syntax eingeben? Überall dort, wo Daten von der Anwendung protokolliert werden.
Das ist der Kern dieser Schwachstelle. Leider ist es sehr schwer zu bestimmen, wo die Angriffsfläche für verschiedene Anwendungen liegt, und folglich, welche Anwendungen tatsächlich verwundbar sind. Das bloße Vorhandensein von log4j-Dateien gibt keinen Aufschluss über die genaue Versionsnummer oder auch nur darüber, wo oder wie die Anwendung das Paket verwendet.
Andere Orte, an denen Sie diese JNDI-Syntax angeben könnten:
Wenn Sie weitere Informationen zu diesem JNDI-Angriffsvektor wünschen, lesen Sie bitte diese Black-Hat-USA-Präsentation aus dem Jahr 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
