AWS EC2 Metadata Updates
Introduction
Amazon introduced version 2 of the AWS metadata service called Instance Meta Data Service version 2 (IMDSv2) in November 2019 which promises to protect against all exploitation attempts to access the metadata service via vanilla SSRF weaknesses.
What are we going to cover?
In this chapter, we will update the metadata service on our target to version 2 and see how our attacks fail and why the update actually secures the Instance metadata service.
What problem did the update solve?
Server Side Request Forgery can be an extremely lucrative finding to an attacker because of the ability to make requests from the target machine. When discovered on a cloud instance, things get a little more interesting as attackers can access the metadata instance, available via a APIPA range IP address over HTTP— http://169.254.169.254/, and accessible only from the target. For AWS this has always been a cause for concern as there was no authentication present to access this instance, and no requirement for a custom header that both GCP and Azure have.
In the most simple cases of an SSRF, a request to an attacker supplied URL is made from the server. For example, if there is a web application running on an AWS EC2 instance, a user supplied input like http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name would initiate a web request to the endpoint from the AWS EC2 resulting in a response being sent back to the client.
This works because
The most basic form of SSRF is a GET based vulnerability. A response for a user supplied URL is fetched via a HTTP GET request by the vulnerable web app/web server.
There is no authentication at the Instance Metadata endpoint. This allows for a simple GET request with no additional/custom headers to retrieve information.
The new Instance Metadata Service v2 (IMDSv2) tackles both of these conditions. IMDSv2 adds the following exploit mitigating changes to access the endpoint
The requirement of a HTTP header called x-aws-ec2-metadata-token that contains a value generated via a PUT request to http://169.254.169.254/latest/api/token
A PUT request to http://169.254.169.254/latest/api/token with the custom header x-aws-ec2-metadata-token-ttl-seconds with the value of the number of seconds for which the token needs to be active. This PUT request generates the token to be used in Step 1.
For a SSRF to succeed with this update, the attacker would need to be able to control the HTTP Method (force server to make a PUT instead of the standard GET) and be able to pass custom headers to the server, which the server then will use to make the requests.
This update fixes all vanilla SSRF where the attacker can only control the URL.
Steps to complete the exercise
To change the version of the metadata instance, we need to know the instance-id of the target machine.
You can obtain this from the AWS console, from the command line using aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,PrivateIpAddress,Tags]' or from the output that was displayed on screen when you ran deploy-compute-target.
Add the instance-id to the following command to upgrade the version of the metadata instance
Once the command has completed, try performing the previous SSRF exercises and see the difference in output
Additional exercise
After the upgrade is applied, you can use the following commands to work with the Instance Metadata Service. You need to be on the system to do this. Use a SSH session using the password that was found in the previous chapter.
Generate a token using the following command
Pass the token in the following command
Additional references
Last updated