A Brief Intro to Cloud Computing & Cloud Storage
Cloud computing has revolutionized the way in which we deploy infrastructure and has massively lowered the technical bar to entry. It’s no longer necessary to have years of experience to deploy an unfamiliar operating system or application, it can be often done in just a few clicks through an easy-to-use interface and be available for use within minutes.
One of the biggest benefits of cloud computing is the introduction of cloud storage services like AWS S3 which allows for data storage in buckets. These services allow organizations to have redundant, secure, scalable, and performant storage configured and available within just a few minutes and without the upfront cost of purchasing hardware.
Buckets and Data Leaks
In recent times there have been some high profile data leaks because of misconfigured buckets, below are just a few examples from 2023:
- Capita had the data of councils, residents and other sensitive data leaked because of a misconfigured S3 bucket
- PWC Nigeria were subject to a data breach from a misconfigured S3 bucket, having passports, and full addresses of bootcamp participants
- MPD FM had passport, visa and employee data snatched because of a misconfigured S3 bucket
The impact in each of the cases above was a a total loss of confidentiality. Depending on location this can result in hefty financial penalties alongside the damage to reputation, this is why it’s so important to ensure that services like S3 are configured with the appropriate bucket policies to safeguard data.
The remainder of this post will focus on AWS S3, but it’s important to understand that this type of misconfiguration is also applicable to Azure, Linode, DigitalOcean, and other S3-compatible storage providers.
What Is A Bucket Policy?
A bucket policy serves as a type of policy associated with AWS (Amazon Web Services) Identity and Access Management (IAM) that can be linked to an S3 bucket. It's utilized for setting permissions on both the bucket and its contained objects, enabling the definition of permitted or prohibited actions on your S3 resources. If you’re familiar with operating systems and applying permissions to directories and files, the concept is very similar and as granular.
Bucket policies can be difficult to configure, particularly if you are new to the concept as they are written in JSON and the policy language has its own syntax that needs to be used. Below is an example from the AWS userguide:
In the above policy, it allows Dave, a user in account Account-ID, s3:GetObject, s3:GetBucketLocation, and s3:ListBucket Amazon S3 permissions on the awsexamplebucket1 bucket. This is a simple example, but it’s easy to see how this could get confusing, and when it’s necessary to have some level of public access on a bucket, it can get even more complicated and is easy to make mistakes.
Example Scenario: DataCo
DataCo want to share sales data between representatives who work in satellite offices, and have decided the best way to do this is to use an S3 bucket. Since they have no centralized IT and people often use their own devices, they’ve decided to leave the bucket publicly accessible and share links over WhatsApp. The sales team aren’t massively technical, so they want it to be as simple as possible to use. MFA and logins are probably going to be a steep learning curve for them.
After creating the bucket dataco-salesreps, the IT team decide on the following bucket policy:
In the above we’re interested in the principal, the effect, the action, and the resource. Each are described below:
- Effect: The outcome of the policy if the the criteria is met, in this case it’ll be
Allow. - Principal: Who it affects, in this case it’s
*- this means anyone. - Action: The specific action it applies to, in the above this applies to the action
s3:ListBucket&s3:GetObject, these mean listing the contents of the bucket and getting an object from the bucket, respectively. - Resource: The specific resource it applies to, in the above this is our bucket and our buckets contents.
It looks relatively harmless. The bucket dataco-salesreps has no write access granted, and importantly, for an attacker to read anything, they first need to know the bucket name to access it and nobody could easily guess this name, right?
Finding the S3 Bucket
Finding the bucket name may seem like a difficult task, but it’s something easily automatable with offensive security tooling, as shown below with s3gobuster:
As you can see from the above, it didn’t take too much effort with the prefix of the company name to find the bucket using a standard wordlist. It’s worth noting that with a more obscure name it’d take longer to find, but with a similar process of brute force it would be discoverable. Security through obscurity often only slows down an attacker, it doesn’t stop a motivated attacker.
With this newly found information, it’s now possible to test the public facing URL using the bucket name. We’ll try against us-east-1 since this is the standard location for buckets on creation if no change is made:
We’ll need to try again on the given URL from the response as it looks like it’s not on us-east-1 but on us-east-2:
We’ve found the bucket and we are now able to list the contents of it! We are now also able to now download the object banking.xlsx by appending it to the URL. Though this would be a targeted attack and may seem a little far-fetched, it’s a very real step used by attackers to gather further intelligence on their targets.
But this looks like an easy fix! We’ll remove ListBucket from the policy, this way they can’t list the contents of the bucket, even if they manage to guess the bucket name.
Finding Objects when ListBucket is removed from the policy
Even if file listing was not available because ListBucket was removed from the policy and we received an access denied error, it would still be possible to brute force the URL for objects on the discovered bucket, as shown below:
Again, though it would be possible to name more obscurely, with time, resource, and effort it would still be likely that an attacker could locate objects in the bucket.
OSINT to Find Insecure S3 Buckets
As well as targeted attacks like the examples above, there are tools like Public Buckets by GrayHat Warfare that automatically scan for buckets, and index content found from discovered buckets. Public Buckets provides an easy-to-use interface for searching the indexed information making it very simple to search for keywords specific to an organization.
Below is an example search on Public Buckets:
As Public Buckets and similar tools are often freemium with some level of access available without paying, it also opens up the potential for opportunist attackers who come across sensitive data. This is why it’s so important that buckets that are configured as publicly accessible only contain data that an organization is happy to have in the hands of anyone on the internet, the assumption should be that if it’s out there with public access set, it will be found by someone online.
Summary
Though there are some valid uses for publicly accessible buckets, this configuration should be used with care as slight misconfigurations can lead to major leaks. It’s important to understand the effective permissions once implementing a policy on an S3 bucket, and the principal of least privilege should always be a part of decisions on who should be able to access a resource.
AWS offers best practices for securing S3 buckets can be found here, below is a brief summary of the key points:
- Disable ACLs
- Ensure that your Amazon S3 buckets use the correct policies and are not publicly accessible
- Identify and audit your buckets and their effective permissions
- Implement least privilege access
- Use IAM roles for applications and AWS services that require Amazon S3 access
Though this post has focused specifically on AWS S3, the same concepts apply to Azure Blob storage, as well as other cloud providers and their own S3 compatible storage offerings.
Tools used:
s3gobuster: 
GitHub - n0mi1k/s3gobuster: A fast S3 bucket suffix brute force tool to identify existing buckets
feroxbuster: GitHub - epi052/feroxbuster: A fast, simple, recursive content discovery tool written in Rust.
Public Buckets: 
Public Buckets by GrayhatWarfare
About SBT, provider of online blue team training
Security Blue Team is a leading online defensive cybersecurity training provider with over 100,000 students worldwide, and training security teams across governments, military units, law enforcement agencies, managed security providers, and many more industries.
