Certitude Consulting GmbH
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 – also mit Cloudflare Cloudflare umgehen. 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.
Cloudflare ist ein großer Anbieter aus dem Bereich der Cybersicherheit, der gehostete Website-Schutzdienste 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. Das ermöglicht eine Analyse des Datenverkehrs auf böswillige Aktivitäten. 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 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. Das ist 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. Daher haben wir uns entschieden, 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.
Mit Cloudflare Cloudflare umgehen: Übersicht über die Schwachstelle
Cloudflare skizziert in ihrer offiziellen Dokumentation auf verschiedenen Ebenen des OSI-Modells verschiedene Mechanismen. Das soll „Angreifer daran 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. Doch der Datenverkehr von anderen Parteien soll abgelehnt werden.
Wir demonstrieren in diesem Bericht, dass Angreifer dieses Vertrauen in Cloudflare missbrauchen können, indem sie ihren Schadcode über die Cloudflare-Plattform senden. Dabei umgehen sie verschiedene Schutzmechanismen (z. B. die Web Application Firewall), 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. In der Dokumentation zur Zoneneinrichtung 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“ anstelle eine mandantenspezifische benutzerdefinierten CA besteht darin, dass alle von Cloudflare ausgehenden Verbindungen zulässig sind. Das ist 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 diesen muss der Kunde seine eigenen Origin-Server Zertifikats-Infrastruktur erstellen und verwalten.
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 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 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. Hier soll 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, 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
Mit Cloudflare Cloudflare umgehen: 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 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.
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)
Dieser Beitrag von Stefan Proksch erschien erstmals auf dem Blog von Certitude Consulting.
