Kategorien

Mit Cloudflare Cloudflare umgehen

Geschrieben von Stefan Proksch am

Von Cloudflare-Kunden konfigurierte Schutzmechanismen (z. B. Firewall, DDoS-Schutz) für Webseiten können aufgrund von Lücken in den mandantenübergreifenden Schutzmaßnahmen umgangen werden, wodurch Kunden potenziell Angriffen ausgesetzt sind, welche von Cloudflare verhindert werden sollten.  Angreifer können ihre eigenen Cloudflare-Konten verwenden, um die Vertrauensbeziehung zwischen Cloudflare und den Webseiten ihrer Kunden zu missbrauchen, wodurch die Schutzmechanismen unwirksam werden. Cloudflare-Kunden sollten ihre Origin-Server-Schutzstrategie überprüfen, um sicherzustellen, dass ihre konfigurierten Schutzmechanismen zuverlässig angewandt werden.

Einleitung

Cloudflare ist ein großer Anbieter aus dem Bereich der Cybersicherheit, der gehostete Website-Schutzdienste [1] anbietet (z.B. Web Application Firewall (WAF), DDoS-Schutz, Bot-Management). Dies wird durch das Hosting eines Netzwerks von Reverse-Proxy-Servern erreicht, die sich zwischen dem Webserver eines Kunden (im Folgenden als „Origin-Server“ bezeichnet) und seinen Benutzern befinden und eine Analyse des Datenverkehrs auf böswillige Aktivitäten ermöglichen. Da Kunden von Cloudflare potenziell auf dieses Serviceangebot angewiesen sind, ist es wichtig, den Origin-Server vor jeglichem Zugriff zu schützen, welcher nicht über die konfigurierten Reverse-Proxy-Server geroutet wurde. Bei Umsetzung gemäß der offiziellen Cloudflare-Dokumentation [2] können Kunden unwissentlich Mechanismen verwenden, die von Angreifern über die Cloudflare-Plattform selbst ausgenutzt werden können. Diese Schwachstelle ergibt sich aus der gemeinsamen Infrastruktur, welche allen Mandanten innerhalb von Cloudflare zur Verfügung steht; unabhängig davon, ob sie legitim oder bösartig sind, und es ihnen ermöglicht, konfigurierte Sicherheitsmaßnahmen zu umgehen und Kundensysteme ins Visier zu nehmen.

Cloudflare Origin Server Protection Services visualisiert

Dieses Angriffsvektor ist nicht klar dokumentiert, weshalb wir uns entschieden haben, dies im Rahmen von Responsible-Disclosure über das Bug-Bounty-Programm an Cloudflare weiterzugeben. Cloudflare hat den Bericht als „informativ“ eingestuft und geschlossen. Daher geben wir diese Details öffentlich bekannt. Dies soll es Kunden ermöglichen, ihre Konfigurationen auf die unten beschriebenen Schwachstellen zu überprüfen.

Übersicht über die Schwachstelle

Cloudflare skizziert in ihrer offiziellen Dokumentation  [2] auf verschiedenen Ebenen des OSI-Modells verschiedene Mechanismen, um „Angreifer daran zu hindern, den Origin-Server zu entdecken und mit Anfragen zu überlasten“ (Anwendungsschicht, Transportschicht und Netzwerkschicht) . Die Mechanismen sind mit unterschiedlichen Sicherheitsstufen versehen, entweder „mäßig sicher“ oder „sehr sicher“, sowie den damit verbundenen technischen Herausforderungen. Während unserer Analyse haben wir festgestellt, dass zwei der vorgeschlagenen Mechanismen auf der Prämisse basieren, dass der gesamte von Cloudflare stammende Datenverkehr zum Origin-Server als vertrauenswürdig betrachtet wird, während der Datenverkehr von anderen Parteien abgelehnt werden soll. Wir demonstrieren in diesem Bericht, dass Angreifer dieses Vertrauen in Cloudflare missbrauchen können, indem sie ihren Schadcode über die Cloudflare-Plattform senden und dabei verschiedene Schutzmechanismen (z. B. die Web Application Firewall) umgehen, welche ein Kunde möglicherweise für seine Umgebung konfiguriert hat. Die effektive Auswirkung dieser Umgehung hängt von der Konfiguration des Origin-Servers des Kunden ab.

Authenticated Origin Pulls

Bei Verwendung des Mechanismus „Authenticated Origin Pulls“ auf Transportschicht, der in der Cloudflare Dokumentation als „sehr sicher“ bezeichnet wird, authentifizieren sich die Reverse-Proxy-Server von Cloudflare beim Origin-Server mit einem Client-SSL-Zertifikat [3]. In der Dokumentation zur Zoneneinrichtung [4] werden zwei Optionen zur Authentifizierung von Verbindungen durch Clients, die über den Reverse-Proxy-Server von Cloudflare geroutet werden, zum Origin-Server vorgestellt. Kunden können entweder ein „Cloudflare-Zertifikat“ oder ein benutzerdefiniertes Zertifikat wählen. In der Dokumentation werden jedoch nicht die Auswirkungen dieser Optionen auf die Sicherheit erörtert. Benutzerdefinierte Zertifikate können zu diesem Zeitpunkt nur über eine API konfiguriert werden. Ohne zusätzliche Dokumentation ist davon auszugehen, dass sich potentiell viele Kunden für die einfacheren Weg der Verwendung des Cloudflare-Zertifikats entscheiden werden.

Die undokumentierte schwerwiegende Auswirkung der Verwendung eines gemeinsam genutzten „Cloudflare-Zertifikats-Infrastruktur“ [5] anstelle eine mandantenspezifische benutzerdefinierten CA besteht darin, dass alle von Cloudflare ausgehenden Verbindungen zulässig sind, unabhängig davon, welcher Cloudflare-Mandant die Verbindung initiiert. Ein Angreifer kann eine eigene Domain bei Cloudflare einrichten und den DNS-A-Eintrag auf die IP-Adresse des Opfers setzen. Der Angreifer deaktiviert dann alle Schutzfunktionen für diese eigene Domain in seinem Mandanten und tunnelt seine Angriffe durch die Cloudflare-Infrastruktur. Dieser Ansatz ermöglicht es Angreifern, die Schutzmechanismen des Opfers zu umgehen.

Beispiel für Ausnutzung von gemeinsamen Cloudflare-Zertifikaten

Dies kann derzeit nur durch die Verwendung von benutzerdefinierten Zertifikaten behoben werden, bei denen der Kunde seine eigenen Origin-Server Zertifikats-Infrastruktur erstellen und verwalten muss.

Allowlist Cloudflare IP addresses

Wenn den Mechanismus “ Allowlist Cloudflare IP addresses“ auf Netzwerkebene verwendet wird, welcher als „mäßig sicher“ angegeben ist, lehnt der Origin-Server jede Verbindung ab, die nicht aus den IP-Adressbereichen von Cloudflare stammt. Die Setup-Dokumentation [6] dokumentiert, wie diese Adressbereiche mittels einer .htaccess-Datei oder iptables eingerichtet werden können.

Wie bei „Authenticated Origin Pull“ besteht die undokumentierte schwerwiegende Auswirkung dieses Mechanismus darin, dass alle Verbindungen, welche von Cloudflare stammen, unabhängig vom Mandanten zulässig sind. Ein Angreifer kann eine eigene Domain bei Cloudflare einrichten und den DNS-A-Eintrag auf die IP-Adresse des Opfers setzen. Als Nächstes deaktiviert er alle Schutzfunktionen für diese eigene Domain und routet seine Angriffe durch die Infrastruktur von Cloudflare, wodurch die vom Opfer konfigurierten Schutzmechanismen umgangen werden.

Beispiel für Ausnutzung von Allowlist Cloudflare IPs

Dies kann derzeit nur durch die Verwendung von Cloudflare Aegis [7] behoben werden, ein Produkt welches dedizierte Outbound-IP-Adressen bietet, anstatt des gemeinsam genutzten IP-Adressbereichs. Dieser Service ist möglicherweise nicht für alle Kunden verfügbar.

Proof of Concent

Im Folgenden wird das Setup für eine erfolgreiche Umgehung einer WAF-geschützten Domain victim.test beschrieben, in welcher der Origin-Server 203.0.113.42 durch die Verwendung von „Authenticated Origin Pulls“ mit dem Cloudflare-Zertifikat sowie „Allowlist Cloudflare IP addresses“ geschützt werden soll, basierend auf der offiziellen Dokumentation. Der Angreifer konfiguriert die Domain attacker.test ohne WAF-Schutz und legt die gleiche Origin-Server IP-Adresse wie victim.test fest. Dies ermöglicht es dem Angreifer, erfolgreich Anfragen an 203.0.113.42 via attacker.test zu senden, welche bei dem Versuch, dies direkt über victim.test zu tun, blockiert werden würden.

Konfiguration des Cloudflare-Kontos des Opfers

Domain: victim.test
DNS A record points to: 203.0.113.42
Cloudflare settings:

  • SSL/TLS encryption mode: „Full (strict)“
  • Authenticated Origin Pulls enabled
  • Cloudflare Origin Certificate created
  • WAF Cloudflare Managed Ruleset enabled
  • WAF Cloudflare OWASP Core Ruleset enabled
  • Security Level: „I’m under attack“ – Always Use HTTPS enabled

Konfiguration des Origin-Servers des Opfers

  • Cloudflare Origin Certificate installed (SSL/TLS enabled)
  • Authenticated Origin Pulls CA installed (SSLVerifyClient enabled)
  • iptables only allows ingress traffic from Cloudflare IPs on port 443

Konfiguration des Cloudflare-Kontos des Angreifers

Domain: attacker.test
DNS A record points to: 203.0.113.42
Cloudflare settings:

  • SL/TLS encryption mode: „Full“
  • Authenticated Origin Pulls enabled
  • WAF Cloudflare Managed Ruleset disabled
  • WAF Cloudflare OWASP Core Ruleset disabled
  • Security Level: „Essentially off“

Exploit Demonstration

Die Cloudflare WAF schützt den Origin-Server des Opfers vor potenziellem Schadcode.
> GET https://victim.test/?test=cat%20/etc/passwd HTTP/2
< HTTP/2 403 Denied

Cloudflare leitet den potenziellen Schadcode an den Origin-Server des Opfers weiter und umgeht dabei die WAF-Konfiguration des Opfers.
> GET https://attacker.test/?test=cat%20/etc/passwd HTTP/2
< HTTP/2 200 OK

Empfehlung für Cloudflare-Kunden

Der Mechanismus „Allowlist Cloudflare IP addresses“ sollte als Defence in depth betrachtet werden und nicht als einziger Mechanismus zum Schutz von Origin-Servern. Der Mechanismus „Authenticated Origin Pulls“ sollte mit benutzerdefinierten Zertifikaten und nicht mit dem Cloudflare-Zertifikat konfiguriert werden. Andere Mechanismen zur Authentifizierung des Cloudflare-Mandanten (anstelle von Cloudflare selbst), die in der Dokumentation [2] beschrieben werden, sollten beim Schutz von Origin-Servern in Betracht gezogen werden, vor allem in Hinsicht auf ihre technologischen Anforderungen (z.B. das Ausführen von Drittanbieter-Code auf sensiblen Webservern).

Wir würden Cloudflare empfehlen Schutzmechanismen gegen derartige Angriffe zu implementieren und Kunden mit schwachen Konfigurationen zu warnen.

UPDATE 04.10.2023

Am 4. Oktober hat Cloudflare den Schweregrad unseres Schwachstellenberichts von „Informativ“ auf „Hoch“ (7,5) geändert und angekündigt, dass sie Schritte unternehmen werden, um die Dokumentation zu verbessern und das Dashboard zu aktualisieren, um die Verwendung von Per-Hostname und Per-Zone Authenticated Origin Pulls zu fördern, um Origin-Server zu schützen und um Benutzer zu ermutigen, ihre Origin-Server zu schützen, indem sie eine Host-Header-Validierung implementieren und die Vertraulichkeit ihrer Origin-Server-IP-Adresse schützen.

Disclosure Timeline

2023-03-16         Problematik an Cloudflare via HackerOne gemeldet (Bericht 1909867)
2023-03-16         Problematik von Cloudflare bestätigt und als „Informativ“ geschlossen
2023-09-13         Veröffentlichung (>180 Tage)
2023-10-04         Cloudflare ändert Schweregrad von „Informativ“ auf „High“ (7,5)
2023-10-04         Cloudflare kündigt Verbesserungen von Dokumentation und Dashboard an

References

[1] https://www.cloudflare.com/application-services/products/
[2] https://developers.cloudflare.com/fundamentals/get-started/task-guides/origin-health/enterprise/
[3] https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/explanation/
[4] https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/
[5] https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem
[6] https://developers.cloudflare.com/fundamentals/get-started/setup/allow-cloudflare-ip-addresses/
[7] https://blog.cloudflare.com/cloudflare-aegis/

Diese Schwachstelle wurde von Florian Schweitzer und Stefan Proksch identifiziert.