# 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 ![](/files/qq0hTK5zgJcsZXgOXxnm) To see who you are run `aws sts get-caller-identity --profile stolencreds` ![](/files/TIDoFfVGYElQ5ltSQzUB) 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 * [What are these 'reserved' set of security-credentials in AWS?](https://ibreak.software/2020/04/what-are-these-reserved-set-of-security-credentials-in-aws/) * [Retrieving Security Credentials from Instance Metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials) * [Finding SSRF via HTML Injection inside a PDF file on AWS EC2](https://blog.appsecco.com/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2-214cc5ec5d90) * [SSRF to Shell via IAM Policies](https://speakerdeck.com/riyazwalikar/raining-shells-in-aws-by-chaining-vulnerabilities?slide=20) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xcriminal.gitbook.io/about-me/cloudsec/cloud-compute-with-aws/cloud-compute/ec2-metadata-intro-accessing-instance-data.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.