Screenshot of the Cloudflare administration panel showing the Authenticated Origin Pulls option set to On Cloudflare's Authenticated Origin Pulls option

During our regular penetration testing, we occasionally encounter a client who’s both using Cloudflare and seems to have configured it correctly (though as you might imagine, this doesn’t happen often). While most people realize that you can still exploit a client with Cloudflare and their WAF, it certainly makes the job harder.

The “hardened” configuration we’re most likely to see is an origin that is firewalled to only Cloudflare IP addresses, preventing any direct access (HTTP or otherwise), and Authenticated Origin Pulls. Either of these options alone is enough to severely frustrate our ability to test efficiently or exploit the target in many cases.

What’s much less likely is that the client has managed to hide their Origin IP addresses appropriately. There are automated tools to check for this failing (a favorite of mine is to just do a password reset email and check the headers), and in the case of penetration testing, you’re able to just ask the client for the IP addresses in use.

However, most people aren’t aware that simply by having the Origin IP address exposed, even if you have a well-configured firewall and Authenticated Origin Pulls, an attacker can trivially bypass the WAF, caching, and other related functionality in Cloudflare.

Authenticated Origin Pulls is particularly important when taking advantage of the Cloudflare Web Application Firewall (WAF) security features. By using Authenticated Origin Pulls with a restricted-to-Cloudflare configuration, websites can be sure all traffic has been processed by a state of the art Web Application Firewall.

From the description on the help page, you might be forgiven for assuming that Authenticated Origin Pulls will ensure all content goes through your configured security features, but there are ways to avoid this.

Briefly, the feature verifies that the connection came from Cloudflare, and your web server will reject connections that don’t meet this criterion. As you can see from the help page, there is only a single generic certificate that is configured. This means the verification that takes place is not specific to a given client, account, or website.

This allows us to quite easily add a new site to our own personal Cloudflare account, set the Origin IP to the server we wish to attack, and reconfigure this site with our own WAF, cache, and security rules. The firewall will allow us through because the connection comes from Cloudflare. The Authenticated Origin Pull will succeed because the request is signed by Cloudflare. And Cloudflare will respect our WAF rules because the traffic is routed through our site, not the client site.

The last piece of the puzzle has to do with the obvious problem of vhosts. When we set up our custom site, we don’t have access to the client’s domain, so we have to use a fake one. This is only going to allow us to access the default vhost on the origin server.

There might be a way to trick the origin server into misinterpreting the Host header, but we need to ensure that Cloudflare routes our request through our site in their system, which makes this kind of attack unlikely.

Luckily, Cloudflare provides a feature for us – Using Page Rules to Re-Write Host Headers. This lets us rewrite the host header as we like given different domains. We could configure site1.fakedomain.com to be rewritten to site1.com so that when the request gets to the origin server, it’s valid and the host header is set, so we receive the content we want.

The downside to this feature is it is only available on Cloudflare Enterprise, which comes with a hefty price tag of $5000 a month minimum. For a single job, this might not be worth it, but remember you can use this to exploit as many sites as you wish simply by adding subdomains, so the price may be worth it.

What kind of mitigations are there? Well, the first is to note Cloudflare isn’t simply going to ignore every request just because you configured the WAF to be lenient. They’ll be on the lookout for suspicious requests, and if you trigger their detection, who knows what they’ll do.

As a website owner, the most obvious decision is to never expose your Origin IP, but this is easier said than done.

Lastly, Cloudflare has a beta product called Cloudflare Warp which can help mitigate this kind of attack by avoiding exposing your webserver to the internet in the first place.