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.
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:
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.
Under the default configuration, an Amazon S3 bucket is not publicly accessible, and access must be explicitly granted. The following permissions exist:
|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 flaws.cloud, which takes a light-hearted approach to the cases cited above and presents some other examples as well.
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.
Like Amazon S3 buckets, Google Cloud Storage has one unique URL per storage container, in the format
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
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.
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.
|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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here