Securing AWS: Understanding EC2 IMDS Vulnerabilities and Learning from the Capital One Breach
Introduction:
As organizations navigate the dynamic landscape of AWS, understanding and implementing these best practices become imperative. The Capital One breach serves as a stark reminder that even the most secure cloud environments can be compromised due to misconfigurations. By proactively limiting IMDS access, locking down metadata endpoints, following IAM best practices, and ensuring application updates, users can significantly fortify their AWS environments against potential threats. In the ever-evolving digital landscape, where the stakes are high and data breaches can have severe consequences, adopting a robust security posture is not just a recommendation but a necessity. The shared responsibility model in AWS emphasizes the importance of users actively participating in the security of their cloud infrastructure, and these best practices serve as a practical guide toward achieving that goal.In this Medium story, we delve into the intricacies of the EC2 Instance Metadata Service (IMDS) and draw essential lessons from the notorious Capital One data breach.
MAGIC IP: 169.254.169.254
The IP address for metadata in instances is 169.254.169.254. This is a “link-local” IP address that is used to expose instance metadata through the Instance Metadata Service (IMDS). The 169.254.169.254 — IP address is a “magic” IP in the cloud world. It is used to retrieve user data and instance metadata specific to an instance. It can only be accessed locally from instances and is available without encryption and authentication. Instance metadata is only retrieved from the running instance and not by the console or the AWS CLI. Requests to the metadata via the URI are free, so there are no additional charges from AWS.
IMDS Functionality:
IMDS plays a pivotal role in the cloud ecosystem, offering a channel for instances to retrieve metadata pertinent to their individual configurations. This metadata includes essential information such as instance type, security groups, IAM roles, and more. It functions as a valuable resource for instances to dynamically adapt to their environment and access necessary credentials for interacting with other AWS services.
Potential Risks of IMDS:
While IMDS is a powerful tool, its default settings come with inherent risks. The 169.254.169.254 IP address, being a “link-local” address, is accessible only from within the instance. However, this also means that access to IMDS is available without encryption and authentication, making it susceptible to exploitation if not properly secured.
Evolution of IMDS: IMDSv1 and IMDSv2:
You can access instance metadata from a running instance using one of the following methods:
- Instance Metadata Service Version 1 (IMDSv1) — a request/response method
- Instance Metadata Service Version 2 (IMDSv2) — a session-oriented method
- By default, you can use either IMDSv1 or IMDSv2, or both. You can configure the Instance Metadata Service (IMDS) on each instance so that local code or users must use IMDSv2. When you specify that IMDSv2 must be used, IMDSv1 no longer works.The
PUTorGETheaders are unique to IMDSv2. If these headers are present in the request, then the request is intended for IMDSv2. If no headers are present, it is assumed the request is intended for IMDSv1. - Instance Metadata Service (IMDS) underwent a significant evolution with the introduction of IMDSv1 in 2012. This version aimed to establish a more secure framework for EC2 instances to interact with various AWS services. It addressed key security concerns by introducing a request/response mechanism that allowed instances to query the metadata service securely.IMDSv1 enabled EC2 instances to query the metadata service to obtain temporary credentials dynamically. This architectural shift aimed to mitigate the risks associated with hardcoded or distributed sensitive credentials. AWS introduced IMDSv2 to further enhance the security posture of EC2 instances. IMDSv2 represented a session-oriented method
External User Restrictions: One of the fundamental changes in IMDSv2 was the explicit blocking of external users from receiving credentials. IMDSv2 only allowed application resources within the instance to receive credentials, significantly reducing the attack surface by preventing unauthorized external entities from exploiting the metadata service.
Session Token Usage:IMDSv2 introduced the concept of session-oriented requests. A session token is created using a PUT request, defining the session duration, which can range from one second to a maximum of six hours. During this duration, the same session token can be reused for subsequent requests. After expiration, a new session token must be created for continued access.
Retrieve instance metadata IMDS V1 :
http://169.254.169.254/latest/meta-data/
Retrieve instance metadata IMDS V2 :
IMDSv2 uses session-oriented requests. 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.
The following example uses a Linux shell script and IMDSv2 to retrieve the
top-level instance metadata items. The example:
- Creates a session token lasting six hours (21,600 seconds) using the PUT request
- Stores the session token header in a variable named TOKEN
- Requests the top-level metadata items using the token
You can view the combined command in the aws documentation:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.htmlAfter you’ve created a token, you can reuse it until it expires. In the following example command, which gets the ID of the AMI used to launch the instance, the token that is stored in $TOKEN is reused.
curl -H “X-aws-ec2-metadata-token: $TOKEN” -v http://169.254.169.254/latest/meta-data/ami-idWhen you use IMDSv2 to request instance metadata, the request must include the following:
- Use a PUT request to initiate a session to the instance metadata service. The PUT request returns a token that must be included in subsequent GET requests to the instance metadata service. The token is required to access metadata using IMDSv2. Include the token in all GET requests to the IMDS. When token usage is set to required, requests without a valid token or with an expired token receive a 401 — Unauthorized HTTP error code.
- The token is an instance-specific key. The token is not valid on other EC2 instances and will be rejected if you attempt to use it outside of the instance on which it was generated.
- The PUT request must include a header that specifies the time to live (TTL) for the token, in seconds, up to a maximum of six hours (21,600 seconds). The token represents a logical session. The TTL specifies the length of time that the token is valid and, therefore, the duration of the session.
- After a token expires, to continue accessing instance metadata, you must create a new session using another PUT.
Introduction to the Capital One Breach:
The Capital One data breach stands as a glaring example of the real-world consequences of misconfigurations and vulnerabilities within cloud environments. The breach, disclosed on July 29, revealed a staggering impact on both the United States and Canada, affecting approximately 106 million individuals.
Role of Misconfigured WAF:
Central to the breach was a misconfigured Web Application Firewall (WAF) named ModSecurity. Capital One deployed ModSecurity, an open-source
solution, alongside the Apache Web server.However, a misconfiguration in
this WAF became the gateway for attackers to exploit the AWS platform.
Understanding SSRF:
Server-Side Request Forgery (SSRF) emerged as a pivotal factor in the Capital One breach. SSRF is an attack vector where an attacker crafts a request from a vulnerable web application, enabling them to make the victim server fetch a URL or a local file. Typically, SSRF is employed to target internal systems or services that are normally inaccessible from external networks.
Significance of Metadata Service:
In the Capital One breach, the misconfigured WAF facilitated SSRF, allowing the attacker to manipulate requests and trick the firewall into relaying requests to a critical backend resource on the AWS platform — the metadata service. This service, responsible for providing temporary information to cloud servers, became a vulnerable point of access.
Exploiting the Metadata Service:
On an AWS instance, a simple command illustrates the potential risk: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access. This command retrieves the security credentials for an IAM role named “s3access.” The attacker could exploit this mechanism to gain unauthorized access to sensitive credentials stored in the metadata service.
Background of the Perpetrator:
Paige A. Thompson, the perpetrator behind the Capital One breach, added a layer of complexity to the incident. A former employee of Amazon Web Services (AWS), Thompson’s tenure as a systems engineer from 2015 to 2016 provided her with intimate knowledge of AWS infrastructure.Thompson allegedly exploited a misconfigured firewall on Capital One’s AWS cloud server. Leveraging her insider knowledge, she gained unauthorized access to more than 700 folders of data stored on the server. This breach
highlighted the heightened risk posed by insider threats with knowledge of cloud infrastructure.The breach, boasting approximately 30 GB of stolen credit application data, affected millions in both the U.S. and Canada. The
compromised data included Social Security numbers, bank account numbers, and other sensitive personal information. Capital One, while
quick to fix the issue and alert the FBI, faced one of the most significant financial data breaches to date.
Best Practices for Strengthening IMDS
A. Limiting IMDS Access
Securing the AWS environment requires a proactive approach to limit access to the Instance Metadata Service (IMDS). If IMDS is not essential for a particular instance, it is recommended to turn it off entirely. This not only minimizes the potential attack surface but also reduces the risk of unauthorized access to critical metadata.
B. Locking Down IMDS
A crucial step in fortifying IMDS is to lock down the metadata endpoint, making it accessible only to specific users. On Linux machines, this can be achieved by running the following command: ip-lockdown 192.168.21.2 root. By doing so, the metadata service becomes accessible only to the root user, significantly enhancing security.
C. IAM Best Practices
The Identity and Access Management (IAM) service plays a pivotal role in securing AWS resources. It is crucial to carefully assign roles to EC2 instances, ensuring that each role has the minimum necessary permissions. Unnecessary roles should be avoided, and a thorough analysis of software requirements should be conducted to create roles with the principle of least privilege.IAM roles should be assigned judiciously. If an EC2 instance does not require a specific role, it is advisable not to assign any role at all. This minimizes potential vulnerabilities and restricts access to sensitive information stored in the metadata service.
D. Keeping Applications Updated
While not specific to IMDS, maintaining overall system security involves keeping applications updated and patched regularly. This is a fundamental best practice that ensures the latest security fixes are applied, reducing the risk of vulnerabilities that could be exploited by attackers.
Thanks For Reading :)
Don’t miss out on my upcoming articles! Follow me on Medium for more insightful content. Clap and share this article to spread the knowledge among fellow bug bounty hunters and cybersecurity enthusiasts.
If you have any further questions or would like to connect, feel free to reach out to me.
My LinkedIn handle: https://www.linkedin.com/in/kishoreram-k/
