Cloudflare WAF Hunting

Cloudflare waf hunting at scale using one simple trick! Click now to find out more…

Feel free to ignore the above, wanted to make it look cool for the subtitle.

When performing various pentests, I have discovered a specific quirk (whether or not others know about this, I don’t know, but if so, great, I’m going to share the information anyway.)

I am not too experienced with understanding how wafs work, but we can assume that they function in a way that all traffic sent to a target application first goes through them, likely as a sort of proxy. This basically boils down, too: Cloudflare lays over the top of your application, looks at requests, and forwards them appropriately, or blocks if it sees things it doesn’t like, an example being a SQL injection payload. Again, I haven’t done research on this, but we will just assume that a service like Cloudflare works as a SaSS platform that is globally operated and not locally deployed. What this means is that Cloudflare itself may have “knowledge” of other applications in its service. Abusing this is quite simple and trivial. With a tool like Burp Suite, we can essentially deploy two methods to just ask Cloudflare if it “knows,” aka if an application is protected by it. Below, I will detail the steps you can expect. I censor as much as possible as this is just a random target, and they don’t need to be disclosed for this, and they wouldn’t care to begin with, as this is not something that will get you a bounty. But this is something you can use for mass recon / knowing what you are up against when actively looking into a target. As this research is going to be published on Medium, we will just make Medium our target for the exercise. Again, this is not EXPLOITATION. This is simply a recon strategy to show a waf that a specific target is using, which could be public knowledge anyway.

Steps:

1. Find an application that already exists/is known on the Cloudflare network.
2. Perform a host header attack aimed at something you know for sure that isn’t on Cloudflare, for example, example.com. We will see a DNS error from Cloudflare in the response body; this means that a normal host header injection attack won’t work; this is what we are looking for and means Cloudflare is, in fact, layered over the top.

Conclusion:
As seen above, it performs the redirect, and we have identified that medium.com is using Cloudflare; this method is a bit “eh” but still can be useful as part of a recon step; the big takeaway for me as a researcher is to expand my mindset as even other sites can be used as the hosts for attacks to detect and understand the attack surface for applications.

Bonus:
HTTP is a hell of a thing; how about instead of using the host header, we target the URL path itself? This works exactly the same and yields the same results; I have censored the host header as the host isn’t relevant. Again, I don’t know the fact on how this works, but to summarize, it is likely because the application is taking this as the true URL because of some funky HTTP stuff; otherwise, the URL would break because it would look like https://example.comhttps://medium.com which, of course, would break in a browser.