Shift Left Security: Why You Should Use AWS IMDSv2 Explained in Detail
Gert Leenders@glnds
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 http://169.254.169.254/latest/dynamic/instance-identity/document 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=http://169.254.169.254/latest/dynamic/instance-identity/document"
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.
Summary
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!