Cloud Storage - Configuration Vulnerabilities

Cloud Storage

Configuration Vulnerabilities

Andrea Hauser
by Andrea Hauser
time to read: 13 minutes


  • Cloud storage services provide data storage at a remote location
  • Permissions for these cloud storage services are still sometimes granted incorrectly, although this is by no means a new issue
  • Both Google Cloud Storage buckets and Amazon S3 buckets have unambiguous identifiers that allow users to find a particular bucket
  • Amazon S3 buckets and Google Cloud Storage buckets both support permissions for "all users" or "all authenticated users", which are risky approaches

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:


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:

Successful access to the bucket

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

Bucket exists but access denied

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

There is no bucket that matches the name entered

To find buckets belonging to a company, you can access the URL by using personalized word lists with the structure <word> 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:

Permission Description
READ Anyone with READ permission can list all objects in the bucket.
WRITE WRITE permission allows the user to create, overwrite or delete objects in the bucket.
READ_ACP This permission allows the user to read the bucket access control policy list.
WRITE_ACP WRITE_ACP allows the user to write to the access control policy list.
FULL_CONTROL This level of permission allows the user to grant READ, WRITE, READ_ACP and WRITE_ACP permissions to others.

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, 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<bucketname>/.

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

Successful access to the bucket

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

Bucket exists but access not allowed

But there is a second method for accessing Google Cloud buckets – using the URL<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:

Successful access to

If the bucket doesn’t exist, or if access is denied, the following error message will appear in the 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.

Roles Description
storage.objectCreator This allows the user to create new objects. However, they cannot view, edit or delete existing objects.
storage.objectViewer Storage.objectViewer enables the user to see and list the content in a bucket.
storage.objectAdmin This grants complete control over objects. However, the user cannot read or edit bucket metadata.
storage.admin This grants complete control over the bucket and all existing objects.
Viewer A user with this permission can list buckets.
Editor This permission allows the user to create, edit and delete a bucket.
Owner This permission allows the user to create, edit and delete a bucket.
legacyBucketReader This allows the user to list the content of a bucket and display its metadata.
legacyBucketWriter In addition to reading the content of the bucket, content can also be created, overwritten or deleted.
legacyBucketOwner This role includes all of the same rights as legacyBucketWriter, but additionally grants permission to create and edit identity and access management policies.

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.


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

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)


You need support securing your cloud?

Our experts will get in contact with you!

XML Injection

XML Injection

Andrea Hauser

Burp Macros

Burp Macros

Andrea Hauser

WebSocket Fuzzing

WebSocket Fuzzing

Andrea Hauser

Prototype Pollution

Prototype Pollution

Andrea Hauser

You want more?

Further articles available here

You need support securing your cloud?

Our experts will get in contact with you!

You want more?

Further articles available here