EC2 SSRF Attack
A walkthrough demonstrating a Server Side Request Forgery attack leading to credit card data exfiltration.
CTF Source: Pwned Labs
Overview
In this walkthrough, we'll perform a Server Side Request Forgery (SSRF) attack leading to the compromise and exfiltration of credit card data. The lab is meant to mimic the 2019 Capital One data breach which also involved exploitation of SSRF, abusing EC2's metadata service, and gaining credentials to an IAM Role.
Pre-Requisites
Install awscli:
brew install awscli(mac)apt install awscli(linux)
Walkthrough
Accessing the website & identifying the server
We start our engagement with an IP address 52.6.119.121 and are led to believe it goes to a website.
When attempting to access the website in the browser, it redirects to http://hugelogistics.pwn/
We can also confirm this with curl -I 52.6.119.121 to see the headers
We can update our /etc/hosts file like so, allowing us to view the webpage
sudosince/etc/hostsrequires elevated permissionsshto execute a shell command-c to enable reading the string as a command
Now, we can view the webpage
If we want to understand who owns the website we can run whois 52.6.119.121 and see it’s an Amazon IP specifically for EC2.
We can also do nslookup 52.6.119.121 and confirm the DNS Hostname of the EC2 instance.
We also learn this is in the us-east-1 region according to Amazon’s doc -
A public (external) IPv4 DNS hostname takes the form
ec2-public-ipv4-address.compute-1.amazonaws.comfor theus-east-1Region, andec2-public-ipv4-address.region.compute.amazonaws.comfor other Regions.
Identifying the backend storage
Let’s take a look at the website source code.
We can see the website uses S3 as its storage backend. Let’s try to access the bucket contents.
--no-sign-requestis needed so we’re not signing the request with any local aws credentials--recursivewill try enumerating the full bucket contents
As we can see there’s a ton of data in the bucket. The backup/ folder looks interesting. Can we copy it locally?
Unfortunately not.
Identifying and Exploiting an SSRF Vulnerability
Heading back to the website we find the Status page in the menu bar.
Clicking this takes us to a webpage that appears to run a php script when clicking the Check button.
Looking at the website source code, we can assume it’s taking hugelogisticsstatus.pwn and sending it to the server.
So, we do know this website is hosted on EC2 as we discovered earlier.
EC2 has a meta-data service that is available at a local address of 169.254.169.254.
If the PHP script is not doing proper validation, we could attempt to access this service.
With the instance meta-data service or IMDS, we can find out a ton of information about the instance such as if it has an IAM role assigned to it.
We can also inspect any user data such as initialization scripts admins might use to configure EC2 which may contain credentials.
Let’s give it a shot! We can attempt this in either the browser or the terminal. I’ll use the terminal.
We don’t get anything back other than the website code. Let’s try to check the meta-data instead.
Success! We can access data on the instance. Let’s find out if an IAM role/credentials are tied to this EC2.
We can assume it might since it’s pulling data from S3 for the website.
If we look at Amazon’s documentation, we’ll first try iam/info
And look at that! We just confirmed the EC2 has an instance profile assigned to it. Let’s grab the name MetapwnedS3Access and leverage another category to grab its credentials.
Are you as excited as I am right now?
Whoami?
Let’s configure our local AWS credentials and attempt to use the ones we just found.
Just run aws configure and it’ll prompt you to copy/paste the AccessKeyId and SecretAccessKey.
After that, we’ll need to add the Token since this is an IAM Role we’re using. We can do it like so:
Next, we’ll run a command to check our identity. Similar to running whoami.
Nice. Let’s see what permissions we have by inspecting our attached IAM policies. This will check for any managed policies attached to our role.
Bummer. No permission to view this. Well, let’s see if we can view inline policies.
Okay, no dice. Not to fret, this was just to try and enumerate all permissions this IAM Role has. We can assume it has access to the S3 bucket we discovered earlier.
Access the S3 Bucket Files
Let’s try and access those backup files.
Success! We discovered the flag and what appear to be plaintext credit card numbers!
Wrap-up
So, much like the attackers who breached Capital One in 2019, we also performed a Server Side Request Forgery (SSRF) attack.
This led to us gaining access to an EC2’s IMDS, discovering the EC2’s instance role credentials, and gaining access to an S3 bucket used for both the static website it was hosting and for sensitive credit card data.
From a defender’s perspective, there are a few things that should be addressed.
The S3 bucket was being used for multiple functions (hosting a website and storing credit card data)
These should have been separate buckets - especially for something as sensitive as the CC data
Multiple functions mean complicating permissions which can lead to misconfiguration and errors
The S3 bucket contents could be seen by anyone in the world
This enabled us to have our interest peaked when we saw
back/cc-export2.txtand should have been prevented
The PHP script wasn’t using proper input validation
This allowed us to access IMDS
IMDS
If the service isn’t needed, it can be disabled (see Example 2)
If it’s needed, use IMDSv2 which can require session tokens for authentication with the service. However, the attack in this scenario is still possible since we can use the SSRF vulnerability to generate a session token. (see Amazon doc)
Last updated
