The Next Step in the IMDSv1 Redemption Journey 

Over the past few months, I’ve become somewhat of an IMDS-geek. 

Understanding the importance of IMDSv2 for the security of EC2 instances and their credentials, I invested some time to learn about it. My colleague Liv Matan and I subsequently published a detailed IMDS blog post, delivered an IMDS webinar – and presented a review of IMDS security for EC2 instances and the equivalent Azure and GCP components at this year’s fwd:cloudsec conference. 

Enforcing IMDSv2 is a significant security posture configuration that anyone using EC2 instances will want to be aware of. One of my conclusions from my deepdive was that AWS is extremely committed to supporting its customers in responsibly securing their EC2 instances. 

This post is about another recent indication of that AWS commitment. 

Background 

First things first: if you’re not familiar with the different versions of the IMDS API and why knowing about them is important to securing your EC2 instances, I highly recommend that you read our blog post on the topic. 

The post discusses the role of IMDS in storing and serving session credentials for applications running on EC2 instances, and the different versions (v1 and v2) of its API. It also discusses why, to improve the security posture of EC2 instances and the cloud environment overall, it is significant to enforce usage of IMDSv2 (in other words, disable IMDSv1). This is because the combination of IMDSv1 enabled and security faults such as certain kinds of vulnerable software deployment may be leveraged by a malicious actor to establish a beachhead to an account. 

In existing environments, enforcement is usually easier said than done since doing it responsibly means making sure no workloads require use of IMDSv1. You also have to modify any such processes to use IMDSv2 instead. Doing so at scale is not a simple task. 

One of the things that became clear to us is that Amazon has made a considerable effort to assist in the shift to IMDSv2 by providing customers with a wide variety of tools. Some of these tools include a relevant scan in AWS Config to detect instances with IMDSv1 enabled, a CloudWatch metric to pick up on calls made to IMDSv1 and a field in CloudTrail events for calls made using credentials stored in IMDS to indicate with which IMDS API version they were retrieved (making it possible to detect retrieval by IMDSv1). 

AWS has other interesting, related controls available such as the ability to apply a Service Control Policy to prevent the creation of new EC2 instances with IMDSv1 enabled – and to prevent its enablement in instances in which it is disabled. Also, Amazon released two new condition keys to support restricting EC2 session credentials used via VPC Endpoints. We wrote a blog post on the topic and also released an open source Terraform lab to help you learn how to use the two new AWS condition keys.

New Tool on the Block 

A few weeks ago, Amazon made yet another interesting step that shows its commitment to responsible enforcement of IMDSv2 by releasing an open source library called aws-imds-packet-analyzer. The new library can be installed on an EC2 instance; it detects calls made to IMDS, logs with which API version they were made and at what time and, most importantly, indicates which process made the call and the parent processes for that process (that is, which process triggered it, and which process triggered the process that triggered it, etc.). 

The library can be a significant instrument for monitoring the activity done on an existing EC2 instance so you can responsibly retire any corresponding use of IMDSv1. This is because the library will not just tell you that calls to IMDS happened but specifically where to look to find the code that made them so you can replace the v1 usage. 

Let Us Ease You into Using It 

Since we’d like as many people as possible to give this new library a try, we have created a new open source lab in Terraform for this purpose. The lab deploys an environment and allows you – using AWS’s EC2 instance connect service – to connect to an EC2 instance within and, using a provided script, install the library on it. You can then make a simple call to IMDS (or even have additional software run on it to make multiple calls over a period of time) and view how these calls are reflected in the log. 

For more information on how to use the lab and what it does, feel free to read its README.md in the repository - and, of course, we warmly invite you to try it out. 

Notes

First, note that we have created this lab strictly as a proof-of-concept to help you easily deploy and test aws-imds-packet-analyzer. It is intended for experimentation and learning purposes only. 

IN NO WAY IS THIS LIBRARY INTENDED TO BE USED IN PRODUCTION. 

We invite you, of course, to draw inspiration from it to test your own solution. 

Second, since our goal was for experimentation and learning only, we have used a simple architecture that obviously would not be appropriate for all use cases. For example, in our lab, the EC2 instance we use has public access to the Internet (to make the process of installing the library and its dependencies easier). For real life use, you could, for example, design an architecture for remote deployment on an instance in a private subnet by hosting the installation files on an S3 bucket. 

Finally, if you plan on installing the packet analyzer on any EC2 instance: as when using any software, you will want to thoroughly test that using the packet analyzer does not interfere with business functionality.

Conclusion 

We hope you find the aws-imds-packet-analyzer useful, and that our open source lab helps you get to know it better. If you have questions on this topic, feel free to reach out to me at [email protected].