Evilflare: Circumventing Cloudflare’s Protection

Cloudflare is a prominent player in web security and infrastructure, providing essential services like content delivery networks (CDNs), DDoS protection, WAF and more. Despite its robustness, vulnerabilities can still emerge.

In this post, we’ll delve into the importance of protecting origin servers and explore three attack scenarios that could potentially bypass Cloudflare’s defenses.

We have called the last of them Evilflare. This medium-high complex attack is based on a zero-day vulnerability, not acknowledged by vendor and which we publish here, along with a mitigation, to prevent third parties from surreptitiously exploiting it.

Cloudflare and Origin Servers

Origin servers are the primary web servers hosting a site’s content. Cloudflare acts as a protective layer by routing traffic between end-users and origin servers, processing requests through its network of edge servers. This setup enables Cloudflare to filter out malicious requests, ensuring that only legitimate traffic reaches the origin server.

In this context, adecuate protection of origin servers is crucial for maintaining the cohesion of the model and prevent that the security provided by Cloudflare being circumvented.

Unprotected origin servers: The First Scenario.

Origin servers that accept connections from any source IP are at risk of being targeted by attackers who want to bypass Cloudflare’s security measures.

This is a major configuration flaw and the attack is relatively trivial. By discovering the real IP addresses of origin servers through methods like DNS bruteforcing, IP history lookups, via server leaks or server errors, attackers can bypass Cloudflare and send their traffic directly to the origin server.

Protecting Origin Servers

Cloudflare customers are quick to learn that, if they do not want to have any problems, the first step must be to properly protect their origin servers. To safeguard origin servers, two primary methods can be employed:

a. IP Filtering: This simpler approach involves allowing traffic only from Cloudflare’s IP addresses. Though it is easier to implement, this method offers less comprehensive protection compared to the alternative.

b. Cloudflare Tunnel: A more secure option is for the origin server to establish a tunnel to Cloudflare, ensuring direct communication between the two. Though more complex to set up, this method provides enhanced protection for origin servers by eliminating exposure to direct attacks.

While the second method is best practice, our experience with the product is that the vast majority of hosts that are protected, and not all of them are, use source IP filtering to Cloudflare’s public addresses.

HTTP Host Header Bypass: The Second Scenario.

Once we are in a common scenario where a server is protected by source IP filtering, HTTP Host header plays a crucial role in the security model.

If attackers could manipulate this header, they can potentially contact to the origin server from another Cloudflare tenant, under its control, bypassing the legitimate tenant protections and mitigations. Cloudflare therefore refuses to allow this header to be modified in its services.

However, an incorrect configuration of the origin server’s web terminator could still allow the attack. Thus, in the case that the origin server ignores the HTTP Host header sent from Clouflare, as happens with some balancers, or in the case that the origin answers all requests from a virtual host by default, an attacker can take advantage of this feature to bypass the security offered by Clouflare.

Evilflare: The Third Scenario

Regrettably, a native Cloudflare’s function presents a zero-day vulnerability, not acknowledged by vendor, that attackers could exploit to attack origin servers properly configured.

Therefore, an origin server that has been correctly configured to only allow contact from Cloudflare IP addresses and where the HTTP header Host is handled correctly, continues to be able to be attacked by bypassing the protections and limitations imposed by Cloudflare.

Evilflare: Abusing Cloudflare’s application logic to attack origin servers

The vulnerability is located in Cloudflare’s Health Check functionality and allows an attacker, using this default feature, to generate targeted HTTP/HTTPS traffic, specifically GET and HEAD requests, towards any origin server and to any TCP port, using legit Cloudflare’s IP addresses.

Although the attacker cannot see the full response generated by the target server, they can discern the HTTP response code (200, 403, 404, 500, etc.) and check if a specific text string is present in the response, allowing blind attacks over tainted inputs.

The attacker also has control over the headers they can include in the request, including Host header, with the exception of the User-Agent header, which they cannot manipulate.

Evilflare: Explotation PoC

Exploitation can be done via the Cloudflare API or via Dashboard.

It is not the aim of this post to go into advanced exploitation, let alone the creation of a complete functional exploit that allows the technique to be used in a real scenario.

As an example, we will simulate a potential exploitation vector using the Dashboard. We will create a new “Health Check” with the following characteristics:

Once created, we can see that the malicious payload (/index.php?id=1'+UNION+SELECT+2+FROM+TABLE--) is indeed received on the origin server (185.X.Y.Z), with the desired HTTP Host header (we-are-not-google.google.es) and from an IP address owned by Cloudflare (172.70.59.4).

# while true; do cat web.http | nc -l 8000; done
GET /index.php?id=1'+UNION+SELECT+2+FROM+TABLE-- HTTP/1.1
Host: we-are-not-google.google.es
User-Agent: Mozilla/5.0 (compatible;Cloudflare-Healthchecks/1.0;+https://www.cloudflare.com/; healthcheck-id: 7[DELETED]0)
Cookie: This is a PoC Value
Accept-Encoding: gzip

# tcpdump port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:51:13.173136 IP 172.70.59.4.11150 > [DELETED].com.irdmi: Flags [DELETED]

Evilflare: Impact

This vulnerability compromise Cloudflare’s security model in several ways. Firstly, the attacker can generate traffic from Cloudflare’s IP addresses, which could enable them to contact a properly configured origin server, not under their control, bypassing the restriction that the origin server only accepts incoming traffic from Cloudflare IP addresses. Moreover, the attacker can bypass Cloudflare’s security layer, such as the WAF (Web Application Firewall) and other protections, when performing these requests.

As a result, vulnerability could allow an attacker to discover the existence of protected routes behind Cloudflare’s security measures. Furthermore, it could enable the attacker to carry out blind tainted input exploitations on origin servers, checking HTTP response codes or strings contained in the HTTP responses. In this respect, the vulnerability could allow exploiting vulnerabilities that should be filtered by Cloudflare’s WAF protections, such as SQL injections, XSS, path traversal, and others.

In addition, this vulnerability could also be used by attackers to exploit Cloudflare’s IP reputation, directing attacks to any other IP addresses while appearing as legitimate Cloudflare traffic.

Evilflare: Mitigations and Contermeasures

As long as Cloudflare does not implement the proposed corrections, to eliminate the described risk, which are listed below:

• In the Origin field: Do not allow IP addresses, always forcing a hostname to be defined.
• In the Port field: Limit the ports to those allowed by Cloudflare.
• In the Request Headers fields: do not allow the Host header to be defined, forcing it to be the hostname defined in the Origin field.

We believe it is reasonable that the following mitigations be implemented:

• In all scenarios where possible, move away from the protection model based on source IP filtering and move towards the Cloudflare Tunnel protection model.
• In scenarios where this is not possible, reject by default any request that contains the string Cloudflare-Healthchecks in its HTTP User-Agent header.
• In general, any Internet webserver that wants to guarantee its maximum security, reject by default any request that contains the string Cloudflare-Healthchecks in its HTTP User-Agent header.

Evilflare: Conclusions

Once again, vendors’ reluctance to accept vulnerabilities that do not have a direct impact and trivial exploitation is evident. In our opinion, although this vulnerability has a complex exploitation, and may not be valid for all cases, it constitutes a clear risk that should be corrected by Cloudflare. Until that time comes, we strongly recommend adopting the proposed countermeasures.

Finally, although the vulnerability shown only affects a specific vendor, we believe it is interesting and necessary to think on how origins that are protected by cloud security solutions are being secured, as well as whether this attack vector could be extrapolated to other platforms or providers.

Evilflare: Disclosure timeline

• April 20th, 2023: The vulnerability is sent to Cloudflare via Hackerone.
• April 21st, 2023: Cloudflare requests more information. Clarification and additional information is provided.
• April 24th, 2023: Cloudflare rejects accepting the report as a vulnerability. The reasons given are that the use of the “health checks” functionality will not compromise confidentiality, integrity, and/or availability.
• April 25th, 2023: The information is released to the community.

READ MORE HERE