Wie Cloudflare Security auf die Log4j-2-Schwachstelle reagiert hat

Wenn wir bei Cloudflare von einer neuen Sicherheitslücke erfahren, stellen wir schnell Teams zusammen, um zwei verschiedene Fragen zu beantworten: (1) was können wir tun, um sicherzustellen, dass die Infrastrukturen unserer Kunden geschützt sind, und (2) was können wir tun, um sicherzustellen, dass unsere eigene Umgebung sicher ist. Als gestern, am 9. Dezember 2021, eine schwerwiegende Sicherheitslücke im beliebten Java-basierten Protokollierungspaket Log4j öffentlich bekannt wurde, wurden unsere Sicherheitsteams sofort aktiv, um auf die erste Frage zu reagieren und die zweite Frage zu beantworten. Dieser Beitrag befasst sich mit der zweiten.

Wie diese Schwachstelle im Detail aussieht, behandeln wir in einem separaten Blogbeitrag: Alle Details zur Log4j2-Sicherheitslücke (CVE-2021-44228), aber zusammenfassend lässt sich sagen, dass diese Sicherheitslücke einem Angreifer die Ausführung von Code auf einem entfernten Server ermöglicht. Aufgrund der weitverbreiteten Nutzung von Java und Log4j ist dies wahrscheinlich eine der schwerwiegendsten Sicherheitslücken im Internet seit Heartbleed und ShellShock. Die Sicherheitslücke wird geführt als CVE-2021-44228. In der CVE-Beschreibung heißt es, dass die Schwachstelle Log4j2 <=2.14.1 betrifft und in 2.15 gepatcht ist. Die Schwachstelle betrifft zusätzlich alle Versionen von log4j 1.x; diese ist jedoch End of Life und hat andere Sicherheitslücken, die nicht behoben werden. Ein Upgrade auf 2.15 ist die empfohlene Maßnahme. In diesem Beitrag erfahren Sie außerdem, wie wir unsere WAF-Regeln aktualisiert haben, um unsere Kunden zu schützen: CVE-2021-44228 - Log4j RCE Zero-Day-Abwehr

Eines der ersten Dinge, die wir tun, wenn wir auf einen Vorfall reagieren, ist, einen Zeitplan der Ereignisse zu erstellen, die wir im Kontext der Situation überprüfen und verstehen müssen. Einige Beispiele aus unserer Zeitleiste sind hier zu finden:

• 2021-12-09 16:57 UTC - Hackerone-Bericht über Log4j RCE auf developers.cloudflare.com erhalten

• 2021-12-10 09:56 UTC - Erste WAF-Regel an Cloudflare Specials-Ruleset ausgeliefert

• 2021-12-10 10:00 UTC - Formaler technischer VORFALL (INCIDENT) wird eröffnet und die Arbeit beginnt, um Bereiche zu identifizieren, in denen wir Log4j patchen müssen

• 2021-12-10 10:33 UTC - Logstash mit Patch zur Behebung der Sicherheitslücke bereitgestellt.

• 2021-12-10 10:44 UTC - Zweite WAF-Regel ist live als Teil der von Cloudflare verwalteten Regeln

• 2021-12-10 10:50 UTC - Neustart von ElasticSearch beginnt mit Patch zur Behebung der Sicherheitslücke

• 2021-12-10 11:05 UTC - Der Neustart von ElasticSearch ist abgeschlossen und nicht mehr verwundbar.

• 2021-12-10 11:45 UTC - Bitbucket ist gepatcht und nicht mehr gefährdet.

• 2021-12-10 21:22 UTC - Hackerone-Bericht als informativ geschlossen, nachdem er nicht reproduziert werden konnte

Eine wichtige Frage beim Umgang mit jeder Software-Sicherheitslücke, und vielleicht sogar die schwierigste Frage, die jedes Unternehmen in diesem speziellen Fall beantworten muss, ist: An welchen Stellen wird die anfällige Software tatsächlich ausgeführt?

Wenn sich die Schwachstelle in einer proprietären Software befindet, die von einem Unternehmen für den Rest der Welt lizenziert wurde, ist das leicht zu beantworten - man muss nur diese eine Software finden. Aber in diesem Fall war das viel schwieriger. Log4j ist eine weit verbreitete Software, mit der jedoch Personen, die keine Java-Entwickler sind, wahrscheinlich nicht vertraut sind. Unsere erste Maßnahme bestand darin, uns erneut mit allen Stellen in unserer Infrastruktur vertraut zu machen, an denen wir Software auf der JVM ausführen, um festzustellen, welche Softwarekomponenten für dieses Problem anfällig sein könnten.

Wir waren in der Lage, ein Inventar aller Software zu erstellen, die auf der JVM läuft, indem wir unsere zentralisierten Code-Repositories nutzten. Anhand dieser Informationen haben wir jede einzelne Java-Anwendung untersucht und festgestellt, ob sie Log4j enthält und welche Version von Log4j darin kompiliert wurde.

Wir haben festgestellt, dass unsere ElasticSearch-, LogStash- und Bitbucket-Instanzen des anfälligen Log4j-Pakets zwischen den Versionen 2.0 und 2.14.1 enthalten. Wir konnten die in der offiziellen Log4j-Sicherheitsdokumentation beschriebenen Abwehrstrategien anwenden, um das Problem zu beheben. Für jede Instanz von Log4j haben wir entweder die Klasse JndiLookup aus dem Klassenpfad entfernt:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Oder die abwehrende Systemeigenschaft in der log4j-Konfiguration eingestellt:

log4j2.formatMsgNoLookups

Mit diesen Strategien konnten wir das Problem in diesen Paketen schnell abschwächen, während wir auf die Veröffentlichung neuer Versionen der Pakete warteten.

Noch bevor wir die Liste der internen Stellen erstellt hatten, an denen die anfällige Software lief, haben wir uns externe Berichte angesehen - von HackerOne, unserem Bug Bounty-Programm und einem öffentlichen Beitrag auf GitHub, der darauf hindeutete, dass wir möglicherweise gefährdet sind.

Wir haben mindestens zwei Berichte gefunden, die darauf hindeuten, dass Cloudflare verwundbar und gefährdet ist. In einem der Berichte war der folgende Screenshot zu sehen:

Dieses Beispiel zielt auf unsere Entwicklerdokumentation, die auf https://developer.cloudflare.com gehostet wird. Auf der rechten Seite zeigt der Angreifer, dass eine DNS-Abfrage für die Nutzdaten, die er an unseren Server gesendet hat, empfangen wurde. Die hier angegebene IP-Adresse ist jedoch 173.194.95.134, die zu einem Google-eigenen IPv4-Subnetz (173.194.94.0/23) gehört.

Die Entwicklerdokumentation von Cloudflare wird als Cloudflare Worker gehostet und stellt nur statische Inhalte bereit. Das Repository ist öffentlich. Der Worker stützt sich auf die Analytics-Bibliothek von Google, wie hier zu sehen ist. Daher gehen wir davon aus, dass der Angreifer keine Anfrage von Cloudflare erhielt, sondern über die Server von Google.

Unsere Backend-Server erhalten Protokolle von Workers, aber auch in diesem Fall war eine missbräuchliche Nutzung nicht möglich, da wir robuste Kubernetes-Egress-Richtlinien einsetzen, die Aufrufe an das Internet verhindern. Erlaubt ist nur die Kommunikation mit einer begrenzten Anzahl von internen Diensten.

Als wir eine ähnliche Meldung in unserem Programm zur Offenlegung von Sicherheitslücken erhielten und weitere Informationen sammelten, war der Analyst nicht in der Lage, das Problem zu reproduzieren. Dies bestärkte uns in unserer Annahme, dass es sich um Server von Drittanbietern handelte, die das Problem möglicherweise behoben haben.

Obwohl wir die oben beschriebenen Versionen der Software einsetzten, glauben wir nicht, dass Cloudflare kompromittiert wurde, dank unserer schnellen Reaktion und unseres Defense-in-Depth-Ansatzes (Ansatz der Tiefenverteidigung). Wir haben erhebliche Anstrengungen unternommen, um dies zu überprüfen, und wir werden weiter daran arbeiten, bis alles über diese Sicherheitslücke bekannt ist. Hier etwas nähere Informationen über diesen Teil unserer Bemühungen.

Während wir daran arbeiteten, alle Kontexte zu bewerten und zu isolieren, in denen die anfällige Software ausgeführt werden könnte, und diese zu beheben, begannen wir mit einem separaten Arbeitsablauf, um zu analysieren, ob eine dieser Instanzen missbräuchlich ausgenutzt worden war.  Unsere Erkennungs- und Reaktionsmethodik folgt den branchenüblichen Verfahren zur Vorfallsreaktion und wurde gründlich eingesetzt, um zu überprüfen, ob unsere Assets tatsächlich kompromittiert wurden. Wir haben einen mehrgleisigen Ansatz verfolgt, der im Folgenden beschrieben wird.

Mit der Bestandsaufnahme unserer Assets und unseren Code-Scan-Tools konnten wir alle Anwendungen und Dienste identifizieren, die auf Apache Log4j angewiesen sind. Während diese Anwendungen überprüft und bei Bedarf aktualisiert wurden, führten wir einen gründlichen Scan dieser Dienste und Hosts durch. Der Exploit für CVE-2021-44228 stützt sich auf bestimmte Muster in Protokollmeldungen und Parametern, z. B. \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+. Für jeden potenziell betroffenen Dienst haben wir eine Protokollanalyse durchgeführt, um etwaige Missbrauchsversuche aufzudecken.

Unsere Netzwerkanalyse ermöglicht es uns, verdächtiges Netzwerkverhalten zu erkennen, das auf einen versuchten oder tatsächlichen Angriff auf unsere Infrastruktur hinweisen könnte. Wir haben unsere Netzwerkdaten untersucht, um Folgendes zu ermitteln:

1. Verdächtige ein- und ausgehende AktivitätenDurch die Analyse verdächtiger ein- und ausgehender Verbindungen konnten wir unsere Umgebung durchsuchen und feststellen, ob eines unserer Systeme Anzeichen einer aktiven Gefährdung aufwies.

2. Ins Visier genommene Systeme und DiensteDurch die Nutzung von Musteranalysen unserer Netzwerkdaten konnten wir Systeme und Dienste identifizieren, die von Bedrohungsakteuren ins Visier genommen wurden. Auf diese Weise konnten wir korrelative Suchvorgänge mit unserem Bestandsverzeichnis durchführen und jeden einzelnen Host aufschlüsseln, um festzustellen, ob einer dieser Rechner der Schwachstelle ausgesetzt war oder aktiv missbräuchlich verwendet wurde.

3. NetzwerkindikatorenAus der oben genannten Analyse haben wir Einblicke in die Infrastruktur verschiedener Bedrohungsakteure gewonnen und Netzwerkindikatoren identifiziert, die beim Versuch, diese Schwachstelle auszunutzen, verwendet werden. Ausgehende Aktivitäten zu diesen Indikatoren wurden in Cloudflare Gateway blockiert.

Wir waren in der Lage, unsere Workflows für die Protokollanalyse und die Netzwerkanalyse zu korrelieren, um unsere Endpunktanalyse zu ergänzen. Anhand der Ergebnisse dieser beiden Analysen konnten wir Kriterien für das Scannen von Endpunkten entwickeln, um weitere potenziell betroffene Systeme zu identifizieren und einzelne Endpunkte auf Anzeichen einer aktiven Gefährdung zu analysieren. Wir haben die folgenden Techniken eingesetzt:

Signaturbasiertes Scannen

Wir sind dabei, benutzerdefinierte Yara-Erkennungsregeln einzurichten, um vor der Ausnutzung der Sicherheitslücke zu warnen. Diese Regeln werden im Endpoint Detection and Response Agent, der auf unserer gesamten Infrastruktur läuft, und in unserem zentralisierten SIEM-Tool (Security Information and Events Management) eingesetzt.

Anomale Prozessausführung und Persistenzanalyse

Cloudflare sammelt und analysiert kontinuierlich Endpunkt-Prozess-Ereignisse aus unserer Infrastruktur. Wir nutzten diese Ereignisse, um nach Techniken zu suchen, die nach dem Ausbeuten einer Sicherheitslücke umgesetzt werden, wie z. B. das Herunterladen von Exploits der zweiten Stufe, anomale untergeordnete Prozesse usw.

Bei der Anwendung all dieser Ansätze haben wir keine Hinweise auf eine Kompromittierung gefunden.

In der obigen Analyse haben wir uns auf die Überprüfung von Code und Daten konzentriert, die wir selbst generieren. Aber wie die meisten Unternehmen verlassen wir uns auch auf Software, die wir von Dritten lizenziert haben. Als wir mit unserer Untersuchung in dieser Angelegenheit begannen, stellten wir gemeinsam mit dem IT-Team des Unternehmens eine Liste aller primären Drittanbieter und aller Unterauftragsverarbeiter zusammen, um herauszufinden, ob sie betroffen waren. Wir sind gerade dabei, die Antworten der Anbieter zu erhalten und zu prüfen. Alle Anbieter, die wir als kritisch einstufen und die von dieser Sicherheitslücke betroffen sind, werden deaktiviert und gesperrt, bis sie vollständig behoben sind.

Bei der Reaktion auf diesen Vorfall haben wir mehrere Stellen gefunden, an denen unser Ansatz der Tiefenverteidigung (Defense-in-Depth) funktioniert hat.

1. Beschränkung des ausgehenden Datenverkehrs

Die Einschränkung der Möglichkeit, Aufrufe zu seinem Ursprungsserver zu tätigen („Call Home“), ist ein wesentlicher Bestandteil der Kill-Chain, um den Missbrauch von Sicherheitslücken zu erschweren. Wie bereits erwähnt, nutzen wir die Netzwerkrichtlinien von Kubernetes, um den Zugang zum Internet in unseren Bereitstellungen zu beschränken. In diesem Zusammenhang wird die nächste Stufe des Angriffs verhindert, und die Netzwerkverbindung zu den vom Angreifer kontrollierten Ressourcen wird unterbrochen.

Alle unsere nach außen gerichteten Dienste sind durch Cloudflare geschützt. Die Ursprungsserver für diese Dienste werden über authentifizierte Origin-Pulls eingerichtet. Das bedeutet, dass keiner der Server direkt mit dem Internet verbunden ist.

2. Nutzung von Cloudflare zur Sicherung von Cloudflare

Alle unsere internen Dienste sind durch unser Zero-Trust-Produkt, Cloudflare Access, geschützt. Aus diesem Grund hätte sich der Angreifer nach dem Patchen der begrenzten Angriffsfläche, die wir identifiziert hatten, bei jedem Angriffsversuch auf die Systeme von Cloudflare oder auf Kunden, die Access nutzen, authentifizieren müssen.

Und da wir das WAF-Produkt von Cloudflare als Teil unserer Bemühungen einsetzen, Cloudflare mit Cloudflare zu sichern, haben wir von der ganzen Arbeit profitiert, die zum Schutz unserer Kunden geleistet wird. Alle neuen WAF-Regeln, die zum Schutz vor dieser Schwachstelle geschrieben wurden, wurden mit einer Standardaktion von BLOCK aktualisiert. Wie jeder andere Kunde, der die WAF eingesetzt hat, erhalten wir jetzt Schutz, ohne dass wir etwas unternehmen müssen.

Wir hoffen, dass dieser Überblick über unsere Bemühungen anderen hilft, während wir weiterhin auf diese schwierige Situation reagieren. Wir sind dankbar für all die Unterstützung, die wir von innerhalb und außerhalb von Cloudflare erhalten haben.

Vielen Dank an Evan Johnson, Anjum Ahuja, Sourov Zaman, David Haynes und Jackie Keith, die ebenfalls zu diesem Blog beigetragen haben.