Server Side Request Forgery (SSRF) and AWS EC2 instances after Instance Meta Data Service version 2(IMDSv2)

A short blogpost about how the introduction of IMDSv2 affects SSRF attempts on AWS EC2 instances, especially when attempting to retrieve metadata information.

Having blogged about exploiting SSRF on AWS EC2 instances in the past, we wanted to give you an update on where things stand now.

Multiple scenarios to attack and exploit AWS misconfigurations which includes a scenario to perform SSRF on AWS EC2 on pre IMDSv2 setups — https://blog.appsecco.com/getting-shell-and-data-access-in-aws-by-chaining-vulnerabilities-7630fa57c7ed

The technical side of how the Capital One breach occurred, the impact of the breach and what you can do as a user of cloud services to prevent this from happening to you — https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af

Background

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.

A successful SSRF attack meant that the attacker would be able to query the instance and retrieve AWS EC2 specific information and in the worst case, temporary credentials attached to the AWS EC2.

An attacker could then impersonate the role attached to the machine using the temporary credentials and do additional discovery or damage.

With the introduction of the version 2 of the Instance Metadata by AWS, authentication is now a requirement to query the endpoint.

What does the defence look like to an attacker

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

1. 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.
2. 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

1. 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
2. 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.

Do I stop searching for SSRF on AWS EC2?

Definitely not.

This is a fairly new update. As with any new feature that is introduced after a long interval, the adoption rate is going to be slow.

Just because AWS released an optional security fix, doesn’t mean that everyone is going to discard IMDSv1 anytime soon enough!

Infra and ops teams that rely on automated scripts to perform actions on AWS EC2 instances based on metadata information will need to update their scripts, add provision to make PUT requests, use the tokens in ALL other requests etc. So, yeah lot of work is needed for everyone to start using this.

Which means, as attackers, there are going to be a lot of applications out there whose AWS EC2 host machines are not going to be updated any time soon for “legacy reasons”.

This update does not protect applications that are vulnerable to more advanced forms of SSRF. A web application or a network aware service that allows you to craft a complete HTTP request and then makes that request on your behalf from the server, will still be vulnerable. Common examples would be API proxying applications, API query builders with API console access (think old Apigee days), web functionality with command argument or vanilla command injection would still be vulnerable.

Any other vulnerabilities that allow for a complete control of the HTTP request to be made would still go through. For example, a SQL Injection vulnerability for a MSSQL backend could potentially allow a HTTP request to be made via xp_cmdshell and a Windows curl binary in a post exploitation setup. The scenarios are plenty, limited only by our imagination.

That said, it is important to note that this is a new feature, is not enabled by default and will likely not be used in systems where a lot of dependency is present on version 1.

You can read our post on how to enable this feature, if you want to test it out in your environment here — https://blog.appsecco.com/getting-started-with-version-2-of-aws-ec2-instance-metadata-service-imdsv2-2ad03a1f3650

References

1. https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
3. https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html

At Appsecco we provide advice, testing and training around software, infra, web and mobile apps, especially that are cloud hosted. We also specialise in auditing AWS environments as per the AWS CIS Foundations Benchmark to create a picture of the current state of security in your AWS environment. Our experience has led us to creating multiple hands on training courses like the very popular “Breaking and Pwning Apps and Servers on AWS and Azure” and “Automated Defence using Cloud Services for AWS, Azure and GCP”.

Drop us an email, contact@appsecco.com if you would like us to assess the security of your AWS infrastructure or if you would like your security team trained in advanced pentesting techniques against AWS.