Cloudflare DDoS protections ironically bypassed using Cloudflare


Cloudflare’s Firewall and DDoS prevention can be bypassed through a specific attack process that leverages logic flaws in cross-tenant security controls.

This bypass could put Cloudflare’s customers under a heavy burden, rendering the protection systems of the internet firm less effective.

To make matters worse, the only requirement for the attack is for the hackers to create a free Cloudflare account, which is used as part of the attack.

However, it should be noted that the attackers must know a targeted web server’s IP address to abuse these flaws.

Cloudflare vs Cloudflare

Certitude’s researcher Stefan Proksch discovered that the source of the issue is Cloudflare’s strategy to use shared infrastructure that accepts connections from all tenants.

Specifically, the analyst identified two vulnerabilities in the system impacting Cloudflare’s “Authenticated Origin Pulls” and “Allowlist Cloudflare IP Addresses.”

Authenticated Origin Pulls is a security feature provided by Cloudflare to ensure that HTTP(s) requests sent to an origin server come through Cloudflare and not from an attacker.

When configuring this feature, customers can upload their certificates using an API or generate one through Cloudflare, the default and easiest method.

Cloudflare origin certificate installation
Cloudflare origin certificate installation
Source: BleepingComputer

Once configured, Cloudflare uses the SSL/TLS certificate to authenticate any HTTP(S) requests between the service’s reverse proxies and the customer’s origin server, preventing unauthorized requests from accessing the website.

However, as Proksch explains, attackers can bypass this protection as Cloudflare uses a shared certificate for all customers instead of a tenant-specific one, causing all connections originating from Cloudflare to be permitted.

“An attacker can setup a custom domain with Cloudflare and point the DNS A record to victims IP address,”  explains Proksch.

“The attacker then disables all protection features for that custom domain in their tenant and tunnel their attack(s) through the Cloudflare infrastructure.”

“This approach allows attackers to bypass the protection features by the victim.”

Exploiting shared Cloudflare certificates
Exploiting shared Cloudflare certificates (Certitude)

The problem arising from this logic gap is that attackers with a Cloudflare account can direct malicious traffic to other Cloudflare clients or route their attacks through the company’s infrastructure.

Proksch says the only way to mitigate this weakness is to use custom certificates rather than one generated by Cloudflare.

The second issue impacts Cloudflare’s Allowlist Cloudflare IP addresses, a security measure that only allows traffic originating from Cloudflare’s IP address range to reach clients’ origin servers.

Again, an attacker can leverage a flaw in the logic by setting up a domain with Cloudflare and pointing their domain’s DNS A record to the IP address of the target victim’s server.

Next, they turn off all protection features for the custom domain and route the malicious traffic through Cloudflare’s infrastructure, which will be seen as trusted from the victim’s perspective and, hence, permitted.

Exploiting Cloudflare shared IP address range
Exploiting Allowlist Cloudflare IP (Certitude)

Proksch has also shared a proof-of-concept with configuration details to demonstrate how easy it is to bypass Cloudflare protections by leveraging the flaws.

Certitude proposes the following defense measures against these attacks:

  1. Use a custom certificate to configure the “Authenticated Origin Pulls” mechanism instead of Cloudflare’s shared certificate.
  2. Use Cloudflare Aegis (if available) to define a more specific egress IP address range dedicated to each client.

Researchers Florian Schweitzer and Stefan Proksch, who discovered the logic flaws, reported it to Cloudflare via HackerOne on March 16, 2023, but the issue was closed as “informative.”

BleepingComputer has contacted Cloudflare to ask if there are any plans to implement additional protection mechanisms or warn clients with potentially risky configurations, but we have yet to hear back.



Source link