Why enabling AWS Instance Metadata Service version 2 (IMDSv2) is important ?

In this article, we will discuss about AWS Instance metadata service, why it’s a special service; how IMDSv1 is vulnerable to SSRF attack and how can we can protect / defend against such attacks ; upgrade imdsv1 to imdsv2.

Table of Content:

• What’s special about metadata service running within AWS ?
• What is IMDSv2 ?
• Why we need to enable IMDSv?
• Common attack on IMDSv1 ?
• Benefits of using IMDSv2 ?
• How to protect systems ?
• How to upgrade IMDSv1 to IMDSv2 ( for existing ec2 instances) ?

What’s special about metadata service running within AWS ?

AWS Metadata service runs on http://169.254.169.254/latest/meta-data/ and is accessible only from localhost but how ?

This 169 range is part of link-local address. In computer networking, a link-local address is a unicast network address that is valid only for communications within the subnetwork that the host is connected to.

Link-local addresses are not guaranteed to be unique beyond their network segment. Therefore, routers do not forward packets with link-local source or destination addresses.

IPv4 link-local addresses are assigned from address block 169.254.0.0/16 (169.254.0.0 through 169.254.255.255)

Assuming, we have controls in place that can detect these attacks, notify INFOSEC teams so they can act on it real quickly and that can circumvent these attacks.

What is IMDSv2 ?

IMDSv2 uses session-oriented requested. With session-oriented requests, you create a session token that defines the session duration, which can be a minimum of one second and a maximum of six hours. During the specified duration, you can use the same session token for subsequent requests. After the specified duration expires, you must create a new session token to use for future requests.

Why we need to enable IMDSv?

If enabled, we can query all metadata about instance such as type/specs/network etc. Other use case -> to reach AWS services via API. Example -> You want access S3 objects from ec2 instances. Attaching IAM role to ec2 makes more sense as credentials are short lived and you don’t need to rely on IAM user creation/manage long lived credentials. You can also enable VPC endpoint in combination and reach AWS endpoints over private IP’s as well.

Common attack on IMDSv1 : SSRF (Server Side Forgery Request)

Server-Side Request Forgery (SSRF) is a security vulnerability that occurs when an attacker can manipulate or control requests made by a server to other services or systems on the internal network. It makes unauthorized requests to internal resources i.e. retrieving sensitive data / causing unintended actions.

In the context of AWS EC2 instances with IMDSv1 enabled :- SSRF could be leveraged to make unauthorized requests to the IMDS, potentially leading to the disclosure of sensitive information, including IAM (Identity and Access Management) role credentials.

Afterwards, these credentials can be used from any location for longer period as there is no session token.

With IMDSv2 it’s not possible as you need session token before retrieving IAM credentials.

Example: Webserver (nginx/apache) running with IMDSv1 + SSRF vulnerability can allow us to make requests to arbitrary address ; we can query instance metadata endpoint and bypass it :

Example: This will check if any role is attached.

wget  http://169.254.169.254/latest/meta-data/iam/

Afterwards, you can check role and query IAM role name (if it’s associated or not):

http://169.254.169.254/latest/meta-data/iam/security-credentials/

If IAM role is associated then you need to query it directly; this will provide credentials that can be used from any location. It’s short term credentials and can valid up to 6 hours (max). Replace <role-name> with actual one.

http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>/.

Recommendations:

• We recommend enabling Guardduty so it can track and alert such incidents.
• Patch all systems attached to public facing load balancer on regular basis.

Benefits of using IMDSv2:

1. Authentication process: Attacker needs to obtain first session credentials and then use Session token to retrieve IAM credentials.

Example:

# Obtain Session Token
session_token=$(curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token)

# Use Session Token to Retrieve IAM Role Credentials
curl -H "X-aws-ec2-metadata-token: $session_token" http://169.254.169.254/latest/meta-data/iam/security-credentials/Your-Role-Name

2. Credentials lifespan: Short term role credentials can restrict attacker to limit the window of opportunity at minimum level.

3. Theft token: Even in worst case, if your role credentials are compromised it can’t be effectively used from outside due to lifespan/short-lived.

4. Conditional Policies: We can apply conditional policies such as MFA or IP based restrictions.

5. Token Binding: IMDSv2 supports token binding, which associates the session token with a specific TCP connection. This helps prevent attackers from using intercepted tokens on different connections.

How to protect ec2 instance ?

It’s imperative that system’s exposed to internet should have below checks in place:

• Regular Patch Management.
• Strict Firewall Ingress/Egress rules → Security groups/NACL’s
• Enable IMDSv2 (instead of imdsv1).
• IAM role attachment with principle of least privilege.
• Intrusion Detection/Prevention System.
• Monitoring/Logging all OS and application logs.
• Use Hardened AMI’s.
• Regular security audit on these instances.
• Enable endpoint protection services
• Application Security.
• Continuous training/awareness.
• Monitor logs/metrics and anomaly detection.
• Incident detection and response team to quickly identify/mitigate any compromise.
• Traffic Encryption (end to end).

Above points are just few of the action items we need to keep in mind. It’s just a 10,000 foot view and each topic is very important to achieve maximum security.

How to upgrade IMDSv1 to IMDSv2 ( for existing ec2 instances) ?

To query the instance metadata options for an existing instance using the AWS CLI

Use the describe-instances CLI command.

aws ec2 describe-instances \
    --instance-id i-xxxxxxxxxx \
    --query 'Reservations[].Instances[].MetadataOptions'

To require the use of IMDSv2 on an existing instance

Use the modify-instance-metadata-options CLI command and set the http-tokens parameter to required. When you specify a value for http-tokens, you must also set http-endpoint to enabled.

aws ec2 modify-instance-metadata-options \
    --instance-id i-xxxxxxxxxxx \
    --http-tokens required \
    --http-endpoint enabled

You might have to monitor application after such changes.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇