Amazon Web Services Identity and Access Management (IAM) mechanisms are complex, and if you don’t fully understand its peculiarities, it usually leads to configuration errors and exposure of cloud assets. Researchers at cloud security company Lightspin found that quirks in S3 bucket permissions seem to be a common source of confusion among administrators.
There are multiple ways to restrict or grant access to data stored in S3 buckets, some of which are more granular than others, but they are all interdependent. Over time, changes to these individual policies may inadvertently expose data or open buckets to unauthorized users. This is especially true when dealing with large buckets containing thousands or hundreds of thousands of objects. Lightspin researchers believe that AWS’s warning messages are not clear or detailed enough for administrators to pinpoint the problem. This is why the company developed and released the open source S3 bucket scanner, which can identify public access and cross-account attacks.
Objects can be public, but what are they?
When dealing with S3 buckets, there are three ways to restrict public access: bucket ACL (Access Control List), which applies to the entire bucket, object ACL, which applies to a single object, and the S3 bucket IAM policy. AWS also provides an S3 block public access function, designed to help administrators protect their buckets by overwriting existing ACLs, but this function comes with four different options with different effects, although they provide administrators with a lot Great flexibility, but they can also be confused.
First, public access in the context of S3 ACL refers to the read or write permissions granted to members of the AllUsers or AuthenticatedUsers group. It is worth pointing out that AuthenticatedUsers refers to anyone who has an AWS account, not just accounts from the same organization.