The Amazon Web Services identity and access management (IAM) mechanism is complex, and not fully understanding its particularities often leads to misconfigurations and exposed cloud assets. Researchers from cloud security firm Lightspin identified quirks in S3 bucket permissions that appear to be a common source of confusion among administrators.
There are several ways in which access to data stored in S3 buckets can be restricted or granted, some more granular than others, but they’re all interdependent. Over time, changes made to these individual policies can inadvertently expose data or open the storage buckets to operations from unauthorized users. This is particularly true when dealing with large buckets that have thousands or hundreds of thousands of objects, and the Lightspin researchers feel that AWS’s warning messages are not clear or detailed enough for administrators to pinpoint the problems. That’s why the company developed and released an open-source S3 bucket scanner that can identify public access and cross-account attack issues.
Objects can be public, but which ones exactly?
When dealing with S3 buckets, there are three methods of restricting public access: bucket ACLs (access control lists), which apply to the entire bucket, object ACLs, which apply to individual objects, and S3 bucket IAM policies. AWS also provides an S3 Block Public Access feature that’s intended to help administrators secure their buckets by overriding existing ACLs, but this feature comes with four different options that have different effects, and while they give admins a lot of flexibility, they can also generate some confusion.
First of all, public access in the context of S3 ACLs refers to read or write permissions given to members of the AllUsers or AuthenticatedUsers groups. It’s worth pointing out that AuthenticatedUsers means anyone with an AWS account, not just accounts from the same organization.
