Amazon S3

S3 Buckets With Global Policy

Ensure there is no public, unsecured access granted to S3 buckets via S3 bucket policies.

Risk Level: High

Description

This plugin determines S3 bucket policies that allow global write, delete, or read permissions. S3 bucket policies are written in JSON that provides action rights to objects in the specific bucket. These policies can be configured to allow the global principal to access the bucket. It should be restricted only to known users or accounts.

Configuration Parameters

S3 Bucket Policy Allowed Condition Keys: This parameter denotes a comma-separated list of AWS S3 condition keys that should be allowed. If the policy statement is vulnerable and these keys are present, the issue will not be generated.

By default, the condition keys mentioned are 'aws:PrincipalArn','aws:PrincipalAccount', 'aws:PrincipalOrgID','aws:SourceAccount', 'aws:SourceArn', 'aws:SourceOwner', 'kms:CallerAccount', 'kms:ViaService', therefore all the statements consisting of these keys will not be scanned.

About the Service

Amazon S3: Amazon Simple Storage Service, popularly known as Amazon S3, is a storage space available on the cloud. Using Amazon S3, you can store and retrieve any amount of data. You can manage permissions using S3 bucket policies. To know more, read here.

Impact

Bucket Policies are flexible JSON policies that allow users to set conditional permissions on a bucket. It’s this flexibility that leads to mistakes such as granting access to a wider range of IPs.


Risking the S3 bucket by making it public can lead to data breaches or data loss. You can imagine the impact of this vulnerability by an incident where an unsecured AWS S3 was found leaking data of over 30k customers. Attackers regularly keep an eye on buckets with public access so removing such policies must be a high priority.

Compliances covered

PCI: PCI requires that cardholder data can only be accessed by those with a legitimate business need. If PCI-restricted data is stored in S3, those buckets should not enable global user access. If the policy Principal is set to global (*), the data can be publicly available and will not fulfill the requirements of PCI.

Steps to Reproduce

Using AWS Console-

  1. Log In to your AWS Console.
  2. Open the S3 Management Console. You can use this link (https://console.aws.amazon.com/s3) to navigate directly if already logged in.
  3. Select the S3 bucket you wish to investigate and click on the Permissions tab from the top navigation bar. 

 

4. Move to the Bucket Policy section in the Permissions Tab and examine the policy present. 

Bucket policy

 

Have a look at two properties of a single entry, “Principal” and “Effect”.  The Principal property defines the users who can perform the actions on the resources mentioned. If the Principal value is set to * and Effect value is set to allow, any user can perform the action on the S3 resource unless a condition is placed. Such type of policy is marked as vulnerable.

 

5. Repeat steps 3 to 4 for all the S3 buckets you want to investigate.

Steps for Remediation

Update the bucket permissions in the policy and restrict access to the owner or specific users.

The steps to restrict access are-
  1. Log In to your AWS Console.
  2. Open the S3 Management Console. You can use this link (https://console.aws.amazon.com/s3) to navigate directly if already logged in. 
  3. Select the vulnerable S3 bucket and click on the Permissions tab from the top navigation bar. 
  4. Move to the Bucket Policy section in the Permissions Tab.

    Edit Bucket Policy

  5. Now you can perform two actions based on your requirements.
    1. To block complete public access, click on the Delete button beside Bucket policy. Type “delete” to confirm the deletion of the policy.
    2. To provide access for the specified actions to a few users, click on the Edit button beside Bucket Policy. Replace the value of Principal property with the ARN (Amazon Resource Name) of the users you want to provide action access to. Select Save Changes after updating the policy.

  6. Repeat the steps from 3 to 5 for all the vulnerable S3 buckets.

References:

https://www.theregister.com/2020/01/23/thsuite_data_exposed/