CloudFlare is a cloud security provider, offering WAF and DDoS services as part of its DNS service. When properly configured, the protections between a user and a CloudFlare-secured site can be an effective way of shielding the true IP addresses of an organization’s internet-facing assets and therefore protect them with CloudFlare’s filtering capabilities. Without the direct IP address of the server, an attacker cannot directly access the target and must utilize the (protected) DNS service.

However, as infrastructure and DNS records grow and configurations are modified, things become more problematic.

In this article, we analyze different strategies for subverting the CloudFlare security service and identifying the real IP addresses of cloud targets. We’ll also be introducing a new tool  – CFire – to help security researchers and engineers identify misconfigurations with their own cloud security architecture.

CFire uses various techniques to discover IP addresses behind CloudFlare, and manage the associated data. Although still in its infancy, this tool has been useful in our own cloud penetration tests and would like to share that with the community. We expect it to become much more modular, with the capability to exploit similar misconfigurations in other providers (such as AWS Cloudfront).

After pulling down the CFire script from the Rhino Security Labs Github (link here), we have a couple steps to set things up. First off, lets install/update the CrimeFlaredatabase (we’ll discuss this as one of the techniques below):

CFire’s default lookup technique uses the CrimeFlare archives, creating our own sqlite3 database locally to avoid adding traffic load to the CrimeFlare project site:

Using the tool Sublist3r as a module, we make use of its search engine enumeration functions which work well:

There are many techniques available to researchers who are looking to find IP addresses for targets behind CloudFlare. Most of these are known and documented, but have one thing in common – the leaks mostly occur due to misconfiguration.

CloudFlare operates as both a CDN, caching resources and improving website speed, as well as a cloud security service for the masses. Due to the way the infrastructure is setup, CloudFlare blocks incoming traffic that their filters deem dangerous. The CloudFlare security team has done a great job at keeping up with trends in the security community and continually refining their attack signatures.

Although the service works great for what it is intended, there are those who use it only to hide behind the CloudFlare infrastructure for DDoS mitigation. This method may seem plausible for most websites with simple configurations, but as companies expand and implement new services or technologies, they inadvertently open themselves up to IP discovery.

One of the more common techniques to discovering IP addresses behind CloudFlare is to find common subdomains or hostnames used for external access to backend services. For a period, CloudFlare would auto-configure a subdomain that, if queried, would expose the IP address of the web server. Many users were unaware of this DNS record’s existence, and that it would be the go-to method of discovery for years. The record in question was “direct-connect.” (e.g., direct-connect.domain.com)

As DDoS attacks became more common against its users, CloudFlare eventually replaced this ‘bypass subdomain’ with something more random (dc-###### — the hashes were replaced with random hex string). While the “direct-connect” subdomain approach may not work for more recently-integrated sites, the vulnerability still exists in older setups.

Not every environment is the same, and some companies prefer to host their mail exchanger (MX) servers for mail transport. According to RFC5321, MX records are used to designate destination mail servers for a domain, by priority.

If a target is not using a third-party mail service, then it is likely their MX servers are on the same network as the web server that is hosted on CloudFlare. In these cases, direct IP address discovery is as simple as executing a DNS query:

Similarly to the MX record lookup technique, there are many situations where organizations need to be able to transfer data from external sources to internal servers. In reality, the proper way of maintaining that relationship is to build a Virtual Private Network (VPN) between origin and destination, allowing remote employees, for example, to transfer files to an internal network securely. Unfortunately, many older infrastructures still require an externally accessible FTP/SCP service, thus widening the chance of an attacker successfully discovering the IP/network they are seeking.

Although CloudFlare has provided access to WebSockets (WS) technology in recent times, there are still many users who are either unaware that the service provides this capability or have not migrated and prefer to use their own WS implementation. The latter is more likely, and the chances for IP discovery are high because WS require a persistent connection between client and server, starting with an initial handshake over HTTP(S).

Users before 2014 did not have access to WebSockets services because the web server that CloudFlare relied on happens to be NGINX, which did not have WS proxying support or modules until the end of 2013. With a bit of testing, they were able to roll out support to all users down to free tier, albeit limited.

While navigating a website dedicated to a niche market, we discovered that although the main site was hosted behind CloudFlare, its WS server was hosted externally.

It turns out that the IP belonging to their WS server was, in fact, hosting their main site:

One of the best archives of research data has to be the CrimeFlare project. Although it slants towards ‘unmasking’ criminals behind the service, it acts as a double-edged sword since attackers would also be able to analyze its data for potential IP discovery leaks.

CrimeFlare doesn’t go into detail as to how it collects their data, but it is safe to assume that they’re doing weekly lookups of a substantial number of domains, correlating nameservers, IP addresses, and SSL certificate information, then grouping it into a database format. They would then run queries against the confirmed CloudFlare hosted domains, looking up common DNS records—as described previously—to discover potential IP addresses.

Fortunately, the CrimeFlare project has made its data available since inception, giving researchers the opportunity to do further analysis on CloudFlare user trends. During development of our CFire project, we took this data and created a sqlite3 database and lookup tool. Below is an example of a lookup from the sqlite3 command line:

Server-Side Request Forgery (SSRF) is a class of vulnerabilities which allow an attacker to make requests to arbitrary destinations (e.g., internal services). Over the years, there has been great research into the topic, SSRF Bible being one of the most comprehensive resources.

Although SSRF vectors can be very contextual to how an application or environment is arranged, it can often play a role in the discovery of IP’s behind CloudFlare.

Our test case is a patched installation of WordPress with a vulnerable version of Nelio AB Testing 4.5.8. The point of this exercise is to prove the SSRF concept, mimicking real-world vulnerable applications today.

The vulnerability in question does not require authentication and can be executed through command line via curl. The vulnerability itself exists in /ajax/iesupport.php, which is part of the aforementioned WP module:

The above code checks to see if $_POST[‘originalRequestUrl’] is part of the request or is set, and if it is, then it sets the $url variable to the value of the parameter. A preg_replace is executed to ensure leading slashes are removed from the $url variable before processing it to a cURL library.

The problem is that there is little input validation or sanitization to assure that the user (attacker) is not trying to request a sensitive resource. Couple that with the lack of authentication checks, and you end up with a situation where the module becomes a vector for SSRF vulnerabilities.

Once the above curl command is executed you will see a request coming in, exposing the IP address of the target web server:

Much like Amazon Web Services S3 Buckets, small changes in configuration can have a big impact on security.

To summarize:

• CloudFlare is a great cloud security tool, offering WAF/DDoS protection by hosting your DNS and protecting the true IP of your domains
• CloudFlare requires proper configuration and maintenance to be its most effective
• Server IPs may still be exposed if moved to CloudFlare from “direct IP” DNS provider
• Subdomains bypassing CloudFlare often exposes all DNS records to bypass attacks

CFire provides security researchers and engineers a myriad of ways to track down the genuine IP Address of an asset while expediting some of the more tedious elements of the process. Our hope is that the research that went into developing this tool will clear up misconceptions regarding what CloudFlare does well and what needs to be configured more carefully to protect your most sensitive data.

>> Download CFire from Rhino Security Lab’s GitHub