A Comprehensive Guide on Locking Down AWS EC2 Metadata to Defend Against SSRF Attacks

EC2 instance metadata access allows easy querying of useful management data about your virtual servers. But leaving it unrestricted also enables sensitive data leakage and IAM credential theft by attackers.

Content Navigation show

In this detailed guide, you’ll learn how metadata works under the covers, why it poses security risks, and how to lock it down using access control tools provided by AWS. We’ll cover techniques like fully disabling HTTP access, requiring IMDSv2, and applying least-privilege IAM policies so you can tailor a layered defense based on your specific infrastructure needs.

How EC2 Metadata Service Functions

The EC2 metadata service runs an HTTP server on all EC2 instances on the link-local address 169.254.169.254. This server hosts JSON documents that contain management data related to the given instance.

There are several categories of metadata available:

Hostname – The private DNS hostname assigned to the instance. Useful for identifying the server from within internal VPC connections.

Public Keys – The SSH public key fingerprints and associated key names, allowing SSH authentication management.

Security Groups – Lists all security groups the instance belongs to for managing networking access controls.

IAM Roles – Any IAM roles attached to the EC2 instance. When present, includes temporary security credentials allowing access to other AWS resources allowed by the role.

User Data – Bootstrap scripts or custom parameters supplied during instance launch. Used to alter configurations at boot time via cloud-init directives.

For example, querying the iam/security-credentials/role-name endpoint would returnAccessKeyID and SecretAccessKey credentials for the given IAM role:

{
  "Code" : "Success",
  "LastUpdated" : "2019-10-15T12:10:34Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ACCESS_KEY_ID",
  "SecretAccessKey" : "SECRET_ACCESS_KEY",
  "Token" : "SESSION_TOKEN",
  "Expiration" : "2019-10-15T18:11:48Z"
}

These temporary credentials grant access to make API calls against any AWS service the role permissions allow.

The metadata can be accessed from within the EC2 instance by querying the metadata API via:

  • HTTP requests to http://169.254.169.254. For example:

      $ curl http://169.254.169.254/latest/meta-data/

  • DNS lookup for instance-data.ec2.internal

  • Via AWS SDK libraries like ec2-metadata module

By default, all EC2 machines have unrestricted access to query metadata this way.

IMDSv1 vs IMDSv2 – Session Tokens and Hop Limits

Originally metadata used IMDSv1 which relies simple GET requests with no authentication. AWS now encourages using IMDSv2 which has additional session handling protections:

IMDSv2

  • Requires PUT request to latest/api/token to begin session and retrieve token
  • Token then must be included in metadata requests as an X-aws-ec2-metadata-token header
  • Tokens expire after 5 minutes
  • Cross checks the Instance ID in the token against current instance to prevent token reuse
  • Configurable HTTP PUT response hop limit to prevent open redirects
  • AWS SDKs use IMDSv2 by default

IMDSv1

  • Simple GET requests with no auth tokens
  • No hop limits on redirects
  • Still enabled by default for backwards compatibility

Disabling IMDSv1 prevents the simplest form of metadata queries by attackers. But the enhanced protections in IMDSv2 like tokens and hop limits provide important isolation even when HTTP endpoint access itself cannot be fully disabled.

The Danger of Metadata Service SSRF Attacks

While enabling Instance Metadata Service access does provide convenience for administering EC2 virtual servers, leaving metadata wide open also poses security risks.

The primary danger is that IAM role credentials exposed in the metadata can be stolen through SSRF attacks.

SSRF or “Server-side request forgery" refers to an attacker forcing vulnerable server-side application code to make requests to internal metadata endpoints they do not have direct access to. Many public-facing apps and apis suffer from SSRF vulnerabilities that allow arbitrary outbound requests to internal IP ranges and AWS endpoints.

Research from cloud security firm Ventack indicates cloud misconfigurations and SSRF risks remain widespread due to legacy software, complexity, and lack of visibility across infrastructures. Studies have shown over 30% of cloud assets are initially misconfigured, introducing preventable risks.

Once an internet-facing system is compromised through something like an unpatched framework vulnerability, attackers can first enumerate metadata IP access, then target IAM credentials. With keys stolen this way, further access can be escalated.

Real-World Attack Statistics

  • Over 75% of companies have sensitive data exposed in cloud storage (McAfee)
  • Estimated 10 billion records exposed in 2022 breaches (RiskBased)
  • Average cost of a data breach is $4.35 million (IBM Cost of a Data Breach Report 2022)
  • Average dwell time before AWS breaches detected is 29 hours (Mandiant)

Locking down metadata access provides protection against this initial credential theft vector. Industry research indicates implementing basic access controls reduces data leakage by over 55% compared to defaults.

Step-By-Step Guide to Disabling Metadata Endpoints

While best practices point to restricting IAM roles and following least-privilege permissions by default, disabling direct access to metadata endpoints still provides an important last line of defense:

1. Identify The EC2 Instance

First identify the EC2 instance IDs you want to update. Use AWS Console, CLI, or tools like Terraform to list your instances:

aws ec2 describe-instances

Make sure to only disable access on instances where metadata is not required for normal administrative purposes.

2. Disable All HTTP Access

Next use the modify-instance-metadata-options CLI command to fully disable the HTTP endpoint:

aws ec2 modify-instance-metadata-options \
   --instance-id i-01234567890abcdef \ 
   --http-endpoint disabled

This blocks all external HTTP requests to 169.254.169.254. Metadata is then only reachable from code running directly on the instance.

Confirm the endpoint is disabled by checking the instance metadata options:

aws ec2 describe-instances \
   --query ‘Reservations[*].Instances[*].MetadataOptions‘

3. Require IMDSv2 Usage

To enforce session tokens over basic IMDSv1 GETs, set:

aws ec2 modify-instance-metadata-options \
   --instance-id i-01234567890abcdef \
   --http-tokens required

This mandates PUT requests to generate tokens before metadata can be accessed.

You can also restrict the number of network hops allowed in PUT responses to defend against open redirects: 

aws ec2 modify-instance-metadata-options \
   --instance-id i-01234567890abcdef \
   --http-put-response-hop-limit 2

4. Attach IAM Policy for Minimum Required Access

Using IAM policies, strictly limit what roles can access metadata. Following the principle of least privilege, create policies tailored to only necessary permissions.

For example, if an application server role only requires hostname info, restrict access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    }
  ]
}

These layered controls prevent leakage even if an EC2 instance itself is compromised internally.

Alternative Options for Metadata Access Controls

In cases where tightly restricting metadata access is not possible due to legacy application needs, alternative techniques can provide protections:

Lambda Proxies

Triggers can invoke Lambda functions to proxy and validate metadata requests before retrieval. This limits exposure of the full metadata API while still providing controlled access.

VPC Endpoints

VPC Endpoints allow instances to connect directly to services using private connections rather than the public Internet. This can extend to metadata without sending requests outside your virtual network.

ALBs and Gateways

Placing Application Load Balancers or CloudFront in front of metadata servers limits direct exposure while still facilitating access. API Gateways can also be used this way.

Valid Use Cases for Metadata Access

There are legitimate reasons to maintain metadata access, for example:

  • Bootstrapping – User data and cloud-init directives allow instances to alter configurations at launch time before networking is online. Disabling metadata would prevent these bootstrap operations.
  • Auto Scaling – ASGs may query metadata like local IP during scaling events to run initialization logic.
  • Containers – Docker and ECS tasks often rely on metadata for service discovery and identity. Breaking this would disrupt inter-service communication.
  • Serverless – Lambda functions may leverage metadata for details on execution context and credentials when handling events.

In these cases using VPC endpoints, proxies, gateways, and forced IMDSv2 provides a balance between usability and security – restricting external access but maintaining internal connectivity.

Expert Guidance on Metadata Risks

Leading cloud security researchers emphasize the importance of locking down roles and metadata access:

  • "Far too many cloud breaches begin with overprivileged identities and lax controls to prevent exploitation of ephemeral workloads. The principle of least privilege must apply to all access, especially metadata services.” – Lucas Moody, Head of Threat Intelligence (Randori)

  • "Metadata is useful but dangerous – sort of like fire. You want those internal endpoints available for systems that genuinely need them, but also locked away from anything outward facing that doesn’t.” – Taylor Leese, Principal Engineer (Unity)

Conclusion: Balance Security Priorities With Administrative Needs

Hopefully this guide has shed light on both the value of EC2 metadata services as well as the risks of allowing unrestricted access. When leveraged carefully metadata can simplify cloud administration – but also provides a vector for IAM credential theft.

Here are some key takeaways:

  • Metadata exposes useful management data via HTTP API that should be locked down
  • Common attack vector is SSRF vulnerabilities allowing remote theft of IAM credentials
  • Controls like enforced IMDSv2 provide important isolation improvements
  • Explicitly disabling HTTP access prevents exploitation by external sources
  • Least privilege policies should restrict roles, limiting blast radius of breaches
  • Proxies, gateways, VPC endpoints facilitate access for internal components that require it

Analyze your workloads, infrastructure dependencies, and threat models to determine where metadata controls need to be strengthened or can be restricted entirely.

With modern cloud platforms the bulk of breaches trace back to small missteps in locking down access and adopting only necessary privileges. Pay special attention to metadata protection across both existing and new environments to close preventable security gaps.

Tags: