Accessing instance data via SSRF

Introduction

The instance metadata endpoint is the most widely accessed endpoint once an app running on AWS (and other cloud providers) is found to be vulnerable to SSRF. The instance metadata endpoint, not only gives you access to useful instance specific information, but also to temporary credentials generated via an attached instance profile.

What are we going to cover?

This chapter will cover an attack that can be used to read the instance metadata endpoint and traverse its tree structure to obtain useful information. We will also use the attack to eventually extract IAM credentials that can be used to gain additional leverage within the cloud account.

Steps to attack

The instance metadata endpoint

The instance metadata service (IMDS) endpoint is accessible on every instance deployed on AWS (unless explicitly disabled during EC2 creation). The endpoint can be accessed at http://169.254.169.254/ as a non routable address and is reachable only from the machine.

Due to its access restriction, the endpoint can be accessed when conditions like these are met

  1. You have SSH/Shell access to the instance

  2. There is a vulnerability in an app, service or network accessible program that allows you to make requests to the endpoint

Take a look at the application that is deployed on the compute-target EC2 instance by browsing to http://10.0.100.11. This will only be accessible if a SSH tunnel to the cloudhacker machine is open on the student machine.

Can you identify what web application vulnerability is present here?

A server side request forgery, essentially allows an attacker to pass custom targets via user input that the application makes a request to without sanitizing the input.

Some interesting information that can be extracted from the IMDS endpoint include

  • AMI-ID that was used to create the EC2 - http://169.254.169.254/latest/meta-data/ami-id

  • Instance ID of the EC2 instance - http://169.254.169.254/latest/meta-data/instance-id

  • Public IPv4 if it exists for the EC2 instance - http://169.254.169.254/latest/meta-data/public-ipv4

Can you folks identify the Security Group attached to the instance?

There is also a not so very well documented endpoint that allows you to generate IAM Instance credentials that AWS uses. These don't have access any documented service in your AWS account. You can get them here - http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance. See references for more details.

Generate Temporary Role Credentials

In AWS you can attach an IAM role to an EC2 instance so that the instance (or programs running on it) can generate temporary credentials and perform actions on behalf of the instance.

For example, when an EC2 instance requires the ability to write to an S3 bucket, a program running locally on that machine would be able to make a request to the IAM IMDS endpoint, generate temporary credentials and perform the required action.

For an attacker, an SSRF on an application running on an EC2 allows you to perform the same steps as a program running locally. Use the following URLs to generate the credentials.

http://169.254.169.254/latest/meta-data/

http://169.254.169.254/latest/meta-data/iam/

http://169.254.169.254/latest/meta-data/iam/security-credentials/

What is the endpoint where credentials can be discovered?

Once credentials are discovered, you may notice that these are essentially 3 values

  • aws_access_key_id

  • aws_secret_access_key

  • aws_session_token

To add them to your local aws cli without overwriting your current configuration, follow these steps very carefully

  1. Run aws configure --profile stolencreds

  2. Provide the stolen values correctly. Enter us-east-1 for region and json for output

  3. Once done, open the ~/.aws/credentials file in a text editor

  4. Under the [stolencreds] section add aws_session_token and add the discovered token value here

To see who you are run aws sts get-caller-identity --profile stolencreds

Any number of profiles can be created. As and when you find credentials, add them to the cli config using different --profile options. Remember to not overwrite the default profile!

Once you have configured the stolen credentials, you can then run any AWS command as if you were using your own AWS account (of course as long as the role from whom the credentials have been generated, have the necessary permissions).

Additional references

PreviousAttacking EC2 instances - Lab setupNextAWS EC2 Reverse Shell via SSM

Last updated