[HN Gopher] Conditional Love for AWS Metadata Enumeration
       ___________________________________________________________________
        
       Conditional Love for AWS Metadata Enumeration
        
       Author : kiyanwang
       Score  : 23 points
       Date   : 2024-02-26 06:42 UTC (1 days ago)
        
 (HTM) web link (blog.plerion.com)
 (TXT) w3m dump (blog.plerion.com)
        
       | nicornk wrote:
       | 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...
        
       | Temporary_31337 wrote:
       | I feel like the potential to abuse this is pretty low but AWS
       | will ,fix' this and make IAM even harder
        
         | ComputerGuru wrote:
         | 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.
        
       | ComputerGuru wrote:
       | 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?
        
       | mdaniel wrote:
       | relevant from yesterday, with some lively discussion:
       | https://news.ycombinator1.com/item?id=39512896
        
       ___________________________________________________________________
       (page generated 2024-02-27 23:02 UTC)