6 January 2023

Shift Left Security: Why You Should Use AWS IMDSv2 Explained in Detail

Very recently, an article about Cloud Metadata security was brought to my attention: Cloud Metadata - AWS IAM Credential Abuse. In short, this article is about a Server Side Request Forgery attack on a poorly designed web application. The attack shows how to exfiltrate IAM credentials and what can be done with those compromised credentials. The article concludes with security enhancement to mitigate SSRF attacks and protect Cloud Server Metadata. Kudos to Mark for writing this nice article!

Upgrading to IMDSv2 is something I evangelism myself, but in all honesty, I never dug deep into its value. In this post, I’ll use the article mentioned above to describe the benefits of IMDSv2 and explain how it enhances security.

IMDSv1 vs IMDSv2

Although AWS considers the existing instance metadata service (IMDSv1) to be secure, with IMDSv2, AWS adds protection for four types of vulnerabilities that could be used to gain unwanted access to Instance Metadata.

IMDSv2 offer extra protection against:

  • Open Website Application Firewalls
  • Open reverse proxies
  • SSRF vulnerabilities
  • Open layer 3 firewalls and NATs

IMDSv2 under the hood

At its core, IMDSv2 enhances Instance Metadata access by protecting every request with session authentication. To achieve this, IMDSv2 requires a PUT request to initiate a session and retrieve a secret token. Next, the secret token is used as a password to make requests to IMDSv2 for metadata and credentials. Unlike traditional passwords, you don’t need to worry about getting the token, because the software gets it for itself with the PUT request. The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates.

It becomes interesting once you know that with IMDSv2, the PUT response containing the secret token can, by default, not travel outside the instance. This is accomplished by having a default Time To Live (TTL) on the low-level IP packets containing the secret token set to “1”. Hardware and software that handle packets, including EC2 instances, subtract 1 from each packet’s TTL whenever they pass it on. If the TTL gets to 0, the packet is discarded. A packet with a TTL of “n” can therefore make n “hops” in a network before giving up, while a packet with a TTL of “1” can exist in just one. In the context of IMDSv2, we refer to hop limit of the PUT call instead of TTL. By using a default hop limit (TTL) of 1, a session token can only be used directly from the EC2 instance where that session was initiated.

Do you wonder why the hop value is überhaupt configurable and allows a value higher than 1? For example, In case you want to run a containerized workload on an instance, the hop limit needs to be raised to 2 in order to make the instance metadata available in the container.

IMDSv2 applied to: Cloud Metadata - AWS IAM Credential Abuse

First of all, the SSRF attack as mentioned in the article will no longer work using IMDSv2 because of the missing PUT call. To be more precise, the curl statement won’t be able to execute or exfiltrate credentials by injecting the metadata URL in its call. The requirement of the session In IMDSv2 protects us from these SSRF attacks.

curl "http://TDIR-WebApp-1UEARVYAI6KFP-1676273348.us-east-1.elb.amazonaws.com/demo.php?site="

Secondly, note that any “Post Compromise-Activities” as described in the article are no longer possible. This is because with IMDSv2 a session can only be used directly from the EC2 instance where the session was initiated (with the default hop limit of 1). Even if IMDSv2 credentials would be exfiltrated, as long as someone hasn’t access to the instance the IMDSv2 sessions was initiated from, those credentials are useless.


The fact that open WAFs very rarely support HTTP PUT requests, makes the requirement of a PUT request a new layer of defense. With the IMDSv2 service to require a PUT request at the beginning of a session, it prevents open WAFs from being abused to access the IMDS in the vast majority of cases.

Reverse proxies, such as Apache httpd or Squid, can be misconfigured to allow external requests that reach internal resources, but it’s still normal for these proxies to send an X-Forwarded-For HTTP header. IMDSv2 will not issue session tokens to any caller with an X-Forwarded-For header, which is effective at blocking unauthorized access due to misconfigurations like an open reverse proxy.

IMDSv2’s combination of beginning a session with a PUT request, and then requiring the secret session token in other requests, is very effective in protecting you against the vast majority of SSRF vulnerabilities.

With IMDSv2, setting the hop limit value to “1” means that requests only from the EC2 instance itself will work. If the EC2 instance has been misconfigured as an open router, layer 3 firewall, VPN, tunnel, or NAT device, the packet containing the response will be discarded on its way out of the instance, preventing transport to the attacker. The information won’t make it further than the EC2 instance itself, which means that an attacker won’t get the response back with the token, and with it the ability to access instance metadata, even if they’ve been successful at getting past all other defenses.

How to Require the use of IMDSv2

When you launch an instance, you can configure the instance to require the use of IMDSv2 by setting the Metadata version to V2 only.

From October 2022, you can also set an EC2 Amazon Machine Image (AMI) to use (IMDSv2 by default.

Enjoy and until next time!


Subscribe to our newsletter

We'll keep you updated with more interesting articles from our team.

(about once a month)