Note: A few minutes before publishing this article, someone brought to my attention that a similar piece had been written a few months ago. I am publishing it nonetheless because I believe it can help raise awareness on the topic (and I spent too much time writing it anyway).

To be clear, this article is not talking about a vulnerability in the Cloudflare service itself, but rather about a configuration mistake commonly made by website owners protecting their website with Cloudflare.

In the past few weeks, I found that multiple websites using Cloudflare were misconfigured, and allowed an attacker to bypass any Cloudflare protection in place easily. Several of the companies behind these websites had more than 1 million users and were among the top companies of their market segment.

Cloudflare allows websites to protect against all sorts of attacks. It can also act as a Web Application Firewall (WAF) to block the exploitation of web-based vulnerabilities such as XSS and SQL injections. It gained even more traction recently by announcing unmetered mitigation of DDoS attacks : Cloudflare is essentially stating they will protect their customers against DDoS attacks of any scale without charging any extra, no matter what pricing plan they are on (including the free one).

Cloudflare is a service that acts as a middleman between a website and its end users, protecting it from various attacks. Unfortunately, those websites are often poorly configured, allowing an attacker to entirely bypass Cloudflare and run DDoS attacks or exploit web-based vulnerabilities that would otherwise be blocked. This post demonstrates the weakness and introduces CloudFlair, an automated detection tool.

In this view, we can see all IPv4 hosts using the SSL certificate whose SHA256 fingerprint is 36f7[…]815a0a.

This simple method to search for IPv4 hosts using SSL certificates issued to a specific domain can be used to find exposed origin servers.

Search for SSL certificates issued to mytarget.tld

Find all IPv4 hosts using one of these certificates

Check if these hosts seem to be origin servers of mytarget.tld

Checking if a host is a (likely) origin

Once we have a list of potential origin servers, the next question is: how do we assess if a host is an origin server of a specific Cloudflare protected domain? There is no silver bullet here since only a company’s sysadmins will be able to tell for sure, but some basic heuristics can help.

First, the IP of the candidate host should not fall into Cloudflare IP ranges, otherwise, we have just found the Cloudflare server which acts as a middleman between the end-users and the origin server. Then, the HTML response of the candidate host should be similar to the response we get when accessing the website using its standard domain name (e.g., mytarget.tld ). I say similar because exact equality is too strict here, since it is common that parts of the same webpage change every time – CSRF tokens, session identifiers, and so on.

Once we find a set of hosts matching these criteria, we can be quite confident we have found a set of exposed origin servers. Of course, these hosts could be very similar to mytarget.tld but actually be development or staging instances. We cannot know with 100 % confidence, but what can help is to browse to the candidate host’s IP directly, and see if it behaves like the production website accessible via mytarget.tld : can you register an account on it? Can you login to an account you created from mytarget.tld , and vice versa? If the answer is yes, you should be pretty confident you found an origin server which shouldn’t be publicly exposed.

Keep in mind that accessing an origin server by entering directly its IP in your browser’s address bar will sometimes not work, as the web server running on it might be expecting an HTTP Host header. When this is the case, you can add a static mapping to your hosts file or query the origin server with a tool like curl or Postman which allows you to set specific Host headers.

Automating the process with CloudFlair

This process can be cumbersome when done manually; to help automate it, I wrote a tool called CloudFlair. It uses the Censys API to search for SSL certificates and associated IPv4 hosts. Once it has retrieved a list of potential origin servers using the method previously described, it will call each one of them and compute the similarity of the response with the response sent by the original domain. It uses a structural similarity function designed on purpose for comparing web pages (described here), since standard string similarity functions such as the Levenshtein distance are too slow to work with strings of the size of a typical web page.

Here’s a sample output.

Once you get a list of likely origin servers, you might still have to make a few manual checks to confirm the result.

Remediation

Update: After Cloudflare’s CTO pointed it out on Twitter, the best mitigation in the future will probably be to use Cloudflare Warp. This feature is currently still in beta, but it’s probably going to be a real game-changer regarding this issue. I did not look into in detail, but essentially it’s allowing you to open a tunnel to a Cloudflare from within a private network (not publicly routable), making sure that only Cloudflare can access your origin server (since it’s not exposed on the Internet).

If your website is vulnerable to the weakness discussed in this post, there is most likely no easy way to fix it. Once the IP of an origin server has leaked, it’s game over. The data used by Censys is versioned, and anyone can download a snapshot of this data at any point in time. What’s more, restricting the incoming traffic on a server is not enough to protect it against DDoS attacks. Dropping traffic at the software level with iptables does not prevent an attacker from sending a large number of packets to the server to consume all the available bandwidth and make it inaccessible to legitimate users.



Below are two steps I would recommend taking.

The first step should prevent the IP address of your origin server from appearing in future Censys scans, and ensure that application-level security features of Cloudflare cannot be bypassed (such as WAF or HTTP endpoint rate limiting).

The second step should (and I believe is the only way to) prevent an attacker from running a DDoS attack against you.

Step 1: Firewall incoming traffic or enable Authenticated Origin Pulls

Configure your origin server only to accept incoming traffic from Cloudflare’s IP ranges. Refer to:

Note: Before applying those steps, make sure you understand that it will prevent you from accessing your origin servers via SSH, RDP, FTP, or any non-HTTP based protocol. Depending on your needs, this might be fine. However, if you still need to access your origin server using one of these protocols, you will need to leave the corresponding ports open.

Another way you can restrict incoming traffic to Cloudflare’s servers is by enabling Authenticated Origin Pulls on your account, and configure your web server accordingly. This feature will make Cloudflare authenticate with a TLS client certificate when talking to your origin server.

Step 2: Change the IP address of your origin server

As stated above, once the IP address of your origin server has leaked, it’s game over. The best solution would be to change it if it is possible, and if DDoS attacks are a credible threat to you. Depending on your hosting provider, this might be easy or painfully hard to achieve.

Acknowledgments

I want to address a big thank you to the people below, for their multiple suggestions and for proofreading this post!