Cybersecurity Awareness Month is here and in celebration, the Mariner Vulnerability Assessment and Penetration Testing team are showcasing some of their favorite hacking techniques. Each week in October, they will explain a vulnerability, demonstrate how they might exploit it, describe its potential impact, and maybe even share some tips on how you can protect yourself.

 

Mariner penetration testing services span a wide range of domains – web and mobile applications, internal and external infrastructures, phishing simulations, wireless security assessments, and more. Testing is performed by combining real-world techniques with tried-and-true standards to provide a realistic picture of your organization’s security posture. Vulnerabilities are identified, analyzed, and broken down with prioritized remedial recommendations to help your IT teams strengthen defences where you need it most.

Today is our last post in celebration of Cybersecurity Awareness Month. Be sure to check out the rest of the posts in this series: Stealing User Credentials with Open Redirects,  SQL Code Injection, Cracking Wireless Networks, and Bypassing Multi-Factor Authentication in Phishing Attacks

Broken access controls are one of the most prevalent vulnerabilities in modern application security and their impact varies widely. This is because modern application security tools and scanners cannot detect these issues, as they are often tightly coupled with the application’s business logic model and deployment configurations. There are a multitude of ways an attacker can gain unauthorized access to your application’s data, and this article focuses on a particularly dangerous one: insecure cloud storage buckets.

What is a Cloud Storage Bucket?

With the rise of deploying applications on cloud-based infrastructure, businesses have migrated their customers’ data to third-party infrastructure-as-a-service (IaaS) providers like Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and Digital Ocean to name a few. Cloud storage buckets provide a scalable and cost-effective means to host user-uploaded content. However, if not properly secured, it may result in a data breach and leaking of the data stored within.

Before we dive into the specifics of how attackers find misconfigured cloud storage buckets, we must first consider a cloud bucket’s permission model. While permissions vary in depending on the cloud provider, they generally fall into the following permission model:

• Anonymous Read
• Anonymous Listing
• Anonymous Writing
• Authenticated Read
• Authenticated Listing
• Authenticated Writing

In this context, “anonymous” means anyone with an internet connection. “Authenticated” means anyone with a cloud provider credential to access the data in the storage bucket.

Attacker’s Methodology

Let’s take an example where a fictitious company hosts an internet-facing application. Although there are many cloud providers, Amazon Web Services (AWS) is one of the most used in 2022 and will be the cloud provider of choice for this fictitious company. This example demonstrates a practical scenario on how an anonymous attacker on the public Internet may gain extensive access to sensitive information hosted by an application.

The attacker visits application’s main site. While navigating the site, the attacker will carefully look through all client-side source code and finds the following AWS S3 bucket in a JavaScript file.

Discovering the myfictitious-org-prod1 AWS S3 bucket in a JavaScript file after visiting the target’s website

At this point, the attacker may try listing the content of the bucket, as they try their luck on gaining unauthorized access to the data within it.

Failure to list the contents of myfictitious-org-prod1

They may also try writing to the bucket to see whether they can deface the application, or host malware and untasteful content on the victim’s infrastructure.

Failure to write content to myfictitious-org-prod1

Fortunately, the company’s DevOps team was aware that “hosting a cloud storage bucket on the public Internet” did not have any anonymous permissions enabled. This may be enough to make some attackers switch gears into finding other ways to compromise your product’s data or move to a different target.

From discovering the S3 bucket name, a savvy reader might recognize a pattern in this bucket’s naming convention. myfictitious-org–prod1 suggests that this is bucket was meant for a production environment. Since different cloud storage buckets are often used in other product deployments, an attacker could try guessing other affiliated storage buckets. For example, a few meaningful names to try would be:

• myfictitious-org-dev1
• myfictitious-org-test1
• myfictitious-org-staging1
• myfictitious-org-prod2
• myfictitious-org-test2

Words that fit this pattern are generated and placed into a wordlist, and piped into a “fuzzing tool”, which repeatedly and automatically attempts to discover resources using the wordlist. Real threat actors use this technique on the internet to constantly guess hundreds of cloud bucket names a second. These attackers use bots to “scrape” (extract information from) websites on the internet to find s3 bucket names they can try to brute force.

Leveraging the open-source web fuzzing tool ffuf to brute force S3 bucket names

The status codes in the screenshot above represent whether an attempt to access the bucket was successful or not. In the case above, a status of 403 means that the attacker did not have access to the bucket, but the bucket still exists. A status of 200 means that the bucket exists, and more importantly, anonymous attackers on the internet can access its data.

From the information above, the attacker determined that the myfictitious-org-test1 bucket exists and is highly likely to leak some of the company’s internal data.

Listing the contents of the myfictitious-org-test1 S3 bucket

The attacker will now download the test-deployment.sh file, which turns out to be a developer script containing secret, high privileged AWS credentials.

Gaining access to an AWS access-key and secret

Because the bucket had full anonymous access listing and reading enabled on the objects it stores, the attacker gained access to an internal script used by the company’s development team. It is notable that in a worst-case scenario, exposing AWS access keys may grant attackers full administrator access to your entire AWS deployment. From here, a typical pivot point attackers will take is to reuse captured credentials to gain unauthorized access to other resources. Perhaps trying to access the previously identified myfictitious-org-prod1 bucket with the credentials may allow the attacker to access all data hosted in that bucket.

Downloading all health records from the myfictitious-org-prod1 bucket to the attacker’s local computer

Once all health records were downloaded, the attacker can host the data on a private site, and demand a ransom from the victim company, threatening to leak all documents to the public should they not pay. Depending on the permissions associated with the compromised AWS key, the attacker may also create backdoors to persist within the victim’s AWS environment.

Lessons Learned

Hopefully, this demonstrated why the cyber security community recommends best practices. Although “best practices” may not be directly exploitable on their own, if many small mistakes are made, they can quickly add up to result in serious harm to your business and clients.

These were some of the mistakes made by the fictitious company:

• Security through obscurity: The assumption that an attacker would never be capable of guessing a cloud storage bucket that “should not have been discoverable”.
• Poor asset management: The myficticious-org-test1 bucket may have been an old asset forgotten by the fictitious company.
• Poor awareness of sensitive information exposure: An AWS credential was hosted in a cloud bucket. The example here was simple, but it might not be obvious if your company leveraged a continuous integration and delivery (CI/CD) pipeline where sensitive information may be read from a S3 bucket with anonymous access enabled.

Mitigations

To mitigate the likelihood and impact of such a data breach, the fictitious company could have performed the following actions:

• Review the access controls on all cloud provider buckets for all regions within your cloud provider.
• Setup alerts for when:
  • Cloud storage access controls are updated
  • New cloud storage buckets are created
• Keep the principle of least privilege in mind – nobody should have access to information or attack paths that could otherwise be used to grant them more access.
• Rotate cloud provider API keys on a regular basis, especially those for non-user accounts which may be accidentally exposed in scripts leveraged by internal staff.
• Take special care to ensure that the identities must first authenticate before they can access data hosted in your cloud storage buckets.
• Never grant anonymous access to cloud storage buckets that may host sensitive or internal information.

Does your organization host assets with cloud service providers? Are you concerned about the security posture of your current cloud deployment? Contact Mariner to speak with one of our application and cloud security consultants today!

—
Brian Yip, Senior Cybersecurity Consultant
Let’s Connect