> The CA fetches that token over plain HTTPS
The HTTP-01 challenge can only be done on port 80.
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?
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.
> 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.
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.
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.
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!"