Vor einigen Wochen stellte die Nachricht von den Sicherheitsproblemen von Log4j viele Benutzer im Netzwerk auf den Kopf und es ist eine der Schwachstellen, die am meisten ausgenutzt wurde und die von vielen Experten als "die gefährlichste seit langem" bezeichnet wurde. Von den Schwachstellen, die im Netzwerk bekannt wurden, sprechen wir über einige davon hier auf dem Blog und diesmal haben wir die Nachricht von einem anderen gefunden.
Und das ist es vor ein paar Tagen es wurde die Nachricht veröffentlicht, dass eine weitere Schwachstelle in der Log4j 2-Bibliothek identifiziert wurde (die bereits unter CVE-2021-45105 gelistet ist) und die im Gegensatz zu den beiden vorherigen Ausgaben als gefährlich, aber nicht kritisch eingestuft wurde.
Das neue Problem erlaubt einen Denial-of-Service und äußert sich in Form von Loops und anormalen Abbrüchen beim Bearbeiten bestimmter Zeilen.
Verletzlichkeit wirkt sich auf Systeme aus, die die Kontextsuche verwenden, wie z. B. $ {ctx: var}, um das Protokollausgabeformat zu bestimmen.
Die Log4j-Versionen 2.0-alpha1 bis 2.16.0 hatten keinen Schutz gegen unkontrollierte RekursionWelche erlaubt einem Angreifer, den bei der Substitution verwendeten Wert zu manipulieren um eine Endlosschleife zu verursachen, die auf dem Stack keinen Platz mehr hat und den Prozess zum Stillstand bringen würde. Insbesondere trat das Problem beim Ersetzen von Werten wie "$ {$ {:: - $ {:: - $$ {:: - j}}}}" auf.
Zusätzlich Es ist festzuhalten, dass Blumira-Forscher einen Angriff auf verwundbare Java-Anwendungen vorgeschlagen haben die keine Anfragen von externen Netzen annehmen, beispielsweise Systeme von Entwicklern oder Benutzern von Java-Anwendungen, können auf diese Weise angegriffen werden.
Das Wesen der Methode besteht darin, dass bei anfälligen Java-Prozessen auf dem System des Benutzers, die Netzwerkverbindungen nur vom lokalen Host (localhost) akzeptieren oder RMI-Anfragen verarbeiten (Remote Method Invocation, Port 1099), der Angriff kann durch ausgeführten JavaScript-Code ausgeführt werden wenn der Benutzer eine schädliche Seite im Browser öffnet. Um bei einem solchen Angriff eine Verbindung zum Netzwerkport einer Java-Anwendung aufzubauen, wird die WebSocket-API verwendet, auf die im Gegensatz zu HTTP-Anfragen keine Same-Origin-Restriktionen angewendet werden (WebSocket kann auch verwendet werden, um Netzwerkports auf der lokalen Seite zu scannen). Host, um verfügbare Netzwerktreiber zu ermitteln).
Interessant sind auch die von Google veröffentlichten Ergebnisse der Auswertung der Schwachstellen der Bibliotheken im Zusammenhang mit Abhängigkeiten von Log4j. Laut Google betrifft das Problem 8% aller Pakete im Maven Central-Repository.
Insbesondere 35863 Log4j-bezogene Java-Pakete mit direkten und indirekten Abhängigkeiten waren Schwachstellen ausgesetzt. Log4j wiederum wird nur in 17% der Fälle als direkte Abhängigkeit der ersten Ebene verwendet, und in 83% der von der Schwachstelle abgedeckten Pakete erfolgt die Bindung über Zwischenpakete, die von Log4j abhängen, also tell. Abhängigkeiten der zweiten und höchsten Ebene (21% - die zweite Ebene, 12% - die dritte, 14% - die vierte, 26% - die fünfte, 6% - die sechste).
Die Reparaturrate der Schwachstelle lässt noch zu wünschen übrig, eine Woche nachdem die Schwachstelle identifiziert wurde, wurde das Problem von 35863 identifizierten Paketen bisher nur in 4620, also zu 13%, behoben.
Änderungen an Paketen sind erforderlich, um Abhängigkeitsanforderungen zu aktualisieren und alte Versionsbindungen durch feste Versionen von Log4j 2 zu ersetzen (Java-Pakete üben die Bindung an eine bestimmte Version und nicht an einen offenen Bereich, der die Installation der neuesten Version ermöglicht).
Die Behebung der Schwachstelle in Java-Anwendungen wird dadurch erschwert, dass Programme oft eine Kopie der Bibliotheken mitliefern und es nicht ausreicht, die Log4j 2-Version in den Systempaketen zu aktualisieren.
In der Zwischenzeit hat die US-Agentur für Infrastrukturschutz und Cybersicherheit eine Notfallrichtlinie erlassen, die Bundesbehörden verpflichtet, von der Log4j-Schwachstelle betroffene Informationssysteme zu identifizieren und Updates zu installieren, die das Problem vor dem 23. Dezember beheben.
Andererseits wurde bis zum 28. Dezember eine Richtlinie vorgegeben, in der die Organisationen verpflichtet waren, über die geleistete Arbeit zu berichten. Um die Identifizierung problematischer Systeme zu vereinfachen, wurde eine Liste von Produkten erstellt, bei denen die Manifestation einer Schwachstelle bestätigt wurde (die Liste enthält mehr als 23 Anwendungen).
Schließlich Erwähnenswert ist, dass die Schwachstelle in Log4j 2.17 behoben wurde, das vor einigen Tagen veröffentlicht wurde und Benutzern, die die Updates deaktiviert haben, wird empfohlen, das entsprechende Update durchzuführen, außerdem wird die Gefahr der Schwachstelle dadurch gemildert, dass sich das Problem nur auf Systemen mit Java 8 manifestiert.
Quelle: https://logging.apache.org/