AWS Penetration Testing
- Credentials Disclosed in Environment variables
- EBS Volume Publicly Accessible
JUMP TO
What is an AWS
penetration test?
all of these are valid, it’s important to know which one best fits your needs.
-
01.
Application Pentest
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.
-
02.
Network Pentest
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. Knowing which of the items above is most applicable to you is an important first step getting star.
-
03.
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.
Learning the attack
surface of services
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
-
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.
EC2
-
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.
S3
-
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.
ELB/ALB
-
EBS volumes can be made publicly available. The AWS CLI can be used to verify if EBS snapshots are publicly accessible.
EBS
-
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.
SNS/SQS
-
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.
Cognito
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 – AWS Pentest vs. Conventional
-
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:
traditional pentest
- Directory Traversal Attacks
- Review content type restrictions
- Review object access controls
-
An AWS Pentest would likely include some of the following additional attacks:
AWS Pentest
- Configuration of the S3 bucket.
- Object-level S3 permissions.
- Analysis of pre-signed keys generated
EXAMPLE B:
Authentication Vulnerabilities
resp = client. sign Up
ClientId=CLIENT_ ID,
SecretHash=get_secret_hash (username),
Username=username,
Password-password,
UserAttributes=[
{
'Name': "name",
'Value': "Pentester"
}
],
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:
-
01.
That Beanstalk app that’s been
forgotten about? -
02.
Public and semi-public S3
bucket permissions? -
03.
The public facing RDS database
in eu-west-2? -
04.
Elastic search 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
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.
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.
