How Not to Use Cloudflare

2024/04/02

Cloudflare is a DDoS mitigation platform which offers free proxying of your origin server. Unfortunately, this proxying is not well-used by some people, such as the person who inspired me to make this blog post. He has since fixed it. On Sunday, me and a friend of mine have exposed a vulnerability to one of our other friends, which we will be referring for privacy reasons as X. X has agreed to the “hacking” of his website.

What is Cloudflare proxying?

In order to mitigate DDoS attacks, Cloudflare must proxy your website throught one of their many proxy servers. This means, Cloudflare accesses your website instead of your user. While this may be a privacy concern, we will not adress it as it is not the point of this document, instead, I direct you to https://0xacab.org/dCF/deCloudflare/-/blob/master/README.md.

The issue

The person configured his webserver incorectly, and instead of denying all of the requests from IPs that are not of Cloudflare (see https://cloudflare.com/ips/), it allows any traffic on port 80. Port 80 is the default web port for unencrypted traffic. The individual did not have an SSL certificate, instead relying on one provided by Cloudflare. This is not reccomended and was used as part of the attack vector.

Due to the fact that they allow all IPs to request port 80, if we have his origin IP, which was easily found via https://search.censys.io/, we could send a direct request to the server. Below is showing a direct request to my server, if we access it from the direct IP, without any host headers.

> curl http://107.189.28.28
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

This is the result of sending the same request but with the host header set to fzorb.xyz:

>curl 107.189.28.28 --header "Host: fzorb.xyz"
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

This is the response you get if you try going to http://fzorb.xyz/. It redirects you to the secure version, https://fzorb.xyz/.

But why would you want to bypass the origin?

We had more “humble” motive. The website in question checked your IP address before accessing the website so it wouldn’t be from a certain country to join a Discord guild in order to prevent someone from joining. I found this absurd so I came up with the attack vector, and my friend did the actual exploiting of this vulnerability. This was used to prevent geoblocking. But this could also be used in worse ways, such as impersonating admins on a forum for example. In fact, Stack Overflow in its early days determined admins by their IP address, which in this case was 127.0.0.1. This is not secure at all.

So how does this work?

The webserver knows your IP address via a header called X-Forwarded-For. Cloudflare doesn’t use that header, instead using CF-Connecting-IP. In the absence of Cloudflare, you can set CF-Connecting-IP to any value you want and the Webserver will think it is valid. You could set your ip to values like 1.1.1.1, 1.3.3.7, 69.69.69.69, or maybe even 420.420.420.420, and the webserver can’t know any better.

How do I mitigate it?

You can mitigate it via numerous ways. Here are the 2 ways you can do that:

I hope this blog post has been useful. While I do not use Cloudflare myself, I know many people that do.