AWS IMDSv2, also known as Instance Metadata Service Version 2, is a secure and enhanced version of the AWS Instance Metadata Service. It provides an interface that allows EC2 instances to securely retrieve metadata about themselves and their associated IAM roles.
IMDSv2 offers improved security features compared to its predecessor, IMDSv1. It uses local authorization tokens for API calls, which are obtained by requesting a session token using an X-aws-ec2-metadata-token-ttl-seconds header in the HTTP GET request. These tokens have limited scope and duration, reducing the risk of unauthorized access.
The key benefits of using IMDSv2 include protection against SSRF attacks (Server-Side Request Forgery), ensuring that only authorized entities can access instance metadata. Additionally, it prevents attackers from exploiting any vulnerabilities within applications running on EC2 instances to gain unauthorized access.
By default, all new Amazon EC2 instances launched after July 28th, 2020 use IMDSv2 as the default method for accessing instance metadata. Existing instances can be manually upgraded to use IMDSv2 through various methods provided by AWS documentation.
Why You Should Use AWS IMDSv2
AWS IMDSv2, or Instance Metadata Service version 2, is a significant improvement over its predecessor IMDSv1. It provides enhanced security features and mitigates several vulnerabilities present in the older version. Here are some detailed reasons why you should use AWS IMDSv2:
1. Improved Security:
– Protection against SSRF attacks: Server-Side Request Forgery (SSRF) attacks exploit vulnerabilities to access sensitive resources on an instance by making unauthorized requests to the metadata service. In IMDSv2, this risk is significantly reduced as it verifies if the request originates from within an EC2 instance.
– Defense against token theft: In IMDSv1, if an attacker could compromise one process on your EC2 instance, they could potentially steal EC2 instance profile credentials and gain unauthorized access to other AWS services. However, with IMDSv2’s session authentication mechanism using short-lived tokens, such risks are effectively eliminated.
2. Enhanced Access Control:
– Fine-grained permissions control: With IAM roles for Amazon EC2 instances and policies attached to them, you can define granular permissions that allow only necessary actions on specific resources.
– Restricting network access: By configuring VPC endpoints for accessing the metadata service instead of using public IP addresses or NAT gateways/instances, you can control which entities have access to it.
3. Simplified Integration:
– Seamless upgrade path: Migrating from IMDSv1 to v2 doesn’t require any major changes in your application code since most SDKs automatically handle retrieving metadata securely via v2.
– Compatible with existing applications: Applications designed around accessing metadata through HTTP headers will continue working without needing explicit modifications.
4. Prevention of accidental data exposure:
– Non-sensitive data separation: In contrast to previous versions where all data was accessible at `/latest/meta-data`, the new design separates sensitive user-supplied data under the path `/latest/user-data`, reducing the risk of accidental data exposure.
5. Compliance and Auditing:
– IMDSv2 provides improved logging capabilities, including capturing failed requests, which can aid in compliance audits.
– Combined with AWS CloudTrail, you can monitor and audit all API calls made to your EC2 instances further enhancing visibility into metadata service access.
In conclusion, using AWS IMDSv2 offers significant security improvements by reducing vulnerabilities such as SSRF attacks and token theft. It also provides enhanced access control options, simplified integration paths for existing applications, prevention of accidental data exposure, and better compliance auditing capabilities.
Summary
The fact that open WAFs very rarely support HTTP PUT requests, makes the requirement of a PUT request a new layer of defense. With the IMDSv2 service to require a PUT request at the beginning of a session, it prevents open WAFs from being abused to access the IMDS in the vast majority of cases.
Reverse proxies, such as Apache httpd or Squid, can be misconfigured to allow external requests that reach internal resources, but it’s still normal for these proxies to send an X-Forwarded-For HTTP header. IMDSv2 will not issue session tokens to any caller with an X-Forwarded-For header, which is effective at blocking unauthorized access due to misconfigurations like an open reverse proxy.
IMDSv2’s combination of beginning a session with a PUT request, and then requiring the secret session token in other requests, is very effective in protecting you against the vast majority of SSRF vulnerabilities.
With IMDSv2, setting the hop limit value to “1” means that requests only from the EC2 instance itself will work. If the EC2 instance has been misconfigured as an open router, layer 3 firewall, VPN, tunnel, or NAT device, the packet containing the response will be discarded on its way out of the instance, preventing transport to the attacker. The information won’t make it further than the EC2 instance itself, which means that an attacker won’t get the response back with the token, and with it the ability to access instance metadata, even if they’ve been successful at getting past all other defenses.
How to Require the use of IMDSv2
When you launch an instance, you can configure the instance to require the use of IMDSv2 by setting the Metadata version to V2 only.
From October 2022, you can also set an EC2 Amazon Machine Image (AMI) to use (IMDSv2 by default.