AWS Instance Metadata Service: A Quick Refresher

  • Network: Public/Private IPs, Subnet, Security Groups, etc.
  • User-data: Custom bootstrap scripts which execute at instance start-up
  • So many more available here!

Querying the IMDS

IMDS is exposed via a link-local IP address, 169.254.169.254, to the instance and behaves like a REST interface accepting requests and generating responses. Now mind you, these requests never leave the network — i.e., these requests never go through the typical flow of going outbound from your security groups, NACLs, or the Internet Gateway. Instead, they’re resolved by the AWS hypervisor (upon which your instance is hosted) which returns information requested by your specific URL.

Output via IMDSv1 Call
Retrieving Instance ID via IMDSv1
IMDS — Accessing Security Credentials

“…the temporary security credentials associated with the role”

You can go so far as to retrieve credentials for a role associated with an instance. If it were a highly privileged role assigned to that instance, re-use of the role could lead to devastating outcomes!

Retrieving the Instance’s Security Credentials via IMDSv1

Something’s Clearly Wrong Here…

There’s no form of authentication, verification, or accountability as to who’s making these requests. We’ve seen compromises in the past where EC2 instances were prone to SSRF attacks and the actors were able to query the metadata service from vulnerable applications. Practically leaving credentials open for anyone to steal.

Say Hello to IMDSv2

IMDSv2 offers protection against SSRF and three other issues with its predecessor. It does so by enforcing session authentications such that the user has to first acquire a token and then pass it in subsequent requests to retrieve the desired data.

Retrieving the Authentication Token via IMDSv2
Retrieving Instance ID via IMDSv2

Migrating to IMDSv2

Luckily, migration isn’t a pain. Both versions of the metadata service are available to instances and enabled by default. It’s up to the tenant to disable either of the two or both the versions on their instances.

Disabling IMDSv1

You can easily disable IMDSv1 at the launch of your instance. While launching it, take a look at the Advanced Details section and look for the Metadata Version parameter. By selecting V2 Only you can ensure your instance only allows the upgraded version of the metadata service.

Disabling IMDSv1

Response Hop Limits

By default, the PUT request to retrieve the token can only go through a single hop to reach the metadata service. Any increment and the request gets rejected. However, this is concerning for containerized applications which have to communicate to IMDS via the host itself. In such cases, the response hop limit can be increased using the same modify-instance-metadata-options call:

What Next?

Disable or upgrade the service? Put up controls? Secure yourself! But hey, due diligence comes first. Check to see if any legitimate application is dependent on the older version of the IMDS. If so, they first need to be made compatible with the IMDSv2. Once compatible, it’s time to get to work 😉

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store