Open S3 Buckets — Examples, Scanner and How to Respond

0xffccdd
6 min readDec 6, 2022

--

It’s important to be aware of any possible data breaches in your AWS environment — and to have a plan in place to respond to them quickly and effectively. One potential source of data breaches is an open S3 bucket, which is a cloud storage service provided by Amazon Web Services (AWS). In this blog, we’ll discuss how to detect and respond to a data breach in an open S3 bucket.

We’ve built a platform for Cloud Detection & Response in AWS including S3, Azure, and GCP — you can grab a demo here. You can also download free playbooks we’ve written on how to respond to security incidents in AWS, Azure, and GCP.

First, let’s define what an open S3 bucket is. An open S3 bucket is a cloud storage service that allows users to store and retrieve data. It’s called “open” because anyone can access the data in the bucket without authentication. This can be a major security risk, as anyone can view, download, or even delete the data in the bucket.

A misconfigured Amazon S3 bucket resulted in 3TB of airport data (more than 1.5 million files) being publicly accessible, open, and without an authentication requirement for access, highlighting the dangers of unsecured cloud infrastructure within the travel sector.

The exposed information, uncovered by Skyhigh Security, includes employee personal identification information (PII) and other sensitive company data affecting at least four airports in Colombia and Peru.

The PII ranged from photos of airline employees and national ID cards — which could present a serious threat if leveraged by terrorist groups or criminal organizations — to information about planes, fuel lines, and GPS map coordinates.

From DarkReading

Detection

So, how do you detect if your S3 bucket has been breached? The first step is to monitor your bucket for any suspicious activity. This can be done through AWS CloudTrail, which is a service that enables you to monitor, log, and retain account activity related to actions taken on your AWS resources. By using CloudTrail, you can monitor for events such as data being accessed or deleted from your bucket.

Another way to detect a data breach in your S3 bucket is to use Amazon S3 Event Notifications. This feature allows you to specify events that you want to be notified about, such as when a new object is added to your bucket or when an object is deleted. You can configure these notifications to be sent to you via email or an HTTP endpoint, so you can be alerted to any suspicious activity in your bucket.

To identify public Amazon S3 buckets, you can use the following steps:

  1. Open the Amazon S3 console.
  2. In the left navigation pane, choose “Buckets”.
  3. For each bucket in the list, check the “Permissions” tab to see whether it has any public access granted.

Alternatively, you can use the Amazon S3 command-line interface (CLI) to identify public S3 buckets. To do this, you can use the aws s3api list-buckets command, which will return a list of all your S3 buckets. You can then use the aws s3api get-bucket-acl command to retrieve the access control list (ACL) for each bucket, which will show you which users or groups have access to the bucket and its contents. If the ACL grants any public access, the bucket is considered to be public.

There are a number of free tools to scan for open S3 buckets, including:

AWS Config

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. With AWS Config, you can identify open Amazon S3 buckets by creating a configuration recording and a custom AWS Config rule.

To identify open S3 buckets with AWS Config, follow these steps:

  1. Start by enabling AWS Config in your AWS account. This will allow you to create and manage configuration recordings for your AWS resources.
  2. Next, create a configuration recording that includes information about the S3 buckets in your account. You can do this by using the AWS Config console, the AWS CLI, or the AWS Config API.
  3. After creating the configuration recording, you can create a custom AWS Config rule to identify open S3 buckets. This rule will use the information in the configuration recording to evaluate whether any of your S3 buckets are publicly accessible.
  4. To create a custom AWS Config rule, use the AWS Config console, the AWS CLI, or the AWS Config API. In the rule, you can specify the conditions that must be met for an S3 bucket to be considered open. For example, you can create a rule that checks whether the bucket’s access control lists (ACLs) allow public read access, or whether the bucket has any public access blocks in place.
  5. Once you have created the custom AWS Config rule, you can use the AWS Config console or the AWS CLI to run the rule and evaluate your S3 buckets. The rule will return a list of any S3 buckets that meet the specified conditions and are therefore considered open.
  6. You can then take appropriate action to secure any open S3 buckets, such as modifying the bucket’s ACLs or adding public access blocks.

Overall, using AWS Config to identify open S3 buckets is a simple and effective way to ensure that your S3 data is protected and secure.

Responding

Once you’ve detected a data breach in your open S3 bucket, it’s important to act quickly to contain the breach and prevent any further damage. The first step is to stop the source of the breach by securing your bucket. This can be done by enabling bucket policies, which allow you to control who can access your bucket and what actions they can perform on the data within it.

Next, you should restore any data that may have been deleted or modified during the breach. AWS provides a number of tools to help you do this, such as the AWS Management Console and the AWS CLI (Command Line Interface). These tools allow you to easily browse, download, and restore objects in your bucket.

Finally, it’s important to investigate the cause of the data breach and take steps to prevent it from happening again in the future. This may involve conducting a thorough security audit of your AWS account and implementing additional security measures such as multi-factor authentication and encryption.

S3 Security Best Practices

There are several settings on an Amazon S3 bucket that can make it insecure if not configured properly. Some of these include:

  • The bucket’s access control settings, such as its bucket policy and access control lists (ACLs), determine who has access to the bucket and its contents. If these settings are not properly configured, the bucket and its contents may be accessible to unauthorized users.
  • The bucket’s versioning settings determine whether previous versions of objects in the bucket are preserved. If versioning is not enabled, old versions of objects may be overwritten or deleted, which can lead to data loss.
  • The bucket’s server-side encryption settings determine whether data stored in the bucket is encrypted at rest. If server-side encryption is not enabled, sensitive data stored in the bucket may be vulnerable to unauthorized access.
  • The bucket’s logging settings determine whether access logs are generated for the bucket. If logging is not enabled, it may be difficult to track access to the bucket and detect any unauthorized access.
  • It is important to properly configure the settings on an S3 bucket to ensure that it is secure. This may involve setting up appropriate access controls, enabling versioning and server-side encryption, and enabling logging.

How to block public access to S3 Buckets

To block all public access to Amazon S3 buckets, you can use the following steps:

  1. Open the Amazon S3 console.
  2. In the left navigation pane, choose “Buckets”.
  3. Select the bucket for which you want to block public access.
  4. In the “Permissions” tab, choose “Block all public access”.
  5. Choose “Edit”.
  6. Select the checkbox next to “Block all public access”.
  7. Choose “Save”.

After completing these steps, all public access to the selected S3 bucket will be blocked. Note that this may affect the functionality of any applications that rely on the bucket, so you should carefully evaluate the potential impact before implementing this change.

For more, see this video from AWS:

--

--