Hacker News Reader

Comment by talboren | Hacker News Reader

why just now? there are many known attacks (SSRF[1] for example) that are based on IMDSv1. maybe i'm missing something but feels like this should have been done a long ago?

[1] https://www.cyberbit.com/uncategorized/aws-imds-v2-secures-s...

View on HN

The migration isn't transparent, IMDSv2 has been available for a while and they have been pushing for it using warning notifications in the console. AWS deprecates things very slowly and usually avoid breaking changes. For instance, EC2 Classic stayed alive a very long time after they stopped selling it.

Over years, they moved from alerting to changing the default and will later remove IMDSv1 for new instances. Even then, they will not remove it for the previous generations and those may stay for years, the current oldest is M4 which I think is from 2015.

IMDSv2 was initially introduced after the capital one attack. but aws users will have to explicitly enable it and its not enabled by default.

now they are changing the default modes for instances launched from aws console using quick start process. and sometime in 2024 they will give an option to customers to control the default value for all run instances API calls from an account

IMDSv2 has been enabled by default since launch, and was made the default in the AWS SDKs at the same time. What's changing now is that IMDSv1 will be disabled by default. Until now customers had to disable it intentionally, either at the instance level, or by using IAM policies / SCPs to block calls still using IMDSv1 issued credentials.

I think we mean different things, it is enabled by default but I'm saying thats not the default IMDS version that metadata endpoint points to for `/latest/`

for example if you run below curl request on ec2 instances launched from aws console before nov 6th then you will get a response

```sh

curl http://169.254.169.254/latest/meta-data/profile

```

but if you run the same command on ec2 instances launched from aws console after nov 6th, then you will get an error that auth token is missing

IMDSv2 doesn't change the URLs, the "/latest/" in that URL is referring to the meta-data profile, rather than the IMDS version. IMDS is a lower level change in the authentication workflow to use a token (which is retrieved using a PUT request).

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance... has a good example.

Because unlike some other providers, AWS understands the value of backward compatibility. They were the first to make the concept of simultaneously deployed versioned public HTTP APIs work seamlessly at scale, and the number of actually impactful API deprecations they have done is tiny. This is one of them.

Prior to this change, IMDSv2 could be enforced on an account, machine image, and launch API call level.

If you're interested in this topic, you might enjoy reading https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

i assumed it's due to bc but does that mean that bc > security? question is how hard do they push/expose the risks of using soon-to-be deprecated tech

Reply on news.ycombinator.com