0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter

Sicherheit (Pexels, allgemeine Nutzung)[English]In der zum Logging benutzen Java Bibliothek log4j gibt es eine kritische Schwachstelle, die ungepatcht ist. Diese Software ist in vielen anderen Produkten integriert. Tausende Dienste von Apple, Amazon, Twitter, Minecraft etc. sind über diese Schwachstelle anfällig. Inzwischen wurden bereits erste Angriffe auf Honeypots beobachtet. Hier ein kurzer Überblick, was Sache ist.


Anzeige

Ein Leser hat in einem Kommentar auf dieses Problem hingewiesen, welches u.a. hier beschrieben ist.  Bei log4j handelt es sich um eine Apache-Bibliothek zum Logging für Java. Diese Bibliothek ist wohl sehr leistungsfähig und flexibel und auch recht populär. Daher wird diese Bibliothek in fast jeder Java-Anwendung zur Protokollierung verwendet.

Leider gibt es in log4j eine ungepatchte Schwachstelle in der JNDI-Lookup-Funktion. Die JNDI-Lookup-Funktion von log4j ermöglicht den Abruf von Variablen über das JNDI – Java Naming and Directory Interface. Dabei handelt es sich um eine API, die Java-Anwendungen Namens- und Verzeichnisfunktionen zur Verfügung stellt. Es gibt zwar viele Möglichkeiten, aber log4j unterstützt (AFAIK) LDAP und RMI (Remote Method Invocation).

Schwachstelle CVE-2021-44228

Am 9. Dezember 2021 wurde ein Proof of Concept (PoC) für die Remote Code Execution-Schwachstelle in log4j veröffentlicht. Der PoC benötigt nur wenige Zeilen Code mit dem eine Zeichenkette in Form einer URL in die Protokolldatei schreibt. Der Verzeichnisdienst JNDI kontaktiert darauf hin den im Protokoll aufgeführten LDAP-Server, um von diesem Daten anzufordern. Das kann auch Java-Klassen umfassen, die dann ausgeführt werden. Gelingt es einem Angreifer die URL auf einen von ihm kontrollierten Server in der Protokolldatei anzugeben, kann er einen Server über das Logging kapern (Log4Shell).

Die Schwachstelle CVE-2021-44228 wird laut heise als kritisch bewertet und hat den CVE-Index 10 (von 10 möglichen Punkten) erhalten. Die Pen-Testing-Gruppe 0x0021h, die den PoC-Exploit entwickelte, gibt an, dass dieser für Apache Struts2, Apache Solr, Apache Druid, Apache Flink und funktioniert. Auf dieser GitHub-Seite werden betroffene Dienste aufgelistet – da ist alles dabei, was Rang und Namen hat. Neben Apple iCloud, Amazon, CloudFlare, Steam, Twitter und selbst das populäre Mindcraft ist alles dabei. Laut Bleeping Computer wurde Minecraft aber bereits per Notfall-Patch über die Version Minecraft: Java Edition 1.18.1 geflickt.

Administratoren von Anwendungen sollten nach Updates der Software-Hersteller Ausschau halten und diese zeitnah installieren. Da die Ausnutzung der Sicherheitslücke es erfordert, dass der betroffene Server/Client einen anderen Server im Internet erreicht (der die JNDI-Referenz bereitstellt), können laut SANS-Institute die folgenden Maßnahmen durchgeführt werden:

  • Blockieren des ausgehenden Datenverkehrs, der nicht erforderlich ist. Wer einen Server hat, auf dem eine Java-Anwendung läuft, die nur eingehenden Datenverkehr annehmen muss, sollte der gesamte ausgehende Datenverkehr verhindert werden.
  • Wer den Datenverkehr überprüft, sollte nach LDAP- und RMI-Protokollen suchen und diese filtern.

Ich denke, wir werden in den nächsten Tagen noch über Vorfälle aus dem Bereich eines Angriffs über die log4j-Schwachstelle lesen. CERT Telekom berichtet hier über Angriffsversuche, die man in den eigenen Honeypots beobachtet.

Apache patcht und Gegenmittel

Neben Microsoft, die einen Patch für Minecraft bereitgestellt haben, gibt es von Apache den Patch Log4j 2.15.0 um die Schwachstelle zu schließen. Und es gibt seit dem 10.12.2021 noch ein universelles Gegenmittel der Sicherheitsfirma Cybereason, wie ich bei den Kollegen von Bleeping Computer lese.

Ein auf GitHub bereitgestelltes Script Logout4Shell ermöglicht eine Einstellung in einer anfälligen Log4Shell-Instanz remote zu deaktivieren. Logout4Shell führt den Benutzer durch die Einrichtung eines Java-basierten LDAP-Servers und enthält eine Java-Payload, die die 'trustURLCodebase'-Einstellung in einem Remote Log4j-Server deaktiviert. Dies ermöglicht die Schwachstelle CVE-2021-44228 zu entschärfen.


Anzeige

Während die beste Abschwächung gegen diese Schwachstelle darin besteht, log4j auf 2.15.0 und höher zu patchen, kann dieses Verhalten in Log4j-Versionen (>=2.10) durch das Setzen der Systemeigenschaft log4j2.formatMsgNoLookups auf true oder durch das Entfernen der JndiLookup-Klasse aus dem Klassenpfad abgeschwächt werden, heißt es auf der GitHub-Seite.

Wenn der Server über eine Java-Runtime  Version >= 8u121 verfügt, sind außerdem die Einstellungen com.sun.jndi.rmi.object.trustURLCodebase und com.sun.jndi.cosnaming.object.trustURLCodebase standardmäßig auf "false" gesetzt, wodurch das Risiko einer Ausnutzung gemindert wird. Weitere Details sind der GitHub-Beschreibung zu entnehmen.

Ergänzung: Ich wurde gefragt, ob auch Ports wie log4net etc. betroffen sind. Laut dieser Einschätzung eher nicht.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Antworten zu 0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter

  1. Andy sagt:

    Hm. Das ist übel.
    Von dem Zeug steckt einiges in Systemen, die z.B. im öffentlichen Bereich recht verbreitet sind und die Updatefrequenzen von alle paar Monate haben.
    Und du kriegst "von oben" nie eine Freigabe, da selbst reinzupatchen oder die Läden massiv unter Druck zu setzen.
    Geht also der Dauerstreit zu dem Thema weiter und man mitigiert mit hohem Aufwand vor sich hin…
    Fast wünscht man sich ja, dass es da mal richtig kracht, damit endlich ein Umdenken machbar ist und die Hersteller von Fachsystemen aufhören müssen, sich die kostenlosen Dienste für ihre Systeme zusammenzuklicken und die dann ungepatcht wegaltern zu lassen.

  2. A. Nonym sagt:

    Da kommen jetzt fast minütlich Meldungen:

    https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java

    John Hammond ist einer der aktivesten CTF-Player auf youtube.

  3. Bolko sagt:

    0.
    Einen Proof of Concept gibt es bereits seit 13.März:
    github[.]com/nice0e3/log4j_POC

    1.
    vmware vCenter 7.0.3 ist auch betroffen.
    twitter[.]com/tnpitsecurity/status/1469429810216771589

    2.
    Cryptominer laufen bereits auf gekaperten Servern
    Screenshot der base64 Codierung
    twitter[.]com/GossiTheDog/status/1469322120840708100

    3.
    Test einer App oder eines Servers:

    3a)
    go to canarytokens[.]org/generate#
    choose the Log4shell token
    enter email and any number
    generate token
    copy token

    3b)
    Use that token in search forms, profile data, settings etc. of your apps

    3c)
    Get notified via email when you triggered a reaction

    4.
    Im Prinzip kann sich log4j in jedem beliebigen jar befinden.
    Man müsste in Windows also alle jars zB mit jd-gui dekompilieren und nach log4j durchsuchen.

    5.
    in Linux kann man die installierten rpm-Pakete durchsuchen:
    – rpm2cpio ThatRpmYouInstalled2Yearsago.rpm | cpio -idvm && find . -type f -name *log4j*

    6.
    Github-Projekt, um getarnte (Obfuscated oder base64-codierte) Befehle in den Logs zu enttarnen:
    gist[.]github[.]com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

    "ldap" muss gar nicht im Klartext in der Befehlszeile vorkommen, sondern kann auch umschrieben werden und der Parser erkennt dann trotzdem, was der Hacker meinte. Beispiel für getarnten Code:
    ${jndi:${lower:l}${lower:d}a${lower:p}://loc${upper:a}lhost:1389/rce}

    Solche Tarncodes können auch in Archiven (.gz) stecken.

    Das wird noch spaßig werden, weil log4j weit verbreitet ist, man die Lücke leicht ausnutzen kann und weil man den Befehl nicht unbedingt so leicht erkennen kann, wenn der Hacker ihn getarnt hat, denn der log-Parser ist hoch entwickelt und kann die verschleierten Befehle trotzdem verstehen.

    • Korinther sagt:

      @Bolko
      "Einen Proof of Concept gibt es bereits seit 13.März:
      github[.]com/nice0e3/log4j_POC"

      Da geht es um CVE-2019-17571 und nicht um CVE-2021-44228.

  4. Korinther sagt:

    "Die Schwachstelle CVE-2021-44228 wird laut heise als kritisch bewertet und hat den CVE-Index 10 (von 10 möglichen Punkten) erhalten."

    CVE ist der "Index" bekannter Schwachstellen, die Bewertung des Risikos erfolgt mittels CVSS-"Index". Das eine hat mit dem anderen nichts zu tun.

  5. 1ST1 sagt:

    Hier gibt es eine Liste von IP-Adressen, von denen Angriffe gesteuert werden, könnten natürlich auch gute Sicherheitsforscher sein, wird ständig aktualisiert…

    https://gist.github.com/blotus/f87ed46718bfdc634c9081110d243166

Schreibe einen Kommentar zu A. Nonym Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.