Overlooking medium and low-severity cloud security misconfigurations can have consequences.
In our “Severity Matters” series, we cover how downplayed misconfigurations can lead to compliance violations, data breaches, and legal ramifications. We’ve seen how easily medium and low severity misconfigurations can become lost in the noise of CNAPP and CSPM alerts, and how attackers can utilize these overlooked alerts as a stepping stone to higher severity attacks.
In this latest installment, we outline how leaving open S3 access to any AWS-authenticated user can expose your sensitive data.
The unintended consequences of open access
Allowing any AWS-authenticated user access to an S3 bucket opens up sensitive data to exfiltration.
The best way to detect this configuration is by examining the Access Control List (ACL) configuration set for the authenticated users group (anyone with an AWS account) grantee, for any given S3 bucket. Here we list two paths to confirm this configuration:
Using AWS Console: In the ACL section of the Permissions tab, if the authenticated users group grantee is set to List in the Objects column, the selected S3 bucket is accessible to anyone with an AWS account.
Using AWS CLI: if the get-bucket-acl command (using the name of the Amazon S3 bucket that you want to examine) output returns “READ” for the “Permission” attribute value, then the selected Amazon S3 bucket is accessible to anyone with an AWS account to list and read.
If you store sensitive data in the bucket, authenticated users’ access may not be desired. A breach could occur without you realizing it. In this post, we chart the attacker’s path to your sensitive data via an overly permissive S3 bucket.
Sample Attack Path
Step 1: Authentication
Attackers commonly utilize one of two methods to obtain valid credentials and authenticate their AWS access:
1) stealing another AWS customer’s credentials, implicating that customer; or
2) creating a new AWS account for the sole purpose of carrying out the attack. Currently, the first approach – stealing another user’s credentials – is far more common.
Step 2: Discovery & Listing Buckets
The attacker identifies an S3 bucket that allows any AWS-authenticated user access. This could be discovered through various means, including scanning, manual inspection, or accidental findings. Dedicated scanners and threat actors specialize in this type of vulnerability discovery, and – according to Orca – detection time has been measured in minutes, from bucket creation to discovery. After authentication, the attacker lists the S3 buckets available to their AWS user account. This step helps identify the target bucket with open access.
Step 3: Unauthorized Access
The attacker accesses the S3 bucket that grants access to any authenticated user. Since they are authenticated, they can read, write, and manipulate objects within the bucket. If the bucket contains sensitive data, it can be exploited for malicious purposes.
Step 4: Data Exfiltration
If the attacker’s goal is data exfiltration, they can download sensitive information from the compromised S3 bucket, potentially including confidential business data, personal information, or intellectual property.
How to stay secure
Employing a CNAPP can provide insights into these types of misconfigurations, offering visibility and timely detection. But if a CNAPP categorizes open S3 access as a low-severity misconfiguration, it can be lost amidst thousands of alerts. Tamnoon sits atop your CNAPP to consolidate and prioritize these types of alerts, thereby preventing threat actors from exfiltrating data from your environment.
Utilizing Tamnoon’s assisted remediation ensures a comprehensive understanding of the operational impact when addressing such misconfigurations, aiding in distinguishing between assets that should remain open in their current state, and those that require remediation.
