Protection Mechanisms, configured by Cloudflare customers (For example, firewall, preventing DDoS attacks) for websites, may be bypassed due to gaps in firewall security controls, potentially exposing clients to attacks, which Cloudflare should prevent. Attackers can use their own Cloudflare accounts to abuse the trust relationship between Cloudflare and customer websites, making the defense mechanism ineffective. Cloudflare customers should reconsider their origin server security strategy, To make sure, that the protection mechanisms they set up are reliably applied.
Vulnerability overview
Cloudflare describes various mechanisms to "prevent attacks, aimed at discovering and overloading your origin server with requests" in its official documentation on the various layers of the OSI model (application layer, transport layer and network layer). Mechanisms are annotated with varying degrees of security levels, or “moderately safe”, or “very safe”, as well as related technical difficulties. During our analysis we found, that the two proposed mechanisms are based on the assumption, that all traffic to the origin server, coming from Cloudflare, must be trusted, while traffic from other parties must be rejected. We show, that attackers can abuse this trust in Cloudflare, sending your malicious code through the Cloudflare platform, bypassing various protection mechanisms (For example, web application firewall), which the client may have configured for their environment. The effective impact of this workaround depends on the client's original server configuration.
Authenticated Origin Pulls
When using the "Authenticated Origin Pulls" mechanism at the transport level, which Cloudflare documentation describes as "very secure", Cloudflare reverse proxies authenticate to the origin server using a client SSL certificate. The zone setup documentation presents two options for authenticating connections from clients, which are routed through Cloudflare's reverse proxy, to the origin server. Customers can choose either "Cloudflare certificate", or your own certificate. However, the documentation does not discuss the security implications, associated with these options. Also worth noting, that a custom certificate can only be configured using the API. Without additional information it is reasonable to assume, that customers will choose the more convenient option of using a Cloudflare certificate.
A serious consequence of using a generic "Cloudflare certificate" instead of a tenant-specific native CA is that, that all connections are allowed, originating from Cloudflare, no matter, which Cloudflare tenant initiates the connection. An attacker can set up a custom domain with Cloudflare and point the DNS A record to the victim's IP address. The attacker then disables all security features for that own domain in their tenant and tunnels their (or yours) attack (attacks) via Cloudflare infrastructure. This approach allows attackers to bypass security features, victim-minded.
This can only be resolved by using your own certificates, which requires the client to create and maintain its own certificates to authenticate the origin server.
Cloudflare IP Whitelist
When using the "Allow Cloudflare IP Addresses" mechanism at the network level, which Cloudflare documentation describes as "moderately secure", the origin server rejects any connection, not originating from Cloudflare IP ranges. The setup documentation describes, how to configure these ranges using .htaccess or iptables file.
Same as with original request authentication, a serious consequence of this mechanism is that, that all connections are allowed, originating from Cloudflare, regardless of the tenant. An attacker can create his own domain with Cloudflare, forward a DNS A record to the victim's IP address. It then disables all security features for that own domain and sends its (or yours) attack (attacks) via Cloudflare infrastructure, actually bypassing security features, victim-minded.
Currently, this problem can only be mitigated byCloudflare Aegis , which offers dedicated output IP addresses instead of using a shared range of IP addresses. This service may not be available to all clients..
Proof of concept
Below is the setup for successfully bypassing the protected WAF domain victim.test, which tries to protect the origin server 203.0.113.42, using “Authenticated Origin Pulls” with Cloudflare Origin certificate, and “Allowlist Cloudflare IP addresses”, as stated in the official documentation. The attacker simply sets up the attacker.test domain without any WAF protection and sets the same source IP address, same as victim.test. This allows an attacker to successfully send requests to 203.0.113.42 via attacker.test, which would be blocked if trying to do this via victim.test
Victim's Cloudflare account configuration
Domain: victim.test
The DNS A record points to: 203.0.113.42
Cloudflare Settings:
- SSL/TLS encryption mode: "Full (strict)».
- Authenticated origin requests enabled
- Cloudflare Certificate of Origin created.
- Cloudflare Managed WAF Rule Set Enabled
- Basic Cloudflare OWASP WAF ruleset included
- Security level: “I'm under attack” - always use HTTPS enabled.
Victim's original server configuration
- 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
Attackers' Cloudflare account configuration
Domain: attacker.test DNS A record points to: 203.0.113.42 Cloudflare Settings:
- SSL/TLS encryption mode: "Full".
- Authenticated origin requests enabled
- Cloudflare Managed WAF Rule Set Disabled.
- Cloudflare OWASP WAF Core Ruleset Disabled.
- Security level: "Almost off"
Bypass protection
Cloudflare WAF protects the victim's server from potentially malicious input.
> GET https://victim.test/?test=cat /etc/passwd HTTP/2
< HTTP/2 403 Forbidden
Cloudflare redirects potentially malicious input to the victim's source server, bypassing the victim's WAF configuration.
> GET https://attacker.test/?test=cat /etc/passwd HTTP/2
< HTTP/2 200 OK
Recommendations for Cloudflare customers
“‘Allowlist Cloudflare IP addresses’ mechanism’ should be considered as a defense-in-depth measure and should not be used as the sole mechanism to protect origin servers. ‘Authenticated Origin Pulls’ mechanism’ must be configured with your own certificates, not a Cloudflare certificate. When securing origin servers, you should also consider other Cloudflare tenant authentication mechanisms (and not Cloudflare itself), described in the documentation, as well as their various trade-offs (For example, running third party code on sensitive web servers).
We recommend that Cloudflare implement mechanisms to protect against such attacks and warn customers with insecure configurations.”
Timeline of disclosures:
- 2023-03-16: Issue reported by Cloudflare via HackerOne (report 1909867).
- 2023-03-16: Cloudflare acknowledged the problem and closed it (informative bug).
- 2023-09-28: Public disclosure (>180 days).