AWS EC2 IMDSv2 versus an esoteric HTTP Method

Our investigation to see if the IMDSv2 can be attacked using the obscure X-HTTP-Method-Override HTTP header. The definitive answer is no.

An interesting Twitter discussion started this all

Couple of days ago, we came across a Twitter discussion (screenshot below)

A security researcher named Ebrahim used the X-HTTP-Method-Override (XHMO) HTTP header to force an application to tunnel a different HTTP method within a GET request on cloud.google.com to achieve information disclosure. Read that awesome blogpost on Ebrahim’s blog.

This post caught the attention of a bunch of security folks who were curious that this could be used to bypass IMDSv2 on AWS EC2 instances.

What follows is how we confirmed that it is not a bypass for AWS EC2 IMDSv2

Test Cases

To try this out in your labs, spin up an EC2 instance and modify the instance metadata service to version 2. We recently blogged in detail explaining how you can migrate to IMDSv2

Getting started with Version 2 of AWS EC2 Instance Metadata service (IMDSv2)

Security mitigations IMDSv2 provides

IMDSv2 mitigates two key requirements that allowed Server Side Request Forgeries (SSRF) to extract data from EC2 metadata endpoints

1. The most basic form of SSRF is a HTTP 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 metadata 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.

To be able to bypass the session oriented approach that IMDSv2 takes, we would need to

1. Control the HTTP method being passed to the metadata endpoint
2. Have the ability to add additional headers

Enter the X-HTTP-Method-Override HTTP header. This HTTP header when parsed by a middleware (WAF/reverse proxies/load balancers etc.) that supports HTTP method delegation (can be programmed as a handler function) overrides the HTTP method as requested by the client.

Consider the following HTTP request to a target with a WAF that rejects PUT method but allows a POST

POST /a.php HTTP/1.1
Host: example.com
X-HTTP-Method-Override: PUT
Content-Length: 27
Content-Type: application/x-www-form-urlencoded
<?php system($_GET['x']) ?>

The client makes a POST request with the XHMO header, the middleware changes the request to a PUT request and creates the a.php file resulting in a RCE (assuming WebDAV with write support via PUT is allowed) bypassing the PUT rejection filter that the middleware had implemented.

We decided to test if the IMDSv2 endpoint supports the X-HTTP-Method-Override HTTP header which could have resulted in a SSRF with header control to bypass method restriction based WAFs etc.

All commands are run from a SSH session to an EC2 instance where IMDSv2 is enabled.

The first test case was to use the standard GET method with the XHMO header

curl -H "X-HTTP-Method-Override: PUT" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://169.254.169.254/latest/api/token -v

resulting in a 405 Method Not Allowed

The second test case was to use the standard POST method with the XHMO header

curl -X POST -H "X-HTTP-Method-Override: PUT" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://169.254.169.254/latest/api/token -d "abc=xyz" -v

also resulting in a 405 Method Not Allowed

IMDSv2 provides adequate defence against further exploitation of SSRF vulnerabilities on applications hosted on AWS EC2 machines

In conclusion — IMDSv2 is well protected against XHMO header

As is evident, the IMDSv2 endpoint does not support the XHMO header.

However, a middleware server or application that understands the XHMO header may be able to translate a GET or a POST to a PUT to generate the metadata token.

There are a lot of caveats though as we need to send additional headers to a SSRF vulnerable endpoint. Given the two primary restrictions that IMDSv2 implements, namely usage of a PUT method and custom headers to retrieve a session token and subsequent metadata queries, most SSRF vulnerabilities will not be able to abuse the metadata endpoint.

However, during our research into what scenarios could still exist where an SSRF (or similar) vulnerability could lead to access and abuse of the IMDSv2 endpoint, we came up with six potential scenarios.

More about those in upcoming blogposts. We are also planning to release a simple vulnerable web application with the scenarios as described in the upcoming posts that you can use to practice and understand IMDSv2 and its exploitation better.

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”.

We are also delivering a new AWS Attack and Defence focused training called Attack and Defence in AWS: Chaining application security vulnerabilities to go beyond OWASP Top 10. Our first public batch of this training will be at Troopers20 (Sign up | More information about the courseware | Announcement post)

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.