Introduction
CloudFlare is a complete solution offering Content Deliver Network (CDN) style capabilities along with Web Application Firewalls (WAF). It's also a market leading solution for Distributed Denial of Service (DDoS) mitigation for websites. CloudFlare works by placing its server arrays in front of a website and determines whether or not to allow traffic to pass through. For a more detailed listing of capabilities, please read CloudFlare's own Blog.
In order for the system to remain effective, all traffic must pass through the CloudFlare network. If we are able to directly connect to end systems, we can often bypass the WAF or target specific systems for traffic shaping or DoS attacks.
Existing Techniques
There has been some effort in the past to unmask servers hiding behind CloudFlare. One website in particular maintains a database of IPs that appear to have been exposed. Not all of their techniques are public, and there appears to be a large gap in most of their data.
Many have also used historical DNS records to track previously exposed systems. Forcing a server to send an e-mail for user registration or mailing lists can also expose backend infrastructure. These techniques also create some gaps, and you may only be able to find an IP or two that is still relevant.
Synopsis
When you use CloudFlare to front your website, an SSL/TLS certificate is automatically registered by CloudFlare for your domain. This means that traffic going to your site is initially encrypted when it hits CloudFlare's servers. From there, traffic may very well be in plain text back to your server. Many sites opt to have their own certificates to protect the second half of the transaction.
In order to maintain a trusted certificate, you must prove to some level of degree that you are the owner of a domain. This burden of proof, and trust mechanism makes it easy to associate true server IPs to CloudFlare protected domains. By utilizing large data sets that have been scraped from the Internet, it's possible to find non-CloudFlare servers by associating previously generated certificates with live hosts.
Censys.io
Censys.io is a great resource that relies on data sets from Scans.io. Both are incredible repositories of information that have been gathered by scanning the Internet at regular intervals. There are multiple types of scans from dns and ftp to http/https scans of all public IPv4 space. Censys has graciously offered a public API for researchers to use. We are going to use the scraped certificates from across the Internet to identify potential servers hiding behind CloudFlare.
Cloudsnare
You'll need to utilize your API credentials after registering with Censys. These can be found under My Account. The only Python requirement is censys's maintained PIP package.
pip install censys
Example
./cloudsnare.py zoomit.ir
Certificates:
Host: *.zoomit.ir zoomit.ir
Fingerprint: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
Hosts: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
Found host: 192.95.47.224
Found host: 94.182.183.50
Examining Top Domains
I downloaded a top million list of domains from Statvoo. From there, I extracted the top 50k domain names, and ran scans to see which domains were using cloudflare. I stopped the scanning once the list was close to 9000 (9038). I then modified the cloudsnare script to add a soft form of rate-limiting. The numbers are not exact, as I did hit a few exceptions here and there in the script, but I was able to observe at least 1842 domains that leak some sort of IP address based on public certificate data. That's right at ~20% of top domains being affected. Note: I did not go through and check every domain for types of systems exposed, or weed out any false positives.
List of domainsMitigation
CloudFlare has a great blog post about keeping your IP space private. You should restrict inbound traffic to your HTTP/HTTPs ports, and only allow connections from CloudFlare IPs. If you are worried about CloudFlare changing IP space, you can use your host's default domain while registering certificates. For instance in AWS, you might have an issued domain from your service provider similar to ec2-54-78-80-22.us-west-2.compute.amazonaws.com. Traffic will still be encrypted between your host and CloudFlare, but won't expose any of your systems to this technique.
pip insall censys -> pip install censys typo!
ReplyDeleteGood catch -- fixed!
DeleteOne thing that I've spent some time doing, and has successfully worked for me in the past, is doing a HEAD request against the target domain, and the twiddling the Host header through ip addresses until you find the IP address that returns the matching headers. It can be difficult though since a lot of systems return 200 codes for domains they aren't configured for. But tons of people don't bother to read the Cloudflare docs telling them how to setup their firewalls to prevent this leak. I was tentatively calling it Cloudglare while working on it -- a distributed system for finding targeted CF-protected sites on the internet.
ReplyDeleteP.S. Good to see you writing again, pal. Hope all is well.
Good one!
ReplyDeleteWorks like a charm! Thanks!!!
ReplyDeleteWe also have a free and open API for this on Cloudsearch - https://cloudsearch.cf
ReplyDelete