The KV vulnerability

I’m curious as to how it was exploited, any details from the Cloudflare team? :slight_smile:

For clarification what this is about

2 Likes

We’re not aware of anyone exploiting this; all of the logs that we have show nothing malicious.

2 Likes

Yes, I’ve gathered that from reading the e-mail.
I’m curious as to what the issue was, what caused the vulnerability?

You’re previous issue with the regex CPU-time issue got a whole blogpost and it was very interesting, was kind of hoping for something similar :wink:

1 Like

Hey thomas4, I manage the product security team at Cloudflare who was first made aware of this issue.

Not every issue we have write about in the same depth as the WAF issue we had earlier in the year. In this case, it wouldn’t be as interesting and there’s not very much to talk about.

The actual bug was a direct object reference type vulnerability. Basically, the IDs are sufficiently random that it’s not possible to guess one but if you happened to find one laying around you could have used it as your own by passing the namespace ID to the API.

3 Likes

Understood, this one was a bit un-interesting as there’s not much to learn.

But you mean that a namespace wasn’t protected by the users API credentials at all and any user could write and read any users KV namespace if they knew the namespace ID? Lucky it was a random ID then and that it was discovered in time.

I’m curious to know what measures are being taken to mitigate this in the future. Not technically, but UI/UX. My (clearly) mistaken impression was that the KV namespace_id was just a unique identifier. Nothing that I recall indicated to me that it was a secret to be handled in the same manner as other sensitive credentials.

Could we get a better indication from CF how different random identifiers are a) treated by CF, and b) should be treated by developers and users? Maybe by using different background colors behind the respective id?

Also, it would help if CF could state clearly wether the KV namespace_id was sufficient alone or did it require other credentials as well? IOW, Is this just “Alice, when logged in with her credentials, could read Bob’s KV store if she new Bob’s KV namespace_id”, or “Eve, without being logged in, could read Bob’s KV store if she knew Bob’s KV namespace_id”?

Thanks,

Jason.

1 Like

The KV namespace id is just a unique identifier. One of the properties of this unique identifier is that it’s difficult to guess, since it’s a UUIDv4. That means that if an attacker found out about this they couldn’t just guess all the namespace ids. Our long hex ids (like zone ids, namespace ids, etc) are not meant to be secrets, but since they have lots of entropy it makes guessing them difficult.

Alice would have needed to be logged in and have Bob’s KV namespace ID. I don’t think this detail matters though. We allow anyone to sign up and get started with Workers KV with very little friction, so Eve is only a few clicks away from having a Cloudflare account just like Alice.

Though I presume they are still subject to access control, right?

And this was not the case in this vulnerability, but it only checked for a valid session. Correct?

1 Like

@sandro that’s correct.

2 Likes

Merci for the clarification :bowing_man:t2:

@ejcx:

Thanks for the quick response!

Sorry, I disagree here. Either we all treat it like a secret, or we don’t. Saying, in effect, “It’s not a secret, but it has some security properties” is a recipe for chaos. Say I take you at your word, namespace_id’s aren’t secret. I then check them in as configuration items in public source control. Then, a couple months down the road, New CF Dev #72 starts coding as if it was secret, because it has some properties of a secret. We’ll end up in the same boat again.

Why do we have namespace_id anyway? We already have the KV name, which, for my sanity, is unique amongst the KVs under my account. Additionally, every operation I’ve ever done with KVs requires separate authentication. So, if CF needs the namespace_id under the hood, that’s fine. I’m just not sure I see how exposing it to the CF users helps in any way. Honestly, It’s a PIA when curling the KV stores. Would be much nicer just to use the KV name everywhere.

If we could extend the restricted API Tokens to be able to limit read/edit down to specific KV stores, that would be much more secure than what we have now with namespace_id.

[EDIT] I’d also like to be able to restrict specific route/script combinations to read-only access to an attached KV store.

Thanks,

Jason.

2 Likes

Just to clear this up, I’m not saying this is a secret. I’m saying that as a random number it is difficult to guess and random numbers have that security property of being difficult to guess. It is not a secret.

2 Likes

@ejcx already addressed it, but allow me to elaborate on it as far as my understanding is concerned.

I’d agree with you if the security concept relied on them being “difficult to guess”, but that does not seem to be the case and there is some proper authorisation supposed to be in place. The fact that it apparently wasnt is a different topic and actually subject of the very issue.

As far as I understand it, these IDs are perfectly public values, which could equally be incremental values, they however do have the advantage of being more difficult to guess than incremental values. That advantage is not a security aspect though.

1 Like

This post was flagged by the community and is temporarily hidden.