Beyond the basics: techniques every pentester should know to exploit AWS Infrastructure — Part 2/X
The first part can be found here.
In this second part, we will deep dive more on reconnaissance technique or exploitation on AWS.
Reconnaissance techniques
1) Tools examples
Several tools exist to facilitate enumeration (especially when you already have a user/role or if you find an AWS Access Key in the wild).
Here is a non-exhaustive list:
- Pacu: open-source AWS exploitation framework, few modules don’t require access Keys
- ScoutSuite : it’s more a CSPM like tool and focused on audit
- Bucket Finder: focus on public bucket
- AWS List All: like the name suggests … enumerate everything …
For some of these tools, you will need to have access to the AWS account you want to audit.
However, you may also find access keys in the wild …
2) Where AWS Access Keys may be found?
a) Code repositories (GitHub, BitBucket, …)
GitHub is a common location where developers store and share code. Unfortunately, developers sometimes commit code that contains AWS access keys to their repositories. Most of the time, this occurs accidentally.
Various tools have been developed to search for exposed keys on GitHub:
One of my colleagues, at Decathlon, wrote an article about how to find secrets in a Github organization with a step-by-step technical guide. It is worth a try ;)
To mitigate this kind of issue, developers must use environment variables or, even better, a vault, to store access keys instead of hardcoding them in code.
Once a secret has been published on a public Github repository (or any public place) it is important to rotate it as soon as possible. Malicious actors use bots to scan the Internet, looking for secrets and we have seen cases in which a secret was used by a malicious actor less than 10 minutes after it was published on Github.
b) Website files
AWS access keys can also be found in files hosted on websites. For example, a developer might accidentally leave an access key in a configuration file used by a web application.
If you are using burp, two extensions exist and allow finding secrets, like AWS access key:
These extensions are great but only focus on a few secrets. One idea would be to take all the regex from the secrets-patterns-db repository and create one burp extension with all the regex. Feel free to credit me for the ideas ;)
c) Email or messaging services
Access keys may be shared over email or messaging services like Slack or Microsoft Teams, either intentionally or unintentionally.
If you have access to a mailbox/Slack/Microsoft Teams or whatever the messaging service, try to search inside potential Access Key.
d) Server-Side Request Forgery (SSRF)
SSRF stands for Server-Side Request Forgery. It is a vulnerability that occurs when an attacker is able to manipulate the server into making a request to a URL specified by the attacker. The attacker is essentially able to forge a request from the server, hence the name “request forgery”.
This vulnerability is particularly dangerous because it allows an attacker to access resources on the internal network that are not intended to be accessible from the internet.
I will deep dive into this vulnerability in the next paragraph, but be aware that exploiting a SSRF allows an attacker to grab credentials, the one used by the EC2.
Exploitation
1) How to exploit a SSRF?
The vulnerability remains the same for all cloud providers, but the exploitation is different depending on the cloud provider used. Here are links if you want to exploit them on other Cloud Providers like GCP.
AWS Instance Metadata Service (IMDS) is a service provided by Amazon that allows EC2 instances running in an AWS environment to retrieve information about themselves, such as their instance ID, instance type, hostname, and more. The full list can be found here. This information is useful for automating tasks, configuring software, and performing various operations within the context of the instance.
As we noticed, the AWS metadata endpoint provides useful information about an EC2 instance and can be accessed from within the instance via the URL http://169.254.169.254. There are two versions of the metadata endpoint: IMDSv1 and IMDSv2.
- Version 1 (IMDSv1) allows for access via GET requests, making it vulnerable to SSRF attacks.
- Version 2 (IMDSv2) requires a token obtained via a PUT request with an HTTP header, which adds an extra layer of security and makes it more difficult to exploit with a SSRF. Also, the TTL of the token is short-live (by default set to 1)
To understand why, let’s first define what TTL means. TTL is a value in an IP packet that determines how many network hops the packet can take before being discarded. When the TTL reaches 0, the packet is dropped, and an ICMP message is sent back to the sender indicating that the packet has expired.
In the context of IMDSv2, setting the TTL to 1 means that the request can only be routed to the immediate next-hop network device, which in this case is the instance’s local network interface. This limits the attack surface by preventing the request from being forwarded to other network devices that could be used to carry out the SSRF attack.
IMDSv2 is definitely a great move from Amazon, and even better, as of October 2022, Amazon Machine Images now supports the version 2 instance metadata service by default
So, now, let’s explain it in a real-world example, with PHP Symfony, how to exploit this vulnerability and gather some creds 😍.
This code is vulnerable to Server-Side Request Forgery (SSRF) attacks because it blindly fetches the image from the URL specified in the url query parameter without verifying that the URL is safe or valid.
A classic query would be
Imagine that you can run
And boom!!! Here are your creds.
As shown at the beginning of the paragraph, you can gather a lot of information with this vulnerability. Here is the complete list of metadata endpoints in the AWS documentation.
A Github repository describes also more possibilities like getting keys or exploitation on other Cloud provider, feel free to have a look
Laurence Tennant wrote an amazing article in March 2023, a deep dive into the mitigation of SSRF in 2023. I really encourage you to go and read it, it’s worth the read
2) Publicly exposed services
During your enumeration, you might find exposed resources to the Internet.
A script has been developed to help you to fetch all public addresses associated with an AWS account
Here are the services supported by this script:
- APIGateway
- CloudFront
- EC2 (and as a result: ECS, EKS, Beanstalk, Fargate, Batch, & NAT Instances)
- ElasticSearch
- ELB (Classic ELB)
- ELBv2 (ALB/NLB)
- Lightsail
- RDS
- Redshift
You can also use Shodan, Censys, Onyphe, Leakyx or Grayhatwarfare
For example, on Shodan, we can imagine this query to find all resources hosted by AWS Ireland:
On Greyhatwarfare, just enter your keywords (like the company name or the brands) to find juicy buckets exposed.
And of course, if you find an EC2, scan it as usual with nmap.
That’s all regarding reconnaissance technique and exploitation. There are a lot more to say so feel free to search on Google.
For example, RhinoSecurityLabs released few days after the release of this article, few tips on how to exploit AWS Cognito.
See you soon for the third part!
How about you?
Do you have experience using AWS? Do you have some additional recommendations? Let us know in the comments below!
🙏🏼 If you enjoy reading this article, please consider giving it a few 👏👏👏
If you are interested in joining Decathlon Tech Team, check out our carriers portal to see the different exciting opportunities ! 👩💻👨💻
