TotalCloud Insights: Unmasking AWS Instance Metadata Service v1 (IMDSv1)-The Hidden Flaw in AWS Security

Introduction

Imagine a breach that cost a company over $150 million in fines, remediation, and lost trust. In 2019, this was an all-too-real situation for one business when vulnerabilities in AWS Instance Metadata Service v1 (IMDSv1) were exploited. A single Server-Side Request Forgery (SSRF) attack, leveraging this hidden flaw, led to the exposure of sensitive data for over 100 million customers. The incident underscores a critical vulnerability in cloud security that many organizations still overlook: the inherent risk of relying on IMDSv1.

Despite the availability of IMDSv2, which addresses the security flaws that were exploited in this attack, countless organizations continue to rely on the outdated IMDSv1, leaving themselves exposed to similar attacks. This blog explores the ongoing dangers of IMDSv1, its potential for massive financial impact, and why transitioning to IMDSv2 is crucial for securing modern cloud infrastructures.

Understanding the Instance Metadata Service (IMDS)

Imagine your cloud server as Detective Sam, who relies on his assistant, Metadata Mike, to recall details. Similarly, your cloud server uses the Instance Metadata Service (IMDS) to get vital information instantly. IMDS provides details about each Amazon Elastic Compute Cloud (Amazon EC2) instance, like AMI ID and security groups, accessible via a link-local address.

From a security standpoint, if an EC2 instance has an AWS Identity and Access Management (IAM) role, its IAM credentials are stored in the instance metadata. Attackers will often target this to access the control plane.

IMDSv1 – a request/response method

IMDSv1 is the original AWS service for accessing instance metadata, allowing instances to retrieve information without requiring explicit authentication or session management.

However, this convenience comes at the cost of potential security vulnerabilities, notably susceptibility to Server-Side Request Forgery (SSRF) attacks. These vulnerabilities can be exploited to gain unauthorized access to sensitive instance data or execute actions on behalf of the instance, posing significant security risks in sensitive environments.

What is Server-Side Request Forgery (SSRF)?

SSRF (Server-Side Request Forgery) is a vulnerability where attackers manipulate the server into making unintended requests by exploiting its ability to process user-provided URLs without proper validation. An adversary proficient in AWS exploitation will target SSRF vulnerabilities in web applications running on EC2 instances. Upon discovery, they exploit these vulnerabilities to access instance metadata and pilfer IAM credentials.

Potential Attack Path due to the Exploitation of IMDSv1

The attack path of an exploitation of IMDSv1 could look like the following: 

Reconnaissance: Attackers identify target EC2 instances with accessible IMDS, probing for vulnerabilities or open ports.

Instance Access: Exploiting vulnerabilities or weak credentials, attackers gain entry to the targeted EC2 instance.

Locating IMDS: Within the compromised instance, attackers locate and access the IMDS endpoint at http://169.254.169.254

Unauthorized IMDS Access: Attackers send HTTP requests to the IMDS endpoint, attempting to extract sensitive metadata such as security credentials and instance details.

Metadata Extraction: Successful extraction grants attackers access to temporary security credentials and other sensitive metadata.

Leveraging Extracted Data: With extracted credentials, attackers impersonate the instance to execute unauthorized AWS API calls and access additional AWS resources.

Unauthorized Actions: Using compromised credentials, attackers conduct unauthorized activities like launching resources, modifying security configurations, or accessing sensitive data stored in S3 buckets.

Expanding Attack Surface: Attackers exploit initial access to move laterally within the AWS environment, compromising additional instances and resources.

How IMDSv2 Improves on IMDSv1: Key Differences Explained

For ten years, from 2009 to 2019, Amazon EC2 exclusively used IMDSv1, a straightforward API for accessing instance metadata. To obtain credentials, any service running on an EC2 instance simply needed to send a basic HTTP GET request to: http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>.

Here, <ROLE_NAME> represents the IAM role assigned to the EC2 instance, which could be retrieved by another HTTP GET request to: http://169.254.169.254/latest/meta-data/iam/security-credentials/.

IMDSv2 – a Session-Oriented Method

IMDSv2 represents a substantial advancement in security over IMDSv1. Unlike its predecessor, IMDSv2 mandates explicit authentication through session tokens issued by the AWS EC2 Instance Metadata Service (IMDS). Before accessing metadata, instances must authenticate themselves, significantly mitigating the risk of SSRF attacks and unauthorized data access attempts.

How IMDSv2 Enhances Security

Session Initiation via PUT Requests

IMDSv2 improves security by using PUT requests instead of the less secure GET requests used in IMDSv1. This adds an extra layer of protection as most web application firewalls and reverse proxies do not support PUT requests. Additionally, IMDSv2 requires sessions to start with a PUT request to generate a token. Without this token, access to instance metadata is denied.

Blocking the X-Forwarded-For Header

IMDSv2 rejects any requests that include the X-Forwarded-For header to block potentially harmful requests from improperly configured open reverse proxies, enhancing security.

Clever IP Packet TTL Reduction Technique

IMDSv2 sets the IP packet’s TTL value to 1 for token responses. This ensures that metadata packets are returned to the instance’s caller application but are dropped before they can leave the EC2 instance boundary, preventing external attackers from accessing the credentials.

TOKEN=$(curl -X PUT -H “X-aws-ec2-metadata-token-ttl-seconds: 21600” -sS http://169.254.169.254/latest/api/token)

curl -H “X-aws-ec2-metadata-token: $TOKEN” -sS http://169.254.169.254/latest/meta-data/

IMDSv2 is a Significant Improvement, but Not Flawless

While IMDSv2 mitigates some attack vectors like simple SSRF, the responsibility of securing the environment remains crucial through proper configurations. Misconfigured applications, permissions, or security groups may still expose metadata to external threats. Even with IMDSv2, an open instance without proper network security controls (like firewalls and security groups) could allow malicious entities to interact with the metadata service. Employing guardrail mechanisms, such as configuring data perimeters to restrict resource access to trusted networks only, can significantly mitigate the risk of credential exfiltration. However, vulnerabilities can persist, as highlighted by a real-life scenario where an IMDSv2-enforced EC2 instance remained exploitable due to specific software vulnerabilities.

Should you Disable IMDS?

If your EC2 application doesn’t need instance metadata, disabling IMDS can reduce the attack surface. However, many AWS tools and services, like CloudWatch and SSM, rely on IMDS for credentials and information. Ensure no service disruptions will occur before disabling it. All Amazon Linux 2 packages now support IMDSv2, making the transition safer.

Best Practices for Securing IMDS

There are several best practices to secure IMDS:

• Limit IMDS Access – Disable IMDS for your EC2 instances where it is not needed to reduce the attack surface and prevent unauthorized access.
• Restrict IMDS Access – Limit access to the metadata endpoint to specific users.
• IAM Best Practices – Assign IAM roles with the minimum necessary permissions to EC2 instances. Avoid unnecessary roles and follow the principle of least privilege. Do not assign roles to instances that do not require them to further limit access to sensitive metadata.

Mitigation and Prevention Strategies with Qualys TotalCloud

Qualys TotalCloud, a CNAPP (Cloud Native Application Protection Platform), which rigorously adheres to cloud security best practices, helps you mitigate the AWS EC2 IMDSv1 vulnerability. TotalCloud continuously monitors EC2 instances, focusing on compliance with the control CID 322: Ensure that EC2 Metadata Service only allows IMDSv2, which mandates the exclusive use of IMDSv2 for the EC2 Metadata Service.

Qualys TotalCloud automates the detection of vulnerable instances by scanning for outdated IMDSv1 configurations and swiftly suggests remediation actions like disabling IMDSv1 and upgrading to IMDSv2 across affected EC2 instances. This proactive approach ensures that organizations maintain a secure cloud environment, effectively mitigating risks associated with IMDSv1.

Secure Instance Metadata Across CSPs: Azure, GCP & OCI

AWS, an early IMDSv1 adapter, enhanced security with IMDSv2. However, GCP, Azure, and OCI each implement unique security measures, including access controls and encryption, to protect instance metadata from unauthorized access, enhancing overall cloud security amid evolving threats. The following figure is a brief summary of their features.

Conclusion

The security risks associated with AWS Instance Metadata Service Version 1 (IMDSv1), as highlighted by incidents like the breach referred to in the introduction, underscore the necessity for enhanced cloud protection strategies. Transitioning to IMDSv2 is vital, but achieving comprehensive security requires more robust solutions.

Qualys TotalCloud addresses this need by automating the detection and remediation of vulnerable configurations, ensuring that EC2 instances are protected against evolving threats. With its proactive monitoring capabilities, Qualys TotalCloud enables organizations to maintain a secure cloud environment across AWS and other major platforms, effectively reducing risk and enhancing overall security posture.

Sign up for a trial to experience first-hand how Qualys TotalCloud can protect against risks like the IMDSv1 vulnerability.

Contributors

• Rahul Pareek, Security QA Engineer, Cloud, Qualys