Why and How You Should Be Using AWS IMDSv2

Organizations should transition EC2 instances to use Instance Metadata Service Version 2 (IMDSv2) because IMDSv1 is susceptible to server-side request forgery (SSRF) attacks. Uptycs customers should be cautious about enabling the curl table in osquery. Uptycs has updated our version of osquery to work with IMDSv2, and we’ve implemented a rule to help customers identify EC2 instances using the vulnerable metadata service.

What Is AWS IMDSv@?

Amazon Web Services (AWS) IMDSv2 is the second version of the EC2 Instance Metadata Service. An enhancement to instance metadata access that requires session-oriented requests to add defense in depth against unauthorized metadata access, IMDSv2 requires a PUT request to initiate a session to the instance metadata service to retrieve a token.

Description of the Threat

AWS EC2 instances can perform AWS actions based on the instance profile IAM role permissions. With this capability, AWS customers do not have to provision AWS access/secret keys to EC2 instances. However, when creating temporary credentials, IMDSv1 did not follow best practices for implementing secure HTTP endpoints—it used a simple GET method. The best practice is to invoke the HTTP endpoint using methods such as PATCH, POST, or PUT. The idea is to avoid leaking sensitive data when GET methods are used.

An example of how this could be exploited is with the curl table in osquery. An attacker could attempt to retrieve temporary credentials by crafting a GET to perform an SSRF attack on the instance metadata service. With those temporary credentials, the attacker could now use AWS CLI and attempt to access AWS configurations and data. Because there is no enforcement to stop attackers from using this method outside of AWS, they could use it to download files from S3 buckets or perform queries on DynamoDB or RDS databases from a host outside of the AWS environment.

This attack was described by Alexandre Sieira and Rodrigo Montoro at Tenchi Security earlier this year in “Abusing the osquery 'curl' table for pivoting into cloud environments.”

How to Mitigate This Threat

First, we advise customers to transition to using IMDSv2 following the AWS instructions outlined in “Transition to using Instance Metadata Service Version 2.” To help with this transition, we’ve implemented a rule in Uptycs to identify EC2 instances using IMDSv1.

The Uptycs platform helps you easily identify EC2 instances using IMDSv1, which is susceptible to SSRF attacks when creating temporary credentials. (Click to see larger version.)

One of the advantages of osquery is its design principle of not allowing access to potentially confidential data from hosts or the environments in which they run. However, the curl table can be exploited to violate this design principle.

To mitigate this threat to users in AWS, we’ve updated our version of osquery to work with IMDSv2, which requires the use of a multi-step session-oriented approach and custom HTTP headers. The osquery curl table does not allow for these custom HTTP headers or methods other than GET, mitigating the threat to EC2 instances. By default, we use IMDSv2 but fall back to IMDSv1 so that customers can transition. The new ec2_instance_metadata table does not retrieve temporary security credentials.

The curl table still poses a problem outside of AWS, so we’ve also updated the Uptycs version of osquery to disable the curl table by default. Only users with sufficient role-based privileges can use the enable_curl flag to turn it on. Depending on the nature of the environment and who has access to run osquery real-time queries, customers should identify whether to keep the curl table disabled by default or enable it.

Here are some resources for further reading:

• AWS Security blog post on IMDSv2
• AWS documentation on instance metadata
• IAM roles for EC2
• Server-side request forgery