Log4j und der allwissende Speicher

Von Trellix · 19. Januar 2022

Von Guilherme Venere, Ismael Valenzuela, Carlos Diaz, Cesar Vargas, Leandro Costantino, Juan Olle, Jose Luis Sanchez Martinez, AC3-Team

Mitarbeiter: Steve Povolny, Douglas McKee, Mark Bereza, Frederick House, Dileep Kumar Jallepalli

Beim Thema Cyber-Sicherheit wird es niemals langweilig. Sehen wir dies als Vorteil und als Chance, das Unternehmen zu stärken.

Experten in aller Welt kämpfen nach wie vor mit der neuesten Bedrohung für Unternehmen, gegen die keine Branche immun ist. Wir haben einen Zuwachs bei den Analysen und beim Patchen der Log4Shell-Schwachstelle in der Java-basierten Protokollierungsplattform Log4j von Apache beobachtet. Dies hat natürlich seinen Grund: Log4j ist bei Entwicklern eine der beliebtesten Protokollierungsanwendungen, wenn nicht DIE beliebteste. Doch Unternehmen dürfen sich nicht nur auf das Patchen konzentrieren. Wir beobachten, dass sich auch Log4Shell als Angriffsfläche verändert.

Das Potenzial für große Schäden und eine Weiterverbreitung dieser Schwachstelle ist hoch. Daher müssen die Folgen schon jetzt ernst genommen werden, um besser zu planen und sich vor der nächsten großen Schwachstelle zu schützen.

Patches sind zwar wichtig, sollten aber keine statische oder einmalige Korrektur darstellen, um die Sicherheit der Infrastruktur zu gewährleisten. Stattdessen muss ein Always-on-Ansatz mit umfassender Überwachung, Bewertung sowie mit Scans und Forensik implementiert werden, um die erforderliche Agilität zur Abwehr der moderneren Bedrohungen von heute zu gewährleisten.

Insbesondere zeigen wir in diesem Beitrag, wie eine Endgerätelösung mit schnellen Speicher-Scan-Funktionen aktive Ausnutzungsszenarios effektiv erkennen und die Netzwerksicherheitsfunktionen Ihres Unternehmens ergänzen kann, um eine neue Art der Resilienz für Ihr Unternehmen zu erreichen.

Hintergrund

Die Experten der Sicherheitsbranche haben registriert, dass rechtzeitig vor den Weihnachtsfeiertagen 2021 die nächste neue Schwachstelle im Zusammenhang mit einer stark genutzten Bibliothek bekannt gegeben wurde. CVE-2021-44228 meldete eine Schwachstelle in der Java-Bibliothek Log4j. Sie betrifft Anwendungen und Websites, die diese Bibliothek für die Protokollierung nutzen.

Durch die Schwachstelle können Angreifer eine anfällige Website oder Anwendung zwingen, schädlichen Java-Code von einem nicht vertrauenswürdigen Remote-Standort zu laden und auszuführen. Der Angriffsvektor variiert, meist sendet der Angreifer dabei jedoch selbstverfasste Zeichenfolgen als Teil eines Netzwerkprotokolls an den Zielrechner, z. B. einen modifizierten HTTP-Header als Teil einer POST-Anforderung.

Aus diesem Grund konzentrieren jetzt viele Sicherheitsexperten ihre Anstrengungen auf die Erkennung schädlicher Zeichenfolgen im Netzwerkverkehr. Zudem erkennen sie, dass proaktives Handeln entscheidend für den Erfolg ist. Netzwerksignaturen können jedoch umgangen werden. Berichte bestätigen, dass Bedrohungsakteure ihre Netzwerkangriffe mit verschiedenen Formen der Verschleierung anpassen, um sich Netzwerk-Scans zu entziehen. Die Abbildung unten zeigt einige der aktuellen Verschleierungstechniken, die im Zusammenhang mit diesem Angriff beobachtet oder gemeldet wurden.

Quelle: https://github.com/mcb2Eexe/Log4j2-Obfucation

Das bedeutet aber nicht, dass Netzwerkschutz-Lösungen nichts gegen diesen Angriff ausrichten können! Vielmehr beweist Log4j, wie wichtig es ist, dass die Sicherheitsexperten genauso anpassungsfähig wie die Angreifer sind und eine neue Ära der lebendigen Sicherheit einläuten – mit einem dynamischeren Ansatz und Denken. Netzwerksicherheitsplattformen stellen eine erste Ebene der Verteidigung dar. Sie müssen im Rahmen einer eingebetteten Sicherheitsarchitektur (Strategie zur Behandlung von Sicherheitsrisiken) eingesetzt und durch weitere Ebenen des Schutzes, der Erkennung, der Transparenz und der Reaktion gestärkt werden.

Moderne Endgerätelösungen sind einzigartig aufgestellt, um netzwerkbasierte Funktionen durch eine tiefgreifende hostbasierte Transparenz bei den Systemprozessen zu ergänzen, z. B. durch speicherinterne Scans und eine schnelle Koordinierung von Reaktionen. Diese Kombination ergibt einen robusten Schutz vor Bedrohungen wie Log4Shell und erlaubt Unternehmen, Vertrauen mithilfe der End-to-End-Sicherheit zurückzugewinnen.

"Ich seh dich": Speicher-Scans #FTW

Speicher-Scans können einen Mehrwert bieten und Netzwerksicherheitsplattformen unterstützen, wenn nach Überwindung der Verschleierungsebenen eine Verbindung auf dem Endgerät ankommt. Das Diagramm unten zeigt den Verlauf eines gängigen webbasierten Log4j-Angriffs.

Er umfasst folgende Schritte:

• Schritt 1: Ein Angreifer sendet eine speziell programmierte Zeichenfolge an den Web-Server, der die anfällige Anwendung hostet. Diese Zeichenfolge kann nach unseren Erkenntnissen so verschleiert werden, dass sie netzwerkbasierte Signaturen umgeht.
• Schritt 2: Die Anwendung entschleiert diese Zeichenfolge, um sie in den Speicher zu laden. Ist dies geschehen, initiiert die Anwendung eine LDAP-Verbindung, um die Adresse für den Standort der schädlichen Klassendatei anzufordern.
• Schritt 3: Der vom Angreifer kontrollierte LDAP-Server sendet daraufhin die HTTP-URL-Adresse des entsprechenden Hosts als Standort der schädlichen Klassendatei.
• Schritt 4: Die anfällige Anwendung initiiert daraufhin den Download der schädlichen Klassendatei.
• Schritt 5: Die anfällige Anwendung lädt die schädliche Klassendatei aus Schritt 4 und führt sie aus. Jetzt führt der Angreifer den Code auf dem Ziel aus und hinterlässt dabei Spuren, die dem Sicherheitsexperten Einblicke in diese Aktivität ermöglichen. Dazu können das Erzeugen weiterer Prozesse oder die Verwendung von Dateien und Registrierungsschlüsseln nach einer Ausnutzung gehören.

Stellen Sie sich vor, wir könnten die Verschleierungstaktiken austricksen? Das ist durchaus möglich – und sogar absolut notwendig – um Bedrohungen wie Log4j zuvorzukommen. Sie können z. B. einen Speicher-Scan an einer bestimmten Stelle der Ausführung auslösen, um die schädliche Code-Datei zu erkennen. Die Wahrscheinlichkeit, die im Prozessspeicher zu diesem Zeitpunkt verwendete entschleierte Zeichenfolge zu finden, ist tatsächlich sehr hoch. Wenn der Speicher gescannt wird, nachdem die schädliche Klassendatei heruntergeladen wurde, wäre dieser Inhalt auch für das Scannen in seiner entschleierten Form verfügbar.

Solche Möglichkeiten machen die Speichersignatur schnell und effizient, wenn man bedenkt, dass das Timing der Erkennung hauptsächlich vom Auslöser abhängt, mit dem der Speicher-Scan gestartet wird.

Expertenregeln für Endgerätesicherheit im Verbund mit Speicher-Scans

Mit unserer Lösung können Unternehmen genau dieses Prinzip anwenden und Speicher-Scans durch eine Expertenregel auslösen.

Expertenregeln sind anpassbare Zugriffskontrollregeln, mit denen Endbenutzer verdächtige Aktivitäten erkennen können, die andere Scanner in der Regel nicht sehen. Darüber hinaus stellen wir spezielle Community-Expertenregeln entsprechend der MITRE ATT&CK-Matrix über unseren öffentlichen GitHub bereit.

Mit diesen Funktionen können wir uns Log4j-anfälligen Anwendungen gezielt widmen und erkennen, wann sie ausgenutzt werden. Sehen Sie sich die folgende Regel an:

Hier sehen wir einen Abschnitt, der AKTEURE (im Abschnitt Process {…}) und ZIELE (im Abschnitt Target {…}) definiert. AKTEURE sind alle Prozesse, die anfällig für den Log4j-Exploit sein können. In diesem Fall sehen wir JAVA.EXE für separate Java-Anwendungen und TOMCAT?.EXE für webbasierte Apache-Anwendungen. Beide Prozesse müssen die Dateien JAVA.DLL und JVM.DLL laden, um sicherzustellen, dass die Java-Laufzeit aktiv ist.

Der Abschnitt Target enthält potenzielle Schaddaten des Angriffs. Da sich Expertenregeln nicht auf Netzwerkverkehr konzentrieren, müssen wir uns auf den letzten Ausführungsschritt konzentrieren, denn dort werden die Schaddaten ausgeführt. Weitere Auslöser wie Dateien oder Registrierungsschlüssel, auf die zugegriffen wird, können hinzugefügt werden, sobald weitere Informationen zu Exploits verfügbar sind. Wie im Beispiel gezeigt, können wir darüber hinaus gültige Verhaltensweisen mit dem Befehlszeilenparameter "Exclude" ausschließen. Dies können Kunden für die gezielte Vermeidung falsch positiver Erkennungen in ihrer Umgebung nutzen, um Bedrohungen noch effizienter zu bekämpfen.

Diese Expertenregel wird ausgelöst, wenn ein ACTOR-Prozess TARGET-Schaddaten erzeugt. Bestimmte Nuancen können Ergebnisse und falsch positive Erkennungen beeinflussen. Sehen Sie sich die folgende Zeile am Anfang der Regel an:

Diese Anweisung initiiert einen Speicher-Scan für den ACTOR-Prozess, der die Expertenregel ausgelöst hat. Jetzt haben wir einen zuverlässigen Auslöser für einen zügigen Speicher-Scan, der keine Leistungseinbußen wie z. B. bei einem blinden Speicher-Scan verursacht. Zudem findet dieser Scan kurz nach dem ersten Ausnutzungsversuch statt. Damit ist garantiert, dass sich die entschleierte Zeichenfolge im Speicher befindet.

Als Nächstes scannen wir den Speicher des Prozesses, der die Expertenregel ausgelöst hat, die vom DAT-Virenschutzmodul (AV DAT-Modul) ausgeführt wird. Sobald diese Zeichenfolge gefunden wurde, beginnt die Erkennung im betroffenen Prozess und die Anwendung der in der REACTION-Zeile der Expertenregel konfigurierten Aktion. Wir empfehlen Ihnen, zunächst die Aktion REPORT zu verwenden, bis Sie geklärt haben, welche Prozesse Sie überwachen müssen.

Das erste gemeldete Ereignis oben ist die Auslösung der Expertenregel für die Erzeugung eines verdächtigen Prozesses aus JAVA.EXE. Das zweite Ereignis ist die AV DAT-Erkennung, die anzeigt, dass der Speicher dieses Prozesses Signaturen des Exploits aufwies.

Hinweis:

Wenn nur das Ereignis für die Expertenregel-Erkennung und NICHT das Ereignis für den Java Naming and Directory Interface (JNDI)/Log4j-Exploit gemeldet wird, würde dies darauf hindeuten, dass ein Programm verdächtige untergeordnete Prozesse ausgeführt hat. In diesem Fall wird Kunden geraten, das Ereignis zu prüfen und die Expertenregel entsprechend zu optimieren.

Wenn jedoch sowohl das Ereignis für die Expertenregel als auch das Ereignis für den JNDI/Log4j-Exploit für das dasselbe Programm ausgelöst werden, haben wir den ausgenutzten Prozess sicher erkannt.

Weitere Informationen über unsere aktuelle Berichterstattung zur Log4j-Schwachstelle finden Sie in KB95901 "Informationen zur Remote-Code-Ausführung mittels CVE-2021-44228 in Apache Log4j". Dieser Artikel enthält Links für den Download der Expertenregel und einer aktualisierten EXTRA.DAT-Datei sowie Details zur Einrichtung von ePO für Ihre Umgebung.

Wenn Sie diese Lösung implementieren möchten, lesen Sie die Anleitungen im KnowledgeBase-Artikel (KB) und in der zugehörigen Dokumentation. Es wird dringend empfohlen, die Expertenregel zu überprüfen und an die eigene Umgebung anzupassen. So verhindern und reagieren Sie nicht nur auf aktive Risiken, sondern passen sich auch dynamisch an, um sich vor veränderten Bedrohungen zu schützen.

Fazit

Für den Schutz einer Umgebung vor Angriffen wie Log4j können die Sicherheitsverantwortlichen zu einer mehrschichtigen, eingebetteten Strategie aus Netzwerksicherheit kombiniert mit gezielten Endgerätespeicher-Scans greifen, um den Verlauf des Angriffs auf anfällige Systeme über Netzwerkvektoren effektiv zu erkennen und abzuwehren. Unsere ENS-Expertenregeln und benutzerdefinierten Scan-Reaktionen sollen Ihnen alle entsprechenden Fähigkeiten an die Hand geben, damit Sie präzise Abwehrmaßnahmen gegen diese neuen Bedrohungen ergreifen sowie die Oberhand und mehr Vertrauen gewinnen können, um Ihr Geschäft zu schützen und auszubauen.