If OP is here, your code block has some html characters double-encoded (> and co).
----
Can someone double check my understanding of something? AWS doesn’t return the failure reason for auth failure on policy mismatch when access is denied, so you can only know your assumption is correct if the request succeeded.
Does that mean that this only works for resources that have been shared publicly by the upstream owner? If I have an AWS bucket and I only generate signed URLs to access the content and otherwise deny access (standard non-public bucket procedure), this attack wouldn’t work since requests to the base resource need to fulfill both the owner and requester policies and even if your requester policy has a prefix match the upstream access policy will deny the request, no?
Yeah, finally a method to figure out the org id of all those snowflake internal stage buckets that snowflake does not want to share for our VPC Endpoint Policies…
I don’t see how the (to me) obvious fix would make IAM any harder. The bug is that they are treating account owner id as a string, allowing matching against it with prefix operations. It is a guid and should only have equal/not-equal tests.
As there are no “valid” IAM use cases for prefix matching on a resource id (you don’t control the resource id so you can never group resources by using a common prefix, etc) then there is no difficulty imposed by patching this.
The only question is backwards compatibility. If some idiot somewhere actually used a prefix match against a substring in production to match part of their actual resource id, this would presumably break it.
As for potential for harm, I don’t think it’s as low as you make it out to be. It’s hard to be anonymous online. This is another example of that. Forget common crawl or Carvana, and think dissident or whistleblower.
Note the ids appear to be 40-bit numbers, which isn’t great for security in the first place. I’m not sure off hand if there’s an efficient way to test all 2^40 values but seems feasible.
----
Can someone double check my understanding of something? AWS doesn’t return the failure reason for auth failure on policy mismatch when access is denied, so you can only know your assumption is correct if the request succeeded.
Does that mean that this only works for resources that have been shared publicly by the upstream owner? If I have an AWS bucket and I only generate signed URLs to access the content and otherwise deny access (standard non-public bucket procedure), this attack wouldn’t work since requests to the base resource need to fulfill both the owner and requester policies and even if your requester policy has a prefix match the upstream access policy will deny the request, no?