Bypassing Cloudflare WAF
Bypassing Cloudflare WAF
This is a tutorial on how to bypass Cloudflare WAF with the origin server IP
address. Cloudflare is a widely used web app firewall (WAF) provider. But what if
you could bypass all these protections in a second making the defense useless? This
article is a tutorial on bypassing Cloudflare WAF getting the origin server IP
address.
With more than 16M Internet properties, Cloudflare is now one of the most popular
web application firewalls (WAF). A year ago Cloudflare released a fast DNS
resolver, which became the proverbial cherry on top of their service offering.
Working as a reverse proxy, the WAF does not only offer a protection against DDOS
but can also trigger an alert when it detects an attack. For paid subscriptions,
users have the option to turn on protection against common vulnerabilities such as
SQLi, XSS and CSRF, yet this must be manually enabled. This option is not available
for free accounts.
As a hacker bug bounty hunter, it�s obvious that it could be very interesting to
get rid of the firewall. For that, you basically have 3 options:
Alter the requests in a proper way to disrupt the server. And as the same as first
option, it can be time-consuming, requires patience and good fuzzing skills.
Soroush Dalili wrote a nice presentation which could help to create such requests
by Using HTTPS Standard and Web Servers� Behaviour.
Get around Cloudflare by finding the origin IP of the web server.
Probably the easiest option, no technical skills required, it�s also part of the
recon process so no time wasted. As soon as you get it, you don�t have to worry
anymore about the WAF or the DDOS protection (rate limit).
______________________________________________
Reminder: Cloudflare is a tool that has to be set by humans, usually developers or
system administrators. Cloudflare is not responsible for the misconfiguration that
could lead to successful attacks performed using the methods described below.
(still has vulnerabilities)
______________________________________________
1. first, Recon!
The idea is to start your normal recon process and grab as many IP addresses as you
can (host, nslookup, whois, ranges�), then check which of those servers have a web
server enabled (netcat, nmap, masscan). Once you have a list of web server IP, the
next step is to check if the protected domain is configured on one of them as a
virtual host. If not, you�ll get the default server page or the default website
configured. If yes then you found the entry point! Using Burp
Censys
If your target has a SSL certificate (and it should!), then it�s registered in the
Censys database (I strongly recommend to subscribe). Choose �Certificates� in the
select input, provide the domain of your target, then hit <enter>.
3. Mail headers
The next step is to retrieve the headers in the mails issued by your target:
Subscribe the newsletter, create an account, use the function �forgotten password�,
order something� in a nutshell do whatever you can to get an email from the website
you�re testing (note that Burp Collaborator can be used).
Once you get an email, check the source, and especially the headers. Record all IPs
you can find there, as well as subdomains, that could possibly belong to a hosting
service. And again, try to access your target through all of them.
4.
XML-RPC Pingback
This well known tool in WordPress, the XML-RPC (Remote Procedure Call), allows an
administrator to manage his/her blog remotely using XML requests. A pingback is the
response of a ping. A ping is performed when a site A links to a site B, then the
site B notifies the site A that it is aware of the mention. This is the pingback.
5. Previous findings
If you�re not able to find the origin IP using the previous methods or if the
website was not protected when you first started your hunt but finally became
protected, remember that sometimes your best friend is your target itself and it
can give you the information you are looking for.
Basically what you need is that the web server of your target performs a request to
your server/collaborator. Using another type of issue could also be a good idea:
SSRF, XXE, XSS or whatever you already found, to inject a payload that contains
your server/collaborator address and check the logs. If you got any hit then check
the virtual host again.
Even the simplest vulnerabilities like Open Redirect or HTML/CSS injection can be
useful if it�s interpreted by the application web server.
5.1) Tools
For now we have seen how to find and check IP addresses manually, fortunately we
have great developers in our community. Below are some tools that are supposed to
do the job for you, and these could save your precious time. You can include them
in your recon process as soon as you detect a Cloudflare protection.
Note, that none of these methods are 100% reliable as all targets are different and
what will work for one, may not work for another. My advice: try them all.
(available on Github)
Cloudsnare.py: censys certificates (key required)
HatCloud: crimeflare, ipinfo.io
CrimeFlare: crimeflare, ipinfo.io
bypass-firewalls-by-DNS-history: securitytrails, crimeflare
Netcraft: https://toolbar.netcraft.com/site_report?url=
dns-trails: https://securitytrails.com/dns-trails
DNSQueries: https://www.dnsqueries.com/en/domain_check.php
DNSdumpster: https://dnsdumpster.com/
Shodan: https://www.shodan.io/search?query=
____________________________________________