Enhancing Data Security: Unveiling IMDSv2's Shield Against Vulnerabilities in IMDSv1
Tags: cloud, security, aws, cybersecurity
Published: 2023-06-13 05:24:32


Imagine you are visiting a restaurant that serves a buffet. Previously [_(IMDSv1)_](https://medium.com/@nandan_writes/ssrf-and-imds-understanding-the-relationship-and-imdsv1-vulnerabilities-1bf467f7da8a), 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g2w5upiy1hu8yvpmkmme.jpg)

**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](https://www.linkedin.com/in/nandan-g/) or [Twitter](https://twitter.com/nandan_twt). I would love to hear your feedback and engage in discussions about cloud security and best 
practices.
Checkout My Previous[ Blogs ](https://medium.com/@ndan11gadhetharia)