AWS Cloud Security: How to Look for and Prevent the Most Common Pentest Vulnerabilities

AWS is the runaway leader in cloud infrastructure, with a staggering 33% of the market. So it’s no surprise that, as a pentesting provider, we spend a lot of time testing AWS assets and get asked fairly frequently about Amazon cloud security vulnerabilities. (For a primer on AWS cloud security and performing pentests to address AWS security concerns, check out our blog, “What You Need to Know About AWS Pentesting.”)

And we’ve noticed something. Through all our testing, we see a small number of vulnerabilities arise time and time again across a wide range of industries, asset types, and organization sizes.

Recently, we held a virtual panel where four of our pentesters discussed the most common security flaws in AWS environments and how to prevent them. This article is a summary of that virtual panel, and includes some suggested strategies for improving AWS cloud security.

6 Common AWS Vulnerabilities

1) Overuse of Public Subnets

Many organizations use the default Virtual Private Cloud (VPC) built into AWS, making few changes to the configuration. When they need to spin up an application, they take the simplest approach: using the VPC’s default public subnet.

However, this approach can be extremely dangerous. Public subnets are routed to Internet gateways, making them accessible via the public Internet. As a result, any sensitive information hosted on the subnet is placed in harm’s way.

Solution: Public subnets are suitable for blogs or simple websites, but not critical applications or databases. Instead, use private subnets and ensure all subnets are properly configured for the security needs of the assets involved.

If an application needs to be public-facing, you can use a combination of public and private subnets to ensure back end functions and databases are kept out of the public domain.

2) IAM Issues

IAM issues are far from being unique to AWS. However, because cloud infrastructure is designed to be accessed remotely, IAM issues can become an even greater risk and present a valid AWS security concern.

Many organizations don’t enable multi-factor authentication for privileged accounts. Worse, insecure privileged accounts are often overused — including for trivial tasks that could be performed from any account — putting them further at risk from social engineering and other credential theft attacks.

Solution: Use an identity solution provider to centralize authentication and use single sign-on so you don’t have to manually create IAM users and attach policies to them.

For sensitive assets, use a tool to create short term keys that expire after a predetermined period. That way, if access and secret keys are leaked, nobody will have persistent access to your AWS environment.

From a structural perspective, create different AWS accounts for different environments, and use a single AWS organization to enforce policies for sub environments.

3) Misconfigured S3 buckets

The most common problem with S3 buckets is permission misconfiguration. Organizations create S3 buckets for various purposes, and even though the buckets are private by default, we as humans make the buckets publicly writeable and readable to make our jobs easier. With this, there is an inevitable threat of malicious users finding the misconfigured S3 buckets and either dumping all the contents or deleting it. Misconfigured S3 buckets can be disastrous if there are sensitive files, db backups, or application logs in it.

Solution: If you want to store content in the bucket, that should be accessed publicly, use AWS Cloudfront. Keep the bucket private and use it as the origin of Cloudfront distribution. With this configuration, you will be allowing only Cloudfront to access content from the bucket. Any entities requiring access to the content from the bucket would need a full URI path that includes Cloudfront domain and doesn’t expose your S3 bucket for enumeration.

There are other hardening techniques provided by AWS such as signed URLs and signed cookies for serving private contents. Make sure to read up on the AWS documentation for insights on what to avoid. Further, read more about the dangers of misconfigurations.

4) Exposed Database Origin Servers

The IP addresses of database origin servers should never be available to any person or application unless specifically required. Unfortunately, these IPs are often available as a result of improperly configured CDNs and other solutions.

One of our pentesters gave an example of how this can lead to a security breach. While testing an HR system, the tester discovered that origin server IPs were available due to a misconfigured CDN. Once he had the IPs, he discovered that the AWS instance wasn’t set up to restrict inbound access to specific applications. Within a short period of time, he was able to access the system directly as a privileged user.

Solution: Secure configuration can be a challenge, because applications and infrastructure can each potentially have thousands of configuration options. Pentesters and cyber criminals use tools — many of which are free and open source — to help them identify when configuration issues exist.

To avoid falling victim to configuration issues, it makes sense for security teams to use a similar approach to identify and resolve configuration issues preemptively.

5) Server-Side Request Forgery (SSRF)

SSRF is an attack that abuses legitimate AWS functionality to gain access to instance metadata. If successful, an attacker may be able to extract credentials for an IAM role attached to the instance, and gain privileged access to the target application.

An attack similar to this was used in the 2019 CapitalOne breach.

Solution: Thankfully, preventing SSRF attacks against AWS is straightforward. Only version one of the Instance Metadata Service (IMDSv1) is vulnerable, so simply update to version two (IMDSv2).

6) Hanging DNS Records

In the course of working with AWS, most organizations create and delete plenty of S3 buckets. However, when an S3 bucket is deleted, many organizations forget to remove references to it across all subdomains.

This is a problem, because if a subdomain’s DNS records stay pointed to a deleted S3 bucket, an attacker can use subdomain enumeration to identify the issue and simply take over the subdomain.

Solution: Our pentesters offered a surprisingly low tech solution to this problem — simply keep track of all S3 buckets using a spreadsheet, and record all references to each bucket. Whenever an S3 bucket is deleted, use the spreadsheet to ensure all references to it are removed.

Treat AWS Like an Internal Network

To finish the webinar, our pentesters provided two powerful pieces of advice to help organizations improve the security of AWS environments.

First, always remember that cloud providers aren’t responsible for the security of anything you build in the cloud. AWS is just any other computer network, and you should be just as diligent with the security and privacy of your AWS network as with your internal network.

Second, keep in mind that developers generally aren’t security experts. Providing training on secure development practices can have a profound impact on the security of new code. It can also be helpful to implement basic checks — potentially including automated vulnerability scanners — into the development workflow to identify simple vulnerabilities before they are pushed live.