Cloudflare zero-day: Accessing any host globally
fearsoff.org
Cloudflare zero-day: Accessing any host globally
1–10 of 16 posts
Re: Cloudflare zero-day: Accessing any host globally
#2I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?
Re: Cloudflare zero-day: Accessing any host globally
#3I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?
All their examples rely on having poorly configured origins. At least the PHP and Tomcat ones might be blocked by a WAF, but the Next.js one would rely on the WAF blocking responses that included secrets (which I’m not sure they do).
Re: Cloudflare zero-day: Accessing any host globally
#4I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?
Basically, it shows that Cloudflare's WAF (which is supposed to intercept requests before they make it to the origin server), is trivially bypassable by using the `.well-known/acme_challenge` path.
That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated
Re: Cloudflare zero-day: Accessing any host globally
#5I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?
All their examples rely on having poorly configured origins. At least the PHP and Tomcat ones might be blocked by a WAF, but the Next.js one would rely on the WAF blocking responses that included secrets (which I’m not sure they do).
I think the idea for the NextJS example was that there might be some configuration variables that are not sensitive for internal / staff users, but would be problematic if exposed externally—basically, relying on Cloudflare's WAF as a "zero trust" endpoint solution, like Google IAP.
I'm not sure how realistic this is in practice. Does anyone actually configure Cloudflare WAF this way? (As opposed to, e.g., Cloudflare's dedicated zero-trust networking product, which I think works completely differently?)
Re: Cloudflare zero-day: Accessing any host globally
#6I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?
It's possible you're rendering more than just a simple 404, such as an SPA response or other result as part of an application response that may leak more information...
I think it's not a severe issue in most cases, and maybe something worth noting or addressing if you are at least aware of it, you can just 404 without content, for example in the .well-known/ path. I run most of my apps behind Caddy, which handles that path itself and doesn't forward requests to that path, so I'm curious how it handles it tbh.
I'm also not sure that there's a clear/good fix for this, since CF is allowing the traffic through so that ACME negotiation can work against the final application host.
Re: Cloudflare zero-day: Accessing any host globally
#7What a frustrating article. There was an interesting bug here. It's trivial to explain. It's not a zero-day, this was fixed months before disclosure. Most of the article is basically: "Imagine you were running software with horrific security holes behind this WAF. We even made some examples. It had a flaw. If your entire security posture depended on this WAF, imagine how much damage could have been done. Imagine if AI were involved!"
Re: Cloudflare zero-day: Accessing any host globally
#8The point is that WAF didn't block everything, and that if your app had some kind of default/error handler that non-blockage would have unexpectedly exposed something.
Not that big of a deal, but interesting.
Re: Cloudflare zero-day: Accessing any host globally
#9> The CA fetches that token over plain HTTPS
The HTTP-01 challenge can only be done on port 80.
Re: Cloudflare zero-day: Accessing any host globally
#10The one thing that I find bizarre about this: why did Cloudflare feel inspired to special-case /.well-known/acme-challenge at all? The only thing I can think of is that clients were having caching issues (Cloudflare caching the challenge value, clients forgetting to set cache-control headers, and challenges therefore failing), but that seems like a bit of a weak reason to special-case anything. Anyone using Cloudflare should already know how to set cache control headers.