{"id":51640,"date":"2023-04-26T14:50:24","date_gmt":"2023-04-26T14:50:24","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/34555\/Evilflare-Circumventing-Cloudflares-Protection.html"},"modified":"2023-04-26T14:50:24","modified_gmt":"2023-04-26T14:50:24","slug":"evilflare-circumventing-cloudflares-protection","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/evilflare-circumventing-cloudflares-protection\/","title":{"rendered":"Evilflare: Circumventing Cloudflare’s Protection"},"content":{"rendered":"

Cloudflare<\/em> 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. <\/p>\n

In this post, we\u2019ll delve into the importance of protecting origin servers and explore three attack scenarios that could potentially bypass Cloudflare\u2019s<\/em> defenses. <\/p>\n

We have called the last of them Evilflare<\/em>. 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.<\/p>\n

<\/span> <\/p>\n

Cloudflare and Origin Servers<\/strong><\/p>\n

Origin servers are the primary web servers hosting a site\u2019s content. Cloudflare<\/em> 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<\/em> to filter out malicious requests, ensuring that only legitimate traffic reaches the origin server. <\/p>\n

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.<\/p>\n

Unprotected origin servers: The First Scenario<\/strong>.<\/p>\n

Origin servers that accept connections from any source IP are at risk of being targeted by attackers who want to bypass Cloudflare\u2019s<\/em> security measures. <\/p>\n

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<\/em> and send their traffic directly to the origin server.<\/p>\n

Example of IP history over a \u201ccloudflared\u201d domain<\/figcaption><\/figure>\n

Protecting Origin Servers<\/strong><\/p>\n

Cloudflare<\/em> 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:<\/p>\n

a. IP Filtering<\/a>: <\/em><\/strong>This simpler approach involves allowing traffic only from Cloudflare\u2019s IP addresses. Though it is easier to implement, this method offers less comprehensive protection compared to the alternative. <\/p>\n

b. Cloudflare Tunnel<\/a>:<\/em><\/strong> 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.<\/p>\n

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\u2019s<\/em> public addresses.<\/p>\n

HTTP Host<\/em> Header Bypass: The Second Scenario.<\/strong><\/p>\n

Once we are in a common<\/em> scenario where a server is protected by source IP filtering, HTTP Host<\/em> header plays a crucial role in the security model.<\/p>\n

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

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

\n
HTTP \u201cHost\u201d Header Bypassing<\/figcaption><\/figure>\n<\/div>\n

Evilflare: The Third Scenario<\/strong><\/p>\n

Regrettably, a native Cloudflare\u2019s<\/em> function presents a zero-day vulnerability, not acknowledged by vendor, that attackers could exploit to attack origin servers properly configured. <\/p>\n

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

Evilflare: Abusing Cloudflare\u2019s application logic to attack origin servers<\/strong><\/p>\n

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

Although the attacker cannot see the full response generated by the target server, they can discern the HTTP<\/em> 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. <\/p>\n

The attacker also has control over the headers they can include in the request, including Host<\/em> header, with the exception of the User-Agent<\/em> header, which they cannot manipulate.<\/p>\n

Evilflare: Explotation PoC<\/strong><\/p>\n

Exploitation can be done via the Cloudflare<\/em> API or via Dashboard. <\/p>\n

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.<\/p>\n

As an example, we will simulate a potential exploitation vector using the Dashboard. We will create a new \u201cHealth Check\u201d with the following characteristics:<\/p>\n

Example of Malicious Health Check<\/figcaption><\/figure>\n

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

# 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<\/code><\/p>\n

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

Evilflare: Impact<\/strong><\/p>\n

This vulnerability compromise Cloudflare\u2019s<\/em> security model in several ways. Firstly, the attacker can generate traffic from Cloudflare\u2019s<\/em> 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\u2019s security layer, such as the WAF (Web Application Firewall) and other protections, when performing these requests. <\/p>\n

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

In addition, this vulnerability could also be used by attackers to exploit Cloudflare\u2019s IP reputation<\/em>, directing attacks to any other IP addresses while appearing as legitimate Cloudflare traffic.<\/p>\n

Evilflare: Mitigations and Contermeasures<\/strong><\/p>\n

As long as Cloudflare<\/em> does not implement the proposed corrections, to eliminate the described risk, which are listed below:<\/p>\n