EC2 SSRF Attack
A walkthrough demonstrating a Server Side Request Forgery attack leading to credit card data exfiltration.
Last updated
Was this helpful?
A walkthrough demonstrating a Server Side Request Forgery attack leading to credit card data exfiltration.
Last updated
Was this helpful?
CTF Source:
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 which also involved exploitation of SSRF, abusing EC2's metadata service, and gaining credentials to an IAM Role.
Install awscli: brew install awscli (mac) apt install awscli (linux)
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
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
sudo since /etc/hosts requires elevated permissions
sh to 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.
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.
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-request is needed so we’re not signing the request with any local aws credentials
--recursive will 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.
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.
If the PHP script is not doing proper validation, we could attempt to access this service.
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.
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?
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.
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.
Let’s try and access those backup files.
Success! We discovered the flag and what appear to be plaintext credit card numbers!
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.txt and should have been prevented
The PHP script wasn’t using proper input validation
This allowed us to access IMDS
IMDS
We also learn this is in the us-east-1 region according to -
EC2 has a that is available at a local address of 169.254.169.254.
With the instance meta-data service or IMDS, we can find out a ton of information about the such as if it has an IAM role assigned to it.
We can also inspect any such as initialization scripts admins might use to configure EC2 which may contain credentials.
If we look at , we’ll first try iam/info
Nice. Let’s see what permissions we have by inspecting our attached IAM policies. This will check for any to our role.
Bummer. No permission to view this. Well, let’s see if we can view .
So, much like the attackers who , we also performed a attack.
If the service isn’t needed, it can be disabled (see )
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 )
