How to remediate – Amazon Web Services EC2 Instance Metadata Enumeration (Unix)

1. Introduction

Amazon Web Services EC2 Instance Metadata Enumeration (Unix) allows retrieval of sensitive information about an AWS EC2 instance. This can expose details like IAM roles, network configuration and other data that could be used to compromise the system. Affected systems are typically Amazon Machine Images running on EC2 instances. A successful exploit could lead to confidentiality breaches through access to metadata.

2. Technical Explanation

The vulnerability occurs because the AWS EC2 instance metadata API is accessible by default from within the instance itself. An attacker who gains access to an EC2 instance can query this API to retrieve sensitive information without needing additional credentials. There isn’t a specific CVE associated with this general enumeration capability, but it’s a common configuration issue. For example, an attacker could use curl to request metadata from the local endpoint. Affected systems include Linux and Unix-based EC2 instances where the instance profile is enabled.

• Root cause: The EC2 instance metadata API is accessible by default within the instance.
• Exploit mechanism: An attacker uses curl or similar tools to query the local metadata endpoint (http://169.254.169.254/latest/meta-data/).
• Scope: Amazon EC2 instances running Linux and Unix operating systems with enabled instance profiles.

3. Detection and Assessment

You can confirm vulnerability by attempting to retrieve metadata from the local endpoint. A thorough method involves checking for exposed IAM roles and network information.

• Quick checks: Run curl http://169.254.169.254/latest/meta-data/. If you receive a JSON response, the API is accessible.
• Scanning: Nessus vulnerability ID 13870 can detect this issue. This should be used as an example only.
• Logs and evidence: Examine system logs for outbound connections to http://169.254.169.254, which may indicate metadata access attempts.

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

4. Solution / Remediation Steps

The following steps detail how to mitigate the risk of EC2 instance metadata enumeration. These steps are designed to be small, testable and safe to roll back.

4.1 Preparation

• No services need to be stopped for this remediation.
• Rollback: Restore from the snapshot if issues occur. Change window approval is recommended.

4.2 Implementation

1. Step 1: Configure a firewall rule (e.g., using iptables or security groups) to restrict outbound access to http://169.254.169.254 from the instance.
2. Step 2: If possible, use IAM roles with least privilege instead of embedding credentials directly in the instance.

4.3 Config or Code Example

Before

# No firewall rule blocking access to metadata endpoint

After

sudo iptables -A OUTPUT -d 169.254.169.254 -j DROP
sudo netfilter-persistent save #If using netfilter-persistent

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – grant only the minimum necessary permissions to IAM roles and users.
• Practice 2: Network segmentation – restrict network access to limit the potential impact of compromised instances.

4.5 Automation (Optional)

The following script shows how to block metadata endpoint using Ansible.

---
- hosts: all
  tasks:
    - name: Block metadata endpoint with iptables
      iptables:
        chain: OUTPUT
        destination: 169.254.169.254
        jump: DROP
        state: present
    - name: Save iptables rules (Debian/Ubuntu)
      command: netfilter-persistent save
      when: ansible_os_family == "Debian"

5. Verification / Validation

• Post-fix check: Run curl http://169.254.169.254/latest/meta-data/. You should receive a connection timeout or error message, indicating access is blocked.
• Re-test: Re-run the initial detection command (curl http://169.254.169.254/latest/meta-data/) to confirm that metadata retrieval fails.
• Monitoring: Monitor system logs for any failed attempts to access http://169.254.169.254, which may indicate ongoing exploitation attempts.

curl http://169.254.169.254/latest/meta-data/  # Expected output: Connection refused or timeout

6. Preventive Measures and Monitoring

Update security baselines to include restrictions on metadata access. Implement checks in CI pipelines to prevent similar misconfigurations.

• Baselines: Update your security baseline (e.g., CIS benchmark) to require firewall rules blocking outbound access to http://169.254.169.254.
• Pipelines: Add checks in CI/CD pipelines to ensure that new EC2 instances are configured with appropriate firewall rules and IAM roles.
• Asset and patch process: Review security configurations during regular asset assessments or vulnerability scans.

7. Risks, Side Effects, and Roll Back

Blocking access to the metadata endpoint may impact applications that legitimately rely on it (rare). Roll back by removing the firewall rule.

• Risk or side effect 1: Blocking the metadata endpoint could break functionality if an application requires it.
• Risk or side effect 2: Incorrectly configured firewall rules can disrupt network connectivity.
• Roll back: Remove the iptables rule using sudo iptables -D OUTPUT -d 169.254.169.254 -j DROP and save the changes with netfilter-persistent save (if applicable).

8. References and Resources

Links to official documentation related to this vulnerability.

• Vendor advisory or bulletin: https://docs.aws.amazon.com/ec2/index.html
• NVD or CVE entry: Not applicable for this general enumeration issue.
• Product or platform documentation relevant to the fix: https://docs.aws.amazon.com/ec2/latest/userguide/instance-metadata-service.html