Severity Matters: IMDSv1 > IMDSv2 (Instance Metadata Service)

Overlooking medium and low-severity cloud security misconfigurations can have consequences.

 

In Part 1 of our “Severity Matters” series, we covered how misconfigured access policies could be exploited to exfiltrate sensitive metadata from an unencrypted AWS Glue Data Catalog. The key takeaway is that it’s easy for medium and low severity misconfigurations to get lost in the noise of CNAPP and CSPM alerts, but they can actually serve as stepping stones to higher severity attacks.

 

In Part 2 of this series, we break down why the switch from IMDSv1 to v2 presents an opportunity to better secure your AWS environment.

---

IMDS v2 (Instance Metadata Service)

Overview

AWS IMDS provides valuable information about instances and can be used for legitimate purposes. However, an attacker can exploit vulnerabilities to assume instance permissions – and eventually perform actions on behalf of the instance.

Since November 2023, AWS Console Quick Start launches use IMDSv2 only. By mid-2024, newly released Amazon EC2 instance types will use only version 2 of the EC2 Instance Metadata Service (IMDSv2). While AWS moves to make IMDSv2 the default choice for AWS Management Console Quick Start and other launch pathways, all the instances that are still running IMDSv1 remain vulnerable.

In IMDSv1, accessing the metadata URI is achieved through a direct GET request. IMDSv2 implements session-oriented requests as an added layer of defense against unauthorized access to metadata. To initiate a session in IMDSv2, the initial step involves creating a session token via a PUT request to the session URI. The laxer authentication mechanism of IMDSv1 leaves it more open to exploits than v2, and so addressing related misconfiguration alerts can help prevent security breaches.

Let’s chart the attackers’ path to see how something as minor as an open port can lead to an attack.

---

Sample Attack Path

Step 1: Reconnaissance
The attacker begins by identifying a target AWS EC2 instance where they suspect IMDS might be accessible. This could involve scanning for open ports, identifying public-facing instances, or exploiting other vulnerabilities to gain a foothold within the AWS environment.

 

Step 2: Instance Access
The attacker gains access to the targeted EC2 instance. This access could be achieved through various means, including vulnerabilities in applications running on the instance, exploiting weak credentials, or other entry points.

 

Step 3: Locating IMDS
Once inside the EC2 instance, the attacker locates the IMDS endpoint. This is typically accessible at http://169.254.169.254 within the instance’s network configuration.

 

Step 4: Unauthorized IMDS Access
The attacker sends HTTP requests to the IMDS endpoint, attempting to extract sensitive information. IMDS allows the instance to retrieve metadata about itself, such as security credentials, instance identity, and user data.

 

Step 5: Metadata Extraction
The attacker successfully extracts sensitive information from IMDS, which may include temporary security credentials, instance profile data, and other metadata.

 

Step 6: Leveraging Extracted Data
With access to the extracted data, the attacker can now impersonate the instance and perform actions on behalf of the instance’s associated AWS role. This can include making AWS API calls, accessing other AWS services, and potentially escalating their privileges.

 

Step 7: Unauthorized Actions
Using the extracted credentials, the attacker can perform unauthorized actions within the AWS environment. This could include launching new resources, modifying security groups, or accessing sensitive data stored in S3 buckets.

 

Step 8: Expanding Attack Surface
The attacker may leverage the initial access gained through IMDS to move laterally within the AWS environment, attempting to compromise additional instances and resources

---

How to stay secure

If you’re still using IMDSv1, unauthorized access to your AWS EC2 instance can be a launchpad for high severity attacks including privilege escalation, lateral movement in your AWS environment, and access to sensitive data stored in S3 buckets.

The most effective way to secure your environment is to switch to IMDSv2. Tamnoon has authored a comprehensive guide to switching from v1 to v2 of AWS IMDS using our managed cloud security solution – you can find more details in our playbook.

---

Further Reading

• The potential risks of an unencrypted AWS Glue Catalog
• Overly permissive SNS policies can have consequences – identify low-severity alerts amidst a sea of noise
• From prioritization to prevention: Tamnoon’s integration with AWS Security Hub