By Charles Joseph | Cybersecurity Researcher

 Published on August 14th, 2023

This post was updated on November 25th, 2023

Did you know that, by default, an AWS EC2 instance has an internal IP address that exposes sensitive details about itself?

That’s right, anyone with terminal access to your instance that’s able to use a basic tool like curl can access the endpoint http://169.254.169.254/latest/meta-data/ to retrieve this information.

Thank you for signing up, we'll be in contact soon.

Stay One Step Ahead of Cyber Threats

Want to Be the Smartest Guy in the Room? Get the Latest Cybersecurity News and Insights.

Subscribe

We respect your privacy and you can unsubscribe anytime.

It’s a surprising feature, and you likely don’t want every command-line user to have this access.

In this article, we’ll discuss what IMDS is, what information you can get from the endpoint, and, most importantly, how to disable it.

What Is the AWS Instance Metadata Service (IMDS)?

Amazon Web Services (AWS) provides the Instance Metadata Service (IMDS) to allow EC2 instances to query metadata about the instance without requiring special permissions or credentials.

The metadata includes information such as the instance type, security groups, IP addresses, and more.

What’s the Purpose of the IMDS?

The purpose of the Instance Metadata Service (IMDS) in AWS is to offer metadata about an EC2 instance to applications running on that instance. This allows for dynamic configuration and automation of tasks without manual intervention.

Furthermore, IMDS provides temporary security credentials, enhancing security by eliminating the need for long-term, embedded AWS access keys.

It enables applications to adapt their behavior based on their operational environment, such as distinguishing between development and production settings.

Additionally, by providing details like IP address, instance type, and AMI ID, IMDS assists in logging, monitoring, and making applications infrastructure-aware.

Lastly, with its latest version, IMDSv2, the service has enhanced security measures to prevent potential vulnerabilities, such as Server-Side Request Forgery attacks.

Is the IMDS Insecure?

The Instance Metadata Service (IMDS) isn’t inherently insecure, but its use can introduce vulnerabilities if not configured or accessed properly.

Here are some security concerns and mitigations:

Server-Side Request Forgery (SSRF): This is one of the most commonly discussed vulnerabilities with IMDS. An SSRF attack allows an attacker to make requests to internal resources, like IMDS, from a vulnerable server. If an attacker can exploit an SSRF vulnerability in an application running on an EC2 instance, they might be able to retrieve instance metadata, including sensitive IAM role credentials.

Mitigation: AWS introduced IMDSv2 to address this concern. IMDSv2 requires a session-based approach, where a token is generated before any metadata is retrieved. This makes exploiting IMDS via SSRF significantly more difficult.

Lack of Granularity in IAM Roles: If you attach a broad IAM role to an EC2 instance, any process or application on that instance can potentially use the role to fetch credentials from IMDS and access AWS resources.

Mitigation: Assign granular permissions to IAM roles, ensuring that each instance or application has only the permissions it absolutely needs.

Unrestricted Access to IMDS: By default, any code or application running on an EC2 instance can query IMDS.

Mitigation: Implement OS-level restrictions, such as iptables rules, to limit which processes or users can connect to the IMDS endpoint.

Exposure of Sensitive Information: IMDS contains details about the instance, which can be valuable for attackers during information gathering.

Mitigation: Again, OS-level controls and limiting unnecessary IAM permissions can help minimize this risk.

No Built-in Auditing: By default, IMDS requests aren’t logged, so it’s challenging to determine if it’s being accessed maliciously.

Mitigation: Introduce monitoring and alerting mechanisms and consider third-party tools or solutions that help monitor and analyze IMDS access patterns.

While IMDS provides valuable functionality, it also introduces a potential attack surface. However, with proper configurations, security measures, and the use of IMDSv2, the risks can be substantially mitigated.

How Many Versions IMDS Are There?

There are two versions of the IMDS: Version 1 (IMDSv1) and Version 2 (IMDSv2).

Here are the key differences between the two:

Request Method:

• IMDSv1: It’s a request/response model. You make a simple HTTP GET request to the IMDS endpoint (http://169.254.169.254/latest/meta-data/) to retrieve the desired metadata.
• IMDSv2: It uses a session-oriented model. This means that before you can make a request to retrieve metadata, you must first create a session by obtaining a token. This is done by making a PUT request to http://169.254.169.254/latest/api/token.

Security:

• IMDSv1: It’s susceptible to certain types of vulnerabilities, particularly Server-Side Request Forgery (SSRF) attacks. In these attacks, a malicious actor can trick an application into fetching metadata from the IMDS endpoint, potentially gaining sensitive information or credentials.
• IMDSv2: It introduces a higher level of security by requiring a session token for metadata queries. This token-based approach makes it more difficult for potential SSRF attacks since the attacker would need to obtain a valid token before querying metadata.

Session Token Lifetime:

• IMDSv2: When you obtain a session token by making a PUT request, the token has a time-to-live (TTL). By default, it’s 6 hours, but you can specify a different TTL between 1 second to 6 hours.

Usage:

• IMDSv1: Simply make a GET request to the desired metadata path.
• IMDSv2: First, obtain a token by making a PUT request. Then, use that token in the headers of your GET request to fetch metadata.

Backward Compatibility:

• AWS has ensured that IMDSv2 is backward compatible with IMDSv1. This means you can choose to implement the newer, more secure version without breaking existing applications using IMDSv1.

Endpoint:

• Both versions use the same base endpoint (http://169.254.169.254/), but the methods and paths you’d use with that endpoint differ based on the version.

Given the improved security features of IMDSv2, AWS recommends using it over IMDSv1, especially for applications that might be exposed to SSRF vulnerabilities.

Example Using CURL to Get Data

charles@server:/$ curl http://169.254.169.254/latest/meta-data/

This will return:

ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
system

Let’s unpack these elements to gain a deeper insight into their meaning.

For any of the keys appearing above, you could issue a request — e.g., 169.254.169.254/latest/meta-data/<key> — to get more information. Here’s an example:

charles@server:/$ curl http://169.254.169.254/latest/meta-data/ami-id

Definitions of IMDS Keys

Can You Disable the IMDS Service?

Yes, and the command to do so is:

aws ec2 modify-instance-metadata-options –instance-id <instance-id> –http-endpoint disabled

Could Anyone with Access to the Metadata Endpoint Get Access to the Attached Role’s Access Key ID and Secret Access Key?

Yes, anyone with access to the metadata endpoint on an EC2 instance can retrieve the temporary IAM role credentials associated with that instance, which include:

• Access Key ID
• Secret Access Key
• Session Token

However, these credentials are temporary and have a limited lifespan, often hours. After they expire, they’re no longer valid.

That said, even temporary access can be harmful if the IAM role has significant permissions. Here’s why:

1. It’s essential to limit the permissions of IAM roles associated with EC2 instances following the principle of least privilege.
2. Use IMDSv2, which requires a token to be obtained before accessing the metadata, making unauthorized access more difficult.
3. Consider adding OS-level restrictions to limit access to the metadata endpoint to only necessary processes or users.

Also, it’s worth noting that even though an entity might retrieve these temporary credentials, they can only perform actions that the IAM role’s policy allows.

So, while they can potentially get the “keys,” what doors they can open depends on the permissions granted to that IAM role.

Still, it’s essential to treat this information as sensitive and secure it accordingly.

How to Enable OS-Level Restrictions to Limit Access

OS-level restrictions to limit access to the metadata endpoint typically involve network-level controls. Here’s a breakdown of how you can achieve these restrictions on a Linux-based EC2 instance:

Using iptables (Netfilter)

iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall. Here’s an example to block all access to the metadata IP, only allowing a specific user (e.g., myuser):

   # Block all access to 169.254.169.254
   iptables -A OUTPUT -d 169.254.169.254 -j DROP

   # Allow only myuser to access 169.254.169.254
   iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner myuser -j ACCEPT

Using firewalld

firewalld provides a dynamically managed firewall with support for network/firewall zones to define the trust level of network connections or interfaces. Here’s an example with firewalld:

   # Block all access to 169.254.169.254
   firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 169.254.169.254 -j DROP

   # You'd need custom direct rules or a custom service definition to allow specific users or services with firewalld.

Using ufw (Uncomplicated Firewall)

ufw is a more user-friendly interface for managing iptables. Example with ufw:

   # Block all access to 169.254.169.254
   ufw deny out to 169.254.169.254

   # ufw doesn't natively support user-based rules like iptables does. You'd need to revert to iptables for that granularity.

A few other considerations:

• Ensure that any changes made to the firewall are tested thoroughly. Incorrectly configured firewall rules can block essential services or accidentally expose services to the public.
• Make sure to persist your firewall rules. For instance, iptables rules will be lost after a system reboot unless saved. Tools like iptables-persistent on Debian-based systems or iptables-services on Red Hat-based systems can help with this.
• Always have a fallback plan. If you’re testing remotely, you could be locked out if the rules are not set up correctly. Always ensure you have another way to access the instance (e.g., AWS Systems Manager Session Manager).

While OS-level restrictions enhance security, they must be implemented carefully to avoid unintended disruptions.

Why Does IMDS Expose the Secret Key of an EC2 Role?

If someone has access to the terminal of an EC2 instance (i.e., they can SSH into it or access it through other means), they’re already in a position of significant privilege. The metadata service (IMDS) is simply a mechanism to provide applications on that instance with the necessary credentials to interact with AWS services without needing to store those credentials on the instance.

The fundamental idea behind EC2 instance profiles and roles is this:

1. Avoid Static Credentials: Without roles, the alternative would be to somehow get AWS credentials (Access Key ID and Secret Access Key) onto the instance, which introduces challenges and risks. How do you securely transport them there? How do you rotate them? What if the instance is compromised and those static credentials are exfiltrated?
2. Dynamic and Temporary: The credentials provided via the instance metadata service are temporary. They will expire after a short period, and a new set of credentials will be generated. This is managed seamlessly in the background.
3. Implicit Trust: As you noted, if someone has terminal access to your EC2 instance, they’re already in a position where they can potentially do a lot of harm. The instance metadata service assumes that anyone with access to the instance can be trusted with the role’s credentials. This is why it’s so essential to restrict and monitor who can access your instances.
4. Secure by Default: While the IMDS provides these credentials readily, AWS has taken steps to enhance its security, like introducing IMDSv2, which makes it harder for unintended parties (e.g., through SSRF attacks) to retrieve these credentials.

However, it’s important to remember the principle of least privilege. The IAM role associated with an EC2 instance should only have the permissions necessary for the tasks that the instance needs to perform.

If an attacker gains terminal access to an instance and retrieves the IAM role’s temporary credentials, their actions will still be limited to the permissions of that IAM role.