Cloudflare zero-day: Accessing any host globally

What 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!"

	▲	bpt3 an hour ago \| parent [-]
		On top of that, AI was clearly used to write it which made it longer than necessary and harder to read.

▲

computerfriend 8 minutes ago | parent | prev | next [-]

> We wish to express our deep gratitude to Jason Lau, CISO and the Crypto[.]com Security Team, who we approached first to help independently verify this zero-day vulnerability.

Bizarre choice.

▲

cube00 2 hours ago | parent | prev | next [-]

> The CA fetches that token over plain HTTPS

The HTTP-01 challenge can only be done on port 80.

https://letsencrypt.org/docs/challenge-types/

	▲	mmsc 42 minutes ago \| parent [-]
		The article was clearly written by an LLM. It would make no sense to use https for a challenge like that, indeed.

▲

nick-sta 3 hours ago | parent | prev | next [-]

I’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?

▲

nightpool 3 hours ago | parent | next [-]

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

▲

tracker1 3 hours ago | parent | prev | next [-]

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.

▲

cowsandmilk 3 hours ago | parent | prev [-]

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).

	▲	nightpool 3 hours ago \| parent [-]
		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?)

▲

mannyv 2 hours ago | parent | prev | next [-]

The 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.

▲

jerrythegerbil 2 hours ago | parent | prev | next [-]

There’s a lot going on in this blog. Interestingly, the core mechanism at play here is the http-01 challenge validations which they state is fetched by the CA over HTTPS. This is particularly amusing when you consider that http-01 is explicitly NOT HTTPS (it’s HTTP), and this is actually the entire reason there’s a different code path to take.

The modern web requires secure (HTTPS) context for many things to work, so it’s commonplace to do so “HTTPS enforcement”; all requests are forcibly upgraded to HTTPS. However, you can’t do that to the CA when it’s performing a http-01 challenge validation. This necessitates a “well known” URL route be used for challenges so that they can very deliberately take a different code path that doesn’t enforce HTTPS (and be routed differently).

This is true of basically every ACME client used for http-01 challenges, not just cloudflare. So while they’ve unfortunately missed the mark on correctly explaining the mechanism at play here, I hope that I succeeded in making it a bit more clear. Other implementations are, of course, similarly exploitable.

▲

amluto 2 hours ago | parent | prev [-]

The 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.

	▲	Dylan16807 14 minutes ago \| parent [-]
		My guess would be that aggressive blocking was causing verification to fail, since it gets verified from multiple well-separated locations.