{"id":2286,"date":"2023-09-28T10:58:32","date_gmt":"2023-09-28T08:58:32","guid":{"rendered":"https:\/\/certitude.consulting\/blog\/?p=2286"},"modified":"2023-10-05T06:55:03","modified_gmt":"2023-10-05T04:55:03","slug":"cloudflare-verwenden-um-cloudflare-zu-umgehen","status":"publish","type":"post","link":"https:\/\/certitude.consulting\/blog\/de\/cloudflare-verwenden-um-cloudflare-zu-umgehen\/","title":{"rendered":"Mit Cloudflare Cloudflare umgehen"},"content":{"rendered":"\n

Von Cloudflare-Kunden konfigurierte Schutzmechanismen (z. B. Firewall, DDoS-Schutz) f\u00fcr Webseiten k\u00f6nnen aufgrund von L\u00fccken in den mandanten\u00fcbergreifenden Schutzma\u00dfnahmen umgangen werden, wodurch Kunden potenziell Angriffen ausgesetzt sind, welche von Cloudflare verhindert werden sollten.  Angreifer k\u00f6nnen 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 \u00fcberpr\u00fcfen, um sicherzustellen, dass ihre konfigurierten Schutzmechanismen zuverl\u00e4ssig angewandt werden.<\/p>\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Cloudflare ist ein gro\u00dfer 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\u00f6swillige Aktivit\u00e4ten erm\u00f6glichen. Da Kunden von Cloudflare potenziell auf dieses Serviceangebot angewiesen sind, ist es wichtig, den Origin-Server vor jeglichem Zugriff zu sch\u00fctzen, welcher nicht \u00fcber die konfigurierten Reverse-Proxy-Server geroutet wurde. Bei Umsetzung gem\u00e4\u00df der offiziellen Cloudflare-Dokumentation [2] k\u00f6nnen Kunden unwissentlich Mechanismen verwenden, die von Angreifern \u00fcber die Cloudflare-Plattform selbst ausgenutzt werden k\u00f6nnen<\/strong>. Diese Schwachstelle ergibt sich aus der gemeinsamen Infrastruktur, welche allen Mandanten innerhalb von Cloudflare zur Verf\u00fcgung steht; unabh\u00e4ngig davon, ob sie legitim oder b\u00f6sartig sind, und es ihnen erm\u00f6glicht, konfigurierte Sicherheitsma\u00dfnahmen zu umgehen und Kundensysteme ins Visier zu nehmen.<\/p>\n\n\n

\n
\"\"
Cloudflare Origin Server Protection Services visualisiert<\/figcaption><\/figure>\n<\/div>\n\n\n

Dieses Angriffsvektor ist nicht klar dokumentiert, weshalb wir uns entschieden haben, dies im Rahmen von Responsible-Disclosure \u00fcber das Bug-Bounty-Programm an Cloudflare weiterzugeben. Cloudflare hat den Bericht als “informativ” eingestuft und geschlossen. Daher geben wir diese Details \u00f6ffentlich bekannt. Dies soll es Kunden erm\u00f6glichen, ihre Konfigurationen auf die unten beschriebenen Schwachstellen zu \u00fcberpr\u00fcfen.<\/p>\n\n\n\n

\u00dcbersicht \u00fcber die Schwachstelle<\/h2>\n\n\n\n

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 \u00fcberlasten” (Anwendungsschicht, Transportschicht und Netzwerkschicht) . Die Mechanismen sind mit unterschiedlichen Sicherheitsstufen versehen, entweder “m\u00e4\u00dfig sicher” oder “sehr sicher”, sowie den damit verbundenen technischen Herausforderungen. W\u00e4hrend unserer Analyse haben wir festgestellt, dass zwei der vorgeschlagenen Mechanismen auf der Pr\u00e4misse basieren, dass der gesamte von Cloudflare stammende Datenverkehr zum Origin-Server als vertrauensw\u00fcrdig betrachtet wird, w\u00e4hrend der Datenverkehr von anderen Parteien abgelehnt werden soll. Wir demonstrieren in diesem Bericht, dass Angreifer dieses Vertrauen in Cloudflare missbrauchen k\u00f6nnen, indem sie ihren Schadcode \u00fcber die Cloudflare-Plattform senden<\/strong> und dabei verschiedene Schutzmechanismen (z. B. die Web Application Firewall) umgehen, welche ein Kunde m\u00f6glicherweise f\u00fcr seine Umgebung konfiguriert hat. Die effektive Auswirkung dieser Umgehung h\u00e4ngt von der Konfiguration des Origin-Servers des Kunden ab.<\/p>\n\n\n\n

Authenticated Origin Pulls<\/h2>\n\n\n\n

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 \u00fcber den Reverse-Proxy-Server von Cloudflare geroutet werden, zum Origin-Server vorgestellt. Kunden k\u00f6nnen entweder ein “Cloudflare-Zertifikat” oder ein benutzerdefiniertes Zertifikat w\u00e4hlen. In der Dokumentation werden jedoch nicht die Auswirkungen dieser Optionen auf die Sicherheit er\u00f6rtert. Benutzerdefinierte Zertifikate k\u00f6nnen zu diesem Zeitpunkt nur \u00fcber eine API konfiguriert werden. Ohne zus\u00e4tzliche Dokumentation ist davon auszugehen, dass sich potentiell viele Kunden f\u00fcr die einfacheren Weg der Verwendung des Cloudflare-Zertifikats entscheiden werden.<\/p>\n\n\n\n

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\u00e4ssig sind, unabh\u00e4ngig 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\u00fcr diese eigene Domain in seinem Mandanten und tunnelt seine Angriffe durch die Cloudflare-Infrastruktur. Dieser Ansatz erm\u00f6glicht es Angreifern, die Schutzmechanismen des Opfers zu umgehen.<\/strong><\/p>\n\n\n

\n
\"\"
Beispiel f\u00fcr Ausnutzung von gemeinsamen Cloudflare-Zertifikaten<\/figcaption><\/figure>\n<\/div>\n\n\n

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.<\/p>\n\n\n\n

Allowlist Cloudflare IP addresses<\/h2>\n\n\n\n

Wenn den Mechanismus ” Allowlist Cloudflare IP addresses” auf Netzwerkebene verwendet wird, welcher als “m\u00e4\u00dfig 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\u00f6nnen.<\/p>\n\n\n\n

Wie bei \u201eAuthenticated Origin Pull\u201c besteht die undokumentierte schwerwiegende Auswirkung dieses Mechanismus darin, dass alle Verbindungen, welche von Cloudflare stammen, unabh\u00e4ngig vom Mandanten zul\u00e4ssig sind. Ein Angreifer kann eine eigene Domain bei Cloudflare einrichten und den DNS-A-Eintrag auf die IP-Adresse des Opfers setzen. Als N\u00e4chstes deaktiviert er alle Schutzfunktionen f\u00fcr diese eigene Domain und routet seine Angriffe durch die Infrastruktur von Cloudflare, wodurch die vom Opfer konfigurierten Schutzmechanismen umgangen werden.<\/strong><\/p>\n\n\n

\n
\"\"
Beispiel f\u00fcr Ausnutzung von Allowlist Cloudflare IPs<\/figcaption><\/figure>\n<\/div>\n\n\n

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\u00f6glicherweise nicht f\u00fcr alle Kunden verf\u00fcgbar.<\/p>\n\n\n\n

Proof of Concent<\/h2>\n\n\n\n

Im Folgenden wird das Setup f\u00fcr eine erfolgreiche Umgehung einer WAF-gesch\u00fctzten Domain victim.test<\/em> beschrieben, in welcher der Origin-Server 203.0.113.42 <\/em>durch die Verwendung von “Authenticated Origin Pulls” mit dem Cloudflare-Zertifikat sowie “Allowlist Cloudflare IP addresses” gesch\u00fctzt werden soll, basierend auf der offiziellen Dokumentation. Der Angreifer konfiguriert die Domain attacker.test <\/em>ohne WAF-Schutz und legt die gleiche Origin-Server IP-Adresse wie victim.test<\/em> fest. Dies erm\u00f6glicht es dem Angreifer, erfolgreich Anfragen an 203.0.113.42<\/em> via attacker.test <\/em>zu senden, welche bei dem Versuch, dies direkt \u00fcber victim.test<\/em> zu tun, blockiert werden w\u00fcrden.<\/p>\n\n\n\n

Konfiguration des Cloudflare-Kontos des Opfers<\/h3>\n\n\n\n

Domain: victim.test<\/em>
DNS A record points to: 203.0.113.42<\/em>
Cloudflare settings:<\/p>\n\n\n\n