or potentially any other CDN/Reverse Proxy using similar techniques
For those that aren’t aware, Cloudflare is a Content Distribution Network (CDN), with features such as a Web Application Firewall (WAF), content caching, free and automatic SSL/TLS certificates and DDoS protection – most of this for free. And it’s popular! From their website:
More than 26 million Internet properties are on Cloudflare, and our network is growing by tens of thousands each day. Cloudflare powers Internet requests for ~10% of the Fortune 1,000 for more than 1 billion unique IP addresses per day.
You’re most likely going to be dealing with Cloudflare on a webapp assessment, and if the client has not/can not turn off the WAF it’ll be a real pain for you because it’ll block a lot of malicious requests. But it can also come up on external inf jobs where you’re given hostnames, or potentially red team engagements during reconnaissance.
How does it work?
Essentially, Cloudflare acts as a proxy to your hosted web content. You point your domain’s nameservers at Cloudflare’s, and then in your Cloudflare configuration you point the domain name at your origin IP address. Any requests to your domain name will now resolve to a Cloudflare, and the request routed by the host header. To prevent an attacker from accessing your origin directly, Cloudflare suggest to whitelist only their IP address
How do I know if Cloudflare is being used?
The easiest way is to use the Wappalyzer browser plugin, which from my experience is incredibly reliable. If this isn’t an option for whatever reason, you can just try accessing the domain’s IP address directly, and if it returns an error saying ‘Direct IP access not allowed’ and some branding, you’ve got a Cloudflare host. If you want to do this the OSINT way, check the DNS records for the target and see if the A record IP is in any of the Cloudflare ranges (https://www.cloudflare.com/ips/)
Bypass Techniques
This article is not about some obscure WAF bypasses, but instead about techniques to completely bypass the Cloudflare infrastructure – much more convenient for testing!
Discovering Potential Origin IPs
The first step is to enumerate possible origin IPs for the application. The easiest way to do this is to actually ask the client, but if for whatever reason that isn’t an option then there are a few methods you can use:
- Internet-wide scan data
If the application has either previously been live on the internet without the use of Cloudflare, or they did not whitelist the IP addresses to only work with Cloudflare’s IP ranges, then it could be possible to find the origin by SSL certificate. Using Censys and/or Shodan, search for the CN used in a cert. Any usage of this cert (Note: and not using Cloudflare certs) could potentially be the origin server. The tool CloudFlair (https://github.com/christophetd/CloudFlair) automates this task. If no luck with SSL cert, there are a few other possibly more reliable but more involved options:
- Analytics tags – They look like this:
ga('create', 'UA-32804181-23', 'auto'); - Favicon – It is possible to use shodan to search by Favicon hash, which obviously only works when the favicon is unique.
- HTTP Headers / Page title – Along with the Favicon, this can really narrow things down.
- DNS records
If the origin uses the same IP address from before it used cloudflare, there could be historical data disclosing the IP. Securitytrails has a DNS history too which could be used to identify a server’s DNS records from before Cloudflare was added.
Alternatively, it could be possible that another DNS record (such as MX) is disclosing the origin IP. Check all the DNS records and note any IPs that are not Cloudflare IP addresses.
- Application-level issues
Burp Collaborator is a really useful tool for this – especially the plugin collaborator-everywhere. If an IP address makes a pingback DNS request or HTTP request, then it could indicate an origin IP address. My top tip is to add a collaborator payload to the host of an email address you’re registering with, and it almost always gets some kind of pingback. Not always from the correct application, but it’s certainly worth making a note of.
Any kind of external service interaction is ideal as it may be possible to get a pingback to a collaborator server which discloses some origins. It’s also worth noting that some error pages can return origin IP / internal IP addresses, as could some kind of application functionality, so keep your eyes peeled.
Discovering the Real Origin
Once you have a list of potential origins, firstly make sure to remove any Cloudflare IP addresses from the list. If the server is not exclusively whitelisting Cloudflare’s IPs, you should be able to access it directly.
To check if the origin has misconfigured whitelisting, simply route your traffic through Burp and in your proxy options, create a match and replace rule to replace all host headers with your target’s host header. Then open all the IP addresses prefixed with http and https in your browser (the plugin ‘open multiple URLs’ is useful here – https://addons.mozilla.org/en-GB/firefox/addon/open-multiple-urls/) and see if any of them return the target application. If they do – success! You’ve bypassed Cloudflare and can directly access the origin IP without any rate liming, WAF or Cloudflare protections.