Skip to content

Article by Wes Ladd.

S3 File ACL Persistence

Requirements

For this scenario to work, you will need to have s3:PutBucketAcl, s3:PutObjectAcl, or PutObjectVersionAcl on the target s3 bucket or associated object.

Purpose

When doing an assessment in AWS you may want to maintain access for an extended period of time, but you may not have the ability to create a new IAM user, create a new key for existing users, or even perform IAM role-chain juggling. How else can you extend your access? By backdooring key S3 resources using S3 Access Control Lists (ACLs).

Background on Sensitive S3 Use Cases

Many organizations have grown to use AWS S3 to store Terraform state files, CloudFormation Templates, SSM scripts, application source code, and/or automation scripts used to manage specific account resources (EC2 instances, Lambda Functions, etc.) During post-exploitation, you may identify opportunities to access these resources. Provisioning write, or in some cases read only access to these resources, may provide persistent access to credentials for the AWS account and/or resources provisioned in the account. Furthermore, write access specifically may allow an attacker to update configuration files, source code for applications, and/or automation code that modifies downstream resources in the account. On the next update/execution of the relevant data/code, this may allow an attacker to further extend access to other resources in the account, or even beyond the specific AWS account accessed. This brings us to the method: S3 ACL Access Control.

Technique

S3 ACL Access Control is a recognized functionality of AWS in that you can use an access control list to allow access to S3 buckets from outside your own AWS account without configuring an Identity-based or Resource-based IAM policy. While many organizations may be prepared to alert on S3 buckets made public via resource policy, this alerting may not extend to capabilities associated with bucket or object ACLs. Furthermore, subtler configurations that expose bucket or object resources to other accounts via ACLs may go undetected by organizations, even those with strong alerting capabilities. Using these permissions, you can extend your access by allowing other AWS accounts you control to read or write objects, buckets, and bucket ACLs. Furthermore, the access can be extended to AUTHENTICATED USERS, which is a term AWS uses to describe any AWS IAM principal in any other AWS account. The access can also be extended to ANY USER which is a term AWS uses to describe anonymous access that does not require authentication.

Key Considerations

  1. Bucket Public Access Block will prevent S3 bucket ACLs from being configured to allow public (ANY USER) access. If configured, it will provide some limitations to this technique. It does not, however, block the sharing of an s3 object to a specific account, due to what AWS classifes as 'public'.
  2. ACLs for Buckets or objects can be disabled at the bucket level, which would mandate the bucket owner as the object owner no matter who uploads the object. From April 2023, AWS will make this the default for all newly created buckets.