Conditional Love for AWS Metadata Enumeration
blog.plerion.com
blog.plerion.com
----
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?
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.