Log4J Erkennung von Sicherheitslücken (CVE-2021-44228)

Wenn Sie dies lesen, haben Sie sicher schon von CVE-2021-44228 gehört, der Sicherheitslücke für Remote Code Execution (RCE), die Apache Log4j betrifft, die Java-Logging-Bibliothek, die ein Großteil des Internets auf seinen Webservern verwendet. Während in vielen Blogs und Kommentaren Methoden beschrieben wurden, mit denen Sie feststellen können, ob Ihre Webserver/Websites anfällig sind, gibt es nur wenige Informationen darüber, wie Sie leicht feststellen können, ob Ihr Webserver tatsächlich ausgenutzt und infiziert wurde. Doch zunächst eine kurze Zusammenfassung:

CVE-2021-44228 Apache Log4J RCE

• Zunächst einmal, wie die meisten Twitter- und Sicherheitsexperten sagen: Diese Sicherheitslücke ist schlimm. Wirklich schlimm. Viele bekannte Websites verwenden diesen Logger.

• RCE = Remote Code Execution. Der Angreifer kann jeden beliebigen Code (z. B. Malware) auf Ihrem Webserver ausführen, indem er eine Webanforderung an Ihre Website sendet, die nichts weiter enthält als eine "magische" Zeichenfolge und einen Link zu dem Code, den er ausführen möchte.

• Betroffen sind Apache-Webserver, die anfällige Versionen des log4j-Loggers verwenden (das beliebteste Java-Protokollierungsmodul für Websites mit Java).

• Betroffene Versionen: 2.0 - 2.14.1 (Wir empfehlen ein Update auf Version 2.17.0)

Hat jemand versucht, meinen Webserver zu missbrauchen?

Ein typisches Verhalten, das zu erwarten ist, wenn Ihr Server von einem Angreifer ausgenutzt wird, ist die Installation einer neuen Webshell (Website-Malware, die über eine versteckte Administratorschnittstelle Zugriff auf den Server ermöglicht). Apache würde curl- oder wget-Befehle ausführen, um die Webshell oder andere Malware, die installiert werden soll, herunterzuladen.

Glücklicherweise gibt es einige Möglichkeiten, Exploit-Versuche zu erkennen und gleichzeitig den Server zu überwachen, um frühere Exploit-Versuche aufzudecken:

1. Überprüfen Sie die Apache-Protokolle auf jndi:ldap, jndi:rmi oder jndi:dns. Das sind die „magischen Zeichenfolgen“, die den Logger durcheinanderbringen und dazu führen, dass er der darauf folgenden URL folgt bzw. diese ausführt.
2. Scannen /var/log wobei Yara-Signaturen mit einigen dieser Indikatoren übereinstimmen.
3. Scannen Sie den Webserver nach generischen Webshells.
4. Wenn Sie EDR auf dem Webserver einsetzen, achten Sie auf verdächtige curl-, wget- oder ähnliche Befehle. Der Code, den sie nach der Ausnutzung als erstes auszuführen versuchen, besteht wahrscheinlich darin, dass das System mit integrierten Dienstprogrammen wie diesem auf den Befehls- und Kontrollserver zugreift.

HINWEIS: Wenn der Server von automatisierten Scannern ausgenutzt wird (diese werden von den Guten eingesetzt), ist es möglich, dass Sie einen Hinweis auf die Ausnutzung ohne nachfolgende Malware oder Webshells erhalten. Einige Forschungsscanner nutzen die Schwachstelle aus und veranlassen das System, einen einzelnen Ping oder eine DNS-Anfrage zu senden, um dem Forscher mitzuteilen, wer verwundbar war.

Datto-Partner: RMM-Komponente

Datto hat sowohl eine „ Datto RMM “-Komponente für seine Partner als auch ein Community-Skript für alle MSPs veröffentlicht, mit denen Sie die Leistungsfähigkeit und Reichweite Ihres RMM-Systems – unabhängig vom Anbieter – nutzen können, um Systeme zu identifizieren, die sowohl potenziell anfällig sind als auch möglicherweise bereits angegriffen wurden. Das Tool kann zudem versuchen, durch die Anwendung einer bekannten Abhilfemaßnahme vor weiteren Angriffen zu schützen.

Bitte zögern Sie nicht, sich an unser Expertenteam zu wenden, um Hilfe zu erhalten.

UPDATE 22.12:

In der letzten Woche haben wir viele Scanning-Aktivitäten von Sicherheitsscannern, weitreichende Exploit-Aktivitäten aus dem russischen und ukrainischen IP-Raum und viele Exploits von Systemen, die von Elastic-Servern bis hin zu benutzerdefinierten Webservices reichen, gesehen.

Wir haben unseren log4shells-Scanner aktualisiert, um eine bessere Abdeckung von Obfuskationsmethoden zu gewährleisten und die nicht mehr vorhandenen Mitigationsoptionen, die Apache zuvor empfohlen hatte, zu verwerfen. Die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS oder das cli-Argument log4j2.formatMsgNoLookups=True wird viele Angriffsvektoren nicht stoppen.

Außerdem haben wir den Scanner so erweitert, dass er alle Laufwerke überprüft (nicht nur die Systemlaufwerke oder die Laufwerke, auf denen log4j installiert ist), und wir empfehlen, ihn erneut auszuführen, wenn Sie dies in letzter Zeit nicht getan haben.

1. Sucht nach allen .jar-Dateien, die die problematische Datei „JndiLookup.class“ enthalten.
2. Durchsucht das System nach komprimierten und unkomprimierten .log-Dateien mit Indikatoren für einen Angriff im Zusammenhang mit dem „log4shells“-Exploit.
— Der primäre Pfad unter Linux und macOS lautet: /var/log
— Zu den primären Pfaden unter Windows gehören $env:SystemDrive\logs\, $env:SystemDrive\inetpub\ sowie alle Ordner, deren Namen die Begriffe „java“, „log4j“ oder „apache“ enthalten.
3. Wendet zudem Open-Source-Yara-Signaturen auf die Log-Dateien an.

Da es viele Implementierungen von log4j gibt, die in verschiedene Produkte eingebettet sind, ist es nicht immer trivial, die Version der log4j-Erweiterung zu finden. Am einfachsten ist es, sich den Datei- oder Ordnernamen der .jar-Datei anzusehen, die mit der JndiLookup.class gefunden wird, aber das ist nicht immer der Fall. Einige Produkte erfordern spezielle Herstelleranweisungen.

UPDATE 12/14:

Es werden weiterhin Angriffe auf verwundbare Apache-Server durchgeführt, diesmal jedoch mit immer mehr Verschleierungen. Die Angreifer scheinen die veröffentlichten Informationsempfehlungen zu prüfen und ihre Angriffe gegen diese zu testen. Wir haben unsere log4shells/log4j-Exploit-Erkennungserweiterung erheblich aktualisiert, um vorausschauend handeln zu können.

Der Regex-Abgleich in Protokollen kann schwierig sein, wenn die Akteure die Daten verschleiern, aber es ist immer noch eine der effizientesten hostbasierten Methoden, um solche Exploit-Aktivitäten zu finden. Die obige Abbildung zeigt verschiedene Verschleierungen, die wir gesehen haben, und unsere Abgleichslogik deckt sie alle ab. Unser Ansatz bei Regeln wie dieser besteht darin, eine hochgradig abgestimmte und spezifische Regel mit geringen Fehlalarmen und eine andere, allgemeinere Regel zu haben, die darauf abzielt, Fehlalarme auf Kosten von Fehlalarmen zu minimieren. Unsere Jäger kümmern sich im Allgemeinen im Auftrag unserer Kunden um die Auswertung der generischen Ergebnisse.

Darüber hinaus ist die allgemeine Verhaltensüberwachung weiterhin eine primäre Fähigkeit, die keine Updates erfordert. Wenn Apache beginnt, neue curl- oder wget-Befehle auszuführen (Standardaktivität der 2. Stufe), wird dies überprüft.

Wir werden die weitere Entwicklung der Situation beobachten und empfehlen, die log4j-Erweiterung zu Ihren geplanten Scans hinzuzufügen.

UPDATE 12/12:

Wir haben gestern Abend mit einigen unserer Partner zusammengearbeitet und unsere Erweiterung auch für Windows-basierte Apache-Server aktualisiert:

Ein Problem beim Durchsuchen von Protokollen auf Apache-Servern unter Windows besteht darin, dass der Protokollordner nicht standardmäßig festgelegt ist. Unsere Erweiterung sucht daher in <em>[DriveLetter]</em>:\logs\ (auch bekannt als C:\logs\) zunächst, da es sich um einen allgemeinen Ordner handelt; sollten Apache und httpd jedoch laufen und die Datei dort nicht vorhanden sein, wird der Rest der Festplatte durchsucht.

Zudem wird geprüft, ob es .jar-Dateien gibt, die den anfälligen Code importieren. Vorschläge von Partnern aus der Praxis, die nach einer Umgebungsvariable namens log4j2.formatMsgNoLookups Man muss aber auch bedenken, dass es viele Implementierungen gibt, bei denen dieser Wert fest codiert ist und nicht in einer Umgebungsvariablen gespeichert ist.

WICHTIG: Ein Großteil der Aktivitäten, die wir beobachtet haben, stammt von automatisierten Scannern (sei es von Forschern oder anderen), die nicht mit der Auslieferung von Webshells oder Malware oder entsprechenden Auswirkungen einhergehen. Da sich diese Schwachstelle sehr leicht ausnutzen lässt, kann dies zu einer hohen Anzahl an Fehlalarmen führen. Wir bitten daher alle, die nach Ausnutzungsmöglichkeiten suchen, nach weiteren Anzeichen für eine Kompromittierung Ausschau zu halten, bevor sie einen Vorfall aufgrund eines positiven Treffers in den Protokollen melden. Bitte kontaktieren Sie uns, falls Sie bei diesem Schritt auf Schwierigkeiten stoßen.

Sie sind noch kein Datto-Partner? Kontaktieren Sie uns noch heute, um eine Demo anzufordern.