AWS has revolutionized the way we build, deploy, and secure apps. But the security landscape is both deep and vast, and the nuances of these services can create confusion when looking for an AWS penetration test.
To help navigate this, we’ve boiled down some essential guidance for performing or contracting a pentest on AWS.
- What is an AWS Penetration Test?
- AWS Penetration Testing vs Traditional Penetration Testing
- The Importance of AWS Penetration Testing Scope
- Pentesting the Implementation of AWS Services
- Know What You Don’t Need in an AWS Pentest
What is an AWS Penetration Test?
An “AWS Penetration Test” actually has a few different meanings. And while all of these are valid, it’s important to know which one best fits your needs.
There are three common engagement styles for pentesting on AWS:
-
Application Pentest on AWS – You have a web or mobile based application hosted on AWS. You might have an array of services that support the platform like, EC2, RDS, S3, Lambda, etc. This assessment will largely resemble a traditional application pentest, but requires special consideration for specific AWS services used within your stack.
-
Network Pentest on AWS – Your organization does not necessarily have a flagship application or even develop any software at all. You may have migrated a datacenter to AWS and use infrastructure to support general business operations.
-
AWS Infrastructure Pentest – Your organization uses a vast and complex array of services for IT, applications, and users. You want to fully understand the effectiveness of IAM policies and permissions. This assessment will generally provide the pentester with various AWS keys and allow them to attempt to escalate privileges.
Knowing which of the items above is most applicable to you is an important first step getting started. And now that we know what type of pentest we’re talking about, let’s look at what makes these assessments so unique.
AWS Penetration Testing vs Traditional Penetration Testing
The differences between an AWS pentest and a traditional one can vary wildly. Some may be nearly identical, whereas others may be entirely tailored to your AWS workload.
The specialization required is subjective to both your application and AWS workload. Since it only takes one overlooked bug to have a major impact, it’s important to understand how each AWS service can be abused.
To illustrate this, let’s look at some examples of common old vs. new scenarios.
Example A: File Upload Vulnerabilities
Consider a web application that allows users to upload an image. A traditional pentest would require a tester to look for some of the following:
- Directory Traversal Attacks
- Review content type restrictions
- Review object access controls
An AWS Pentest would likely include some of the following additional attacks:
- Configuration of the S3 bucket.
- Object-level S3 permissions.
- Analysis of pre-signed keys generated.
A pentest team who is inexperienced with AWS may not identify S3 misconfigurations, and these frequently are the source of large data breaches.
Example B: Authentication Vulnerabilities
This example application also uses AWS Cognito with a user pool for authentication. Users are manually created in the AWS console to invite new customers. But this user pool has been mistakenly configured to allow users to self enroll.
Although the UI doesn’t have a signup form, an attacker can still interact directly with the Cognito API and create a user. To make things more complicated, a traditional API is not exposed, so an unfamiliar pentester is unlikely to be aware of such capabilities.
A savvy AWS pentester, however, would use the Cognito SDK to perform this test case, and bypass all authentication requirements:
The Importance of AWS Penetration Testing Scope
As we mentioned when choosing a pentest company, scoping is vital; and an AWS pentest only elevates that importance.
Chances are, your AWS stack has an attack surface larger than just elastic IPs. When scoping your pentest, ask yourself if you (or a vendor) is covering the following:
- That Beanstalk app that’s been forgotten about?
- The public facing RDS database in eu-west-2?
- Public and semi-public S3 bucket permissions?
- Elasticsearch instances?
These are the things that frequently fall between the gaps of traditional and AWS penetration tests. If you are contracting an assessment, the vendor should ideally be driving these questions, but it’s always best to have a solid understanding of what your attack surface consists of.
Pentesting the Implementation of AWS Services
Remember that as you build code using AWS services, vulnerabilities will manifest in unique ways. And while there is a unique threat model for each service, there are many additional abuse cases likely to be created as you continue to build.
Sometimes vulnerabilities arise when two software components are unaware of each other’s full behaviors. For example, we frequently find PDF rendering vulnerabilities that can be used to extract AWS access tokens.
In other cases, we’ve seen AWS Pinpoint used for critical logging functions, when configured with anonymous userpool access, a malicious user could omit or falsify application logs.
In all of these scenarios, there was no blatant misuse with any of these technologies. But just a small oversight in implementation can lead to serious security vulnerabilities.
Know What You Don’t Need in an AWS Pentest
Like all areas of cybersecurity, there’s no shortage of overstatements and promises of one click security. There are a couple things I always recommend looking out for:
-
Configuration Scanners – Automated tools like ScoutSuite are a quick and easy way to find AWS vulnerabilities; and while this is valuable, there are important limitations. These are limited strictly to predefined checks, and cannot analyze your application or implementation. These should not be considered ‘penetration testing’.
-
Improper Scoping – Playing a game of telephone between you, a sales person, a project manager, and pentester is a frequent starting point of failure. You should ensure that your pentester is sufficiently savvy with AWS and has had a chance to understand your ecosystem and give advice on scope.
-
Pentests that don’t actually focus on AWS – This is the most common scenario we see, where pentest teams are simply unaware of cloud security nuances and overlook cloud vulnerabilities.
Learning the Attack Surface of Services
As we discussed, many services introduce a unique attack surface. This requires a fair bit of time to understand the nuances and security model, but having knowledge of each of these is invaluable.
Below is a high level overview of AWS services and their implications for pentesters.
| AWS Service | Attack Surface |
|---|---|
| EC2 | EC2 has an attack surface similar to traditional physical infrastructure. Vulnerabilities that affect the OS will manifest exactly as they would on their hardware based counterpart. Things start to differ when you deal with anything that interacts with the local network or system. A vulnerability allowing command execution may allow an attacker to move laterally if configured with STS. Access tokens may also be stolen with SSRF vulnerabilities by reaching out to metadata IP addresses. More information: EC2 Pentesting in Depth |
| S3 | S3 requires careful consideration for bucket-level and object-level permissions. The S3 bucket itself can grant permissions to ‘Everyone’ or ‘Authenticated Users’. The ‘Authenticated Users’ permissions will grant access to all AWS users. Because of this a pentester must check both anonymous permissions as well as semi-public permissions with their own access tokens. More information: S3 Pentesting in Depth |
| ELB/ALB | Did you know an ELB can introduce HTTP Request Smuggling? This commonly overlooked configuration can allow attackers to inject requests into other user’s sessions. We have a full guide to pentesting ELBs. |
| SNS/SQS | Misconfigured topics or queues can allow unauthorized users to subscribe to topics or push messages to queues. Testing of this can be done with the AWS CLI. |
| RDS/Aurora/Redshift | Databases on AWS are relatively straightforward, although a penetration test should check for databases configured with public access. |
| EBS | EBS volumes can be made publicly available. The AWS CLI can be used to verify if EBS snapshots are publicly accessible. |
| Cognito Authentication | An AWS pentest should determine if the Cognito configuration is appropriate for intended application behavior. This includes checking for self-signups, and enabling advanced security. |
AWS Pentesting FAQ
Do I need to file a request for approval?
No. AWS no longer requires this process. Prior to 2019 AWS had required a form to be submitted and approved. The current policy allows for routine testing at your discretion.
Will Pentesting Impact Our AWS Environment?
Impact to availability is rare, however, the small possibility always exists. We generally recommend that a staging environment is used where testing can be done freely without risk of impact. Special precautions can always be taken when this is not possible.
Do I need to pentest inside my VPC(s)?
Great question. Traditional network pentests were performed from ‘internal’ and ‘external’ perspectives to simulate two types of threat actors. In AWS environments this objective does not translate directly to each VPC environment. This needs to be taken on a case by case basis. In many scenarios, there may be either low value or low technical feasibility to simulate such an actor. In other cases, it may be a very important exercise.
Conclusion
There are lots of tools and assessments that can help secure your AWS environment. We’ve built a platform to combine these and deliver a simply better AWS penetration test. We’d love to hear your feedback!
