With cloud storage services, data is transferred to and managed at a remote location. Users access the data over a network, such as the Internet. The configuration vulnerabilities that we see in the case of cloud storage are not a new problem. Reports and analyses covered the topic as early as 2011. But we are presently seeing an increase in media reports of data breaches in connection with cloud storage providers. When you study these media reports it soon becomes apparent that both private companies and governments struggle with correctly configuring cloud storage services.

Most articles dealing with this issue touch on data leaks from Amazon S3 buckets that have come to light. But there are also similar reports about Google Cloud Storage. This article focuses on analysis of Amazon S3 buckets as well as Google Cloud Storage. First we will look at how to find a cloud storage data container (or “bucket”). Then we will address the various forms of misconfiguration and how these can be exploited. And finally, we find out how to check the configuration and make it more secure.

Amazon S3 Buckets

Techniques for finding an Amazon S3 bucket

Each Amazon S3 bucket has its own unique name. Later on we will explain how this name can be discovered. If you know the name, the first step in accessing the bucket works like this:

http://<bucketname>.s3.amazonaws.com

If the name exists and permissions are set so that anyone can read the content, you will receive a response that looks something like this:

If the bucket exists but you don’t have permission to access it, you will get the following error message:

Finally, it is possible that no bucket exists under the name you have entered. This is indicated by the following error message:

To find buckets belonging to a company, you can access the URL by using personalized word lists with the structure <word>.s3.amazonaws.com. Another option is to search existing sub-domains and to use them as a starting point for any possible S3 bucket names. Certificate transparency logs can make it much easier to search for sub-domains.

Possible misconfiguration of an Amazon S3 bucket

Under the default configuration, an Amazon S3 bucket is not publicly accessible, and access must be explicitly granted. The following permissions exist:

The permissions described above can be granted to specific Amazon Web Services accounts (AWS accounts) or pre-defined Amazon S3 groups. The most important Amazon S3 groups are authenticated users and all users.

The all users group does not restrict users. So by granting READ and WRITE access to this group, anyone in the world can upload and download content to and from this bucket.

The authenticated users group includes all users who have an AWS account. You can create this type of account free of charge with the free tier option. So restricting permissions to this group creates only a minor hurdle. It may not be possible to list the content of a bucket via a browser without an account, but using AWS CLI allows you to readily access such a bucket. The CLI command for querying a bucket looks like this:

aws s3 ls s3://<bucketname>

If you want to try locating an S3 bucket for yourself, I recommend the website flaws.cloud, which takes a light-hearted approach to the cases cited above and presents some other examples as well.

Checking the configuration

Since late February 2018, Amazon has offered the Trusted Advisor tool for checking permissions and configurations of all customers free of charge. We recommend using it to check your existing buckets. If possible, the groups all users and authenticated users should not be granted any permissions at all. We recommend keeping rights as restrictive as possible, and limiting the delegation of permissions only to specific AWS accounts.

Google Cloud Storage

Techniques for finding a Google Cloud Storage bucket

Like Amazon S3 buckets, Google Cloud Storage has one unique URL per storage container, in the format http://storage.googleapis.com/<bucketname>/.

When accessing a bucket that allows anyone to read content, you will receive the following response:

Attempting to access a valid bucket name without sufficient permissions will return the following error message:

But there is a second method for accessing Google Cloud buckets – using the URL https://console.cloud.google.com/storage/<bucketname>/. However, to access this type of URL you must first be logged in with a Google account. But because an account can be readily set up at no cost, this does not present an obstacle.

If there is an existing bucket with public data, you will see something like this:

If the bucket doesn’t exist, or if access is denied, the following error message will appear in the console.cloud.google.com view:

You need the permission storage.objects.list in order to list objects in this bucket. Request this permission from a project or bucket owner and then try it again.

Possible misconfiguration of a Google Cloud Storage bucket

As with Amazon, access for Google Cloud Storage buckets is not public and must first be granted. Roles can be granted for specific Google accounts, for allAuthenticatedUsers or for allUsers. The definition allAuthenticatedUsers includes all users who can be authenticated with a Google account. AllUsers includes all users, no matter whether they have been authenticated or not.

With Google Cloud Storage, permissions for buckets can be granted both through Identity & Access Management (IAM) and through access control policy lists. But when roles are assigned through access control policy lists, a corresponding role is created in IAM. The following section therefore only describes the IAM roles. The content items in a bucket are referred to as objects.

As soon as one of these roles is granted to allAuthenticatedUsers or allUsers, this could be a misconfiguration. When granting permissions, you should be aware of the implications and who can then access this data – and maybe even change it.

Conclusion

Permissions should be granted with care. Read and write permissions for buckets should always be as restrictive as possible. The rights to existing buckets in online cloud storage services should be reviewed to rule out the possibility of unintended access and changes. Any existing resources should be used to simplify the checking of permissions.

About the Author

Andrea Hauser graduated with a Bachelor of Science FHO in information technology at the University of Applied Sciences Rapperswil. She is focusing her offensive work on web application security testing and the realization of social engineering campaigns. Her research focus is creating and analyzing deepfakes. (ORCID 0000-0002-5161-8658)

Links

• http://flaws.cloud
• https://aws.amazon.com/de/about-aws/whats-new/2018/02/aws-trusted-advisors-s3-bucket-permissions-check-is-now-free/
• https://aws.amazon.com/de/free/
• https://aws.amazon.com/de/premiumsupport/trustedadvisor/best-practices/#security
• https://cloud.google.com/iam/docs/understanding-roles
• https://digi.ninja/blog/analysing_amazons_buckets.php
• https://docs.aws.amazon.com/de_de/AmazonS3/latest/dev/BucketRestrictions.html
• https://www.bleepingcomputer.com/news/security/exposed-mongodb-server-exposes-details-of-cryptocurrency-users/
• https://www.certificate-transparency.org/what-is-ct
• https://www.upguard.com/breaches/cloud-leak-centcom
• https://www.upguard.com/breaches/s3-localblox