Forem: N&an Gadhetharia

Demystifying IMDS: The Backbone of EC2 Instances

N&an Gadhetharia — Mon, 24 Jul 2023 06:35:48 +0000

Introduction:
In the Amazon Web Services (AWS) space, Instance Metadata Service (IMDS) plays a key role in driving the functionality of Amazon Elastic Compute Cloud (EC2) instances. IMDS acts as a authoritative source for retrieving metadata about EC2 instances and related resources. In this blog, I will explain in detail how IMDS works, explore the relationship between IMDS and EC2, and show how a developer can use his IMDS to build dynamic and scalable applications on his AWS cloud. I understand.
Understanding IMDS:

The Instance Metadata Service (IMDS) is a RESTful web service that exists within the EC2 infrastructure provided by AWS. This gives your EC2 instance access to important metadata about itself and its environment. Metadata here is information that describes the properties and configuration of an instance.
IMDS works in a client/server model, with an EC2 instance acting as the client and IMDS acting as the server. It works over a secure internal network connection and ensures that the metadata retrieval process remains isolated and protected within his AWS environment.
How IMDS works:

How IMDS Works:

Instance Initialization: When an EC2 instance is launched, it automatically contacts the IMDS to retrieve its initial metadata. This metadata includes details like the instance ID, availability zone, security group information, and network configuration. This information is crucial for the instance to configure itself correctly during the bootstrapping process.
Metadata Querying: EC2 instances can query IMDS at runtime to retrieve dynamic metadata. This allows instances to adapt to changes in their environment. For example, an instance can retrieve its public IP address, IAM role information, or network interface details.
Metadata Accessibility: IMDS follows a strict security model. Only the EC2 instance itself can access its own metadata. This prevents unauthorized access from external sources, adding an extra layer of security to the instance. The metadata retrieval process is limited to the instance’s internal IP address, ensuring that sensitive information remains protected.

Imagine you’re a developer building an application that runs on an Amazon EC2 instance. Traditionally, you would need to store access credentials, like special keys and secrets, directly within your code or configuration files. However, this approach can be risky and challenging to manage.

With the help of IMDS, you can take a different and more secure approach. IMDS stands for Instance Metadata Service and is like a special vault of information that’s available only to your EC2 instance. Instead of storing access credentials directly on the instance, you can use something called an IAM role.

Think of an IAM role as a set of permissions or rules that define what your EC2 instance can do. By assigning an IAM role to your instance, you’re essentially saying, “Hey, this instance has the power to access specific resources and perform certain tasks.”

Now, here’s where IMDS comes into play. When your EC2 instance starts up, it automatically reaches out to IMDS and asks for its assigned IAM role. IMDS acts as a trusted source of information, providing the instance with the necessary credentials it needs to access AWS services securely. This process has a few benefits. First, it saves you the trouble of manually managing access credentials on each instance. You don’t have to worry about distributing and rotating keys and secrets anymore. Instead, the instance gets its credentials on-demand from IMDS, making everything easier and more secure.

By simplifying the management of access credentials and enforcing the principle of least privilege, IMDS and IAM roles make your life as a developer easier. You can focus on building your application and rely on the secure infrastructure provided by AWS.

Conclusion:
In a nutshell, IMDS is like a secret vault that holds the credentials your EC2 instance needs. By using IAM roles and IMDS, you eliminate the hassle of managing credentials manually, making your application more secure and your development process smoother.

Happy Learning!
Next time, we’ll talk about some interesting cases of SSRFs with IMDS.

SSRF and IMDS: Understanding the Relationship and IMDSv1 Vulnerabilities

N&an Gadhetharia — Mon, 24 Jul 2023 06:34:43 +0000

BUT FIRST WHAT IS SSRF ?
Understanding Server-Side Request Forgery (SSRF) : Server-Side Request Forgery (SSRF) is a type of web vulnerability where an attacker tricks a website into making requests on their behalf.

Here’s an analogy to help understand SSRF: Think of the website as a person who can fetch things for you (i.e. web server). They have a list of approved places they can go to and bring back information. However, with SSRF, the attacker tricks this person( i.e. web server) into going to a different place(i.e. Backend server) without their knowledge. The attacker might give them a misleading or malicious URL that points to a sensitive internal resource or a different website altogether.

EXPLAINING ABOVE ANALOGY
The person goes to the URL provided by the attacker, thinking it’s a legitimate request. But behind the scenes, the attacker may be accessing private information, like internal databases, sensitive files, or even other websites that the person’s computer can reach. This can lead to unauthorized access, data leaks, or even attacks against other systems.

In summary, SSRF is a vulnerability where attackers trick a website into making requests on their behalf, potentially accessing sensitive information or launching attacks.

The SSRF and IMDSv1 Connection :
The connection between SSRF and IMDS lies in the fact that attackers can exploit SSRF vulnerabilities to access and abuse the IMDS service. Check this to understand more about IMDS.

Problem #1:

Weak Authentication: Authentication is like a lock on a door that ensures only authorized individuals can gain access. IMDsv1 lacked a strong authentication mechanism, meaning it relied solely on the fact that requests were coming from the cloud instance itself. It’s like a door that opens just because someone says they’re allowed, without checking their credentials. This made it easier for attackers to exploit a security vulnerability called SSRF, tricking IMDsv1 into providing sensitive information.

Problem #2:

Unrestricted Access to Sensitive Data: Imagine you have a personal diary with all your private thoughts and secrets. Now, picture if anyone could simply open it and read everything inside without any restrictions. That’s what happened with IMDsv1. It allowed attackers to access sensitive data, including temporary security credentials, which are like powerful keys that grant access to important resources

Example :
If there is a web server running on EC2 instance. This web server has a simple SSRF vulnerability, allowing us to make GET requests to arbitrary addresses. We can leverage this to make a request to http://169.254.169.254 via bypassing some factors.

To view all categories of metadata from within a running instance, you need to access the following :

http://169.254.169.254/latest/meta-data/
To determine if the EC2 instance has an IAM role associated with it, look for

http://169.254.169.254/latest/meta-data/iam/
response 404 indicates there is no IAM role associated.

If there is a valid role you can steal, make a request to :

http://169.254.169.254/latest/meta-data/iam/security-credentials/
This will return the name of the IAM role the credentials represent. Suppose the role name returned is ‘xxxx-role’.

To steal the credentials, append the role name(i.e. xxxx-role) to your previous query. For example, we’d query

http://169.254.169.254/latest/meta-data/iam/security-credentials/xxxx-role/.
AND BOOM 💥💥 !!!! , it will expose private creds, that should only be known to authorized individuals. This unrestricted access gave attackers a way to infiltrate the cloud environment and potentially cause more harm.

CONCLUSION:
While IMDsv1 served its purpose of providing important information to cloud instances, it had vulnerabilities that made it susceptible to exploitation. Weak authentication and unrestricted access to sensitive data were the primary concerns.

ENDING NOTE:

If you found this blog helpful in understanding the relationship between SSRF and IMDS vulnerabilities, please consider connecting with me on LinkedIn or Twitter. I would love to hear your feedback and engage in discussions about cloud security and best practices. Together, we can create a safer and more secure digital landscape.

Next time, we’ll talk about Protecting Against IMDsv1 Vulnerabilities.

Enhancing Data Security: Unveiling IMDSv2's Shield Against Vulnerabilities in IMDSv1

N&an Gadhetharia — Tue, 13 Jun 2023 05:24:32 +0000

Imagine you are visiting a restaurant that serves a buffet. Previously (IMDSv1), everyone was free to go to the buffet table and take food home without any controls or restrictions. This created a security vulnerability as a malicious person could easily contaminate or tamper with the food.

IMDSv2 : a session-oriented method

With a new approach using IMDSv2 session-oriented requests, the restaurant implemented a system to prevent unauthorized access to the buffet. Before entering the buffet area, each customer receives a special identification bracelet (i.e. token) indicating their access. This bracelet is valid for a certain period of time, say X hours.

With your wristband, you are free to move to the buffet table and self-serve within the allotted time. However, after X hours, the wristband will expire and you will not be able to access the buffet.
This security measure avoid unauthorized persons from entering the buffet area and tampering with the food. To ensure a safer dining experience for all, only those with valid wristbands may interact at the buffet.

Similarly, in the context of IMDSv2, session tokens serve as a form of identity, granting authorized access to the system's resources. For requests, the session token acts as a validation mechanism, ensuring that the requester has the proper permissions to access the requested data.

By implementing session-oriented requests, IMDSv2 adds an additional layer of security against SSRF attacks. An SSRF attack occurs when an attacker tricks a server into making unintended requests to internal or external resources. In IMDSv2, session tokens limit requests to authorized sources and prevent unauthorized access to sensitive information and Once the session expires, a new token must be obtained, minimizing the risk of prolonged unauthorized access.

Instance Metadata Service Version 1 (IMDSv1) - a request/response method
Instance Metadata Service Version 2 (IMDSv2) - a session-oriented method

SO HOW TO REQUEST INSTANCE METADATA WHILE USING IMDSv2.

Use a PUT request to initiate a session to the instance metadata service. A PUT request returns a token that must be included in subsequent GET requests to the Instance Metadata Service. Tokens are required to access metadata via IMDSv2.

Generating a Token:

$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"

Then, use the token to get metadata items using the following command.

$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id

After you've created a token, you can reuse it until it expires.
Include the token in all GET requests to IMDS. If token use is set to required, requests without a valid token or with an expired token will receive the error code 401 - Unauthorized HTTP Error.
A token is an instance-specific key. This token is not valid on other EC2 instances, so any attempt to use the token outside of the spawned instance will be rejected.

The PUT request must include a header that specifies the token's time-to-live (TTL) in seconds, up to 6 hours (21,600 seconds). A token represents a logical session, and TTL indicates the lifetime of the token, i.e. how long the session lasts.
Also, By using a default hop limit (TTL) of 1, a session token can only be used directly from the EC2 instance where that session was initiated.

Identifying IMDSv1 instances in you AWS account and Upgrading it.

Use AWS EC2 CLI describe-instances to pull the instance metadata for each instance. For IMDSv1, the instance metadata option HttpTokens is set to optional.

aws ec2 describe-instances --region=us-east-1 --query Reservations[*].Instances[*].MetadataOptions

The Output:

{ 
 "State": "applied", 
 "HttpTokens": "optional", 
 "HttpPutResponseHopLimit": 1, 
 "HttpEndpoint": "enabled" 
 }

To enable IMDSv2 on the selected instance, run the following command. In the parameters, HTTP endpoint must be set as enabled and HTTP Tokens must be set as required.

aws ec2 modify-instance-metadata-options --instance-id xxxxxxx > --http-endpoint enabled --http-tokens required --region=us-east-1>

After this you will see this as output when you pull the instance metadata for the instance that you modified.

{ 
 "State": "applied", 
 "HttpTokens": "required",
 "HttpPutResponseHopLimit": 1, 
 "HttpEndpoint": "enabled" 
 }

CONCLUSION:

IMDSv2 is a new recommended security best practice to enable on your instances. It provides another layer of security to access your instance metadata, even if IMDSv2 is enforced, there's a possibility that your environment could still have vulnerable software or misconfigurations. These weaknesses may leave IMDS exposed to potential credential harvesting.

ENDING NOTE:

If you found this blog helpful, please consider connecting with me on LinkedIn or Twitter. I would love to hear your feedback and engage in discussions about cloud security and best
practices.
Checkout My Previous Blogs