There is a local metadata API for Azure but it is fairly simple right now.

Some limited instance info about your host ID, fault domain, and update domain: curl http://169.254.169.254/metadata/v1/InstanceInfo

Poll this regularly to find out when your VM is about to go down for maintenance: http://169.254.169.254/metadata/v1/maintenance

Those are the only two endpoints I know of. I encouraged them to require a special header for access to this API before releasing to the public but it looks like it was not included. A special header would help prevent your app from being able to access this from a user specified URL.

Google requires a header to help prevent this: https://cloud.google.com/compute/docs/storing-retrieving-met...

thank you so much for posting these extra details. My product is hosted on Google Cloud and allows users to arbitrarily craft http requests (including headers!)

I try to limit the possibility of abuse (restricting protocol to http, https, //, data, or ftp) but didnt know about this metadata issue.

I updated my product to account for this issue too.

it looks like google's metadata doesn't leak any important secrets (unless I had custom metadata, which i do not) but better safe than sorry!

You are getting downvoted because it's not a vulnerability.

It's well documented and very useful feature in aws and it also exists in gcloud, although gcloud documentation is not as good^1.

It only becomes a vulnerability if you don't read the documentation AND don't follow best practices^2.

I don't know if azure provides this feature.

^1 I use gcloud now and have used aws in the past.

^2 Don't run unknown code without proper sandboxing

It's borderline a privilege escalation vulnerability. The default behavior is that an unprivileged user on the system with network access can get access to an instance's credentials that can be used to perform administrative functions.

Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.

No, it is not a vulnerability. Misunderstanding of this functionality can result in developer introducing a vulnerability, but this is a well described, well defined feature.

Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.

I didn't mean to suggest it being what it isn't.

I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.

If your service allows arbitrary url queries that a user can trigger then you should make sure that you only allow queries to publicly routable ip ranges anyway.

169.254.0.0/16 is link-local range which you should be flitering along with publicly routable ip ranges that might be very upset if you access them like .mil reserved ip ranges. Go as far to also only allow DNS names instead of arbitrary ip, keeping in mind dns names may resolve to non publicly routable ranges or ranges you may not wish to access. These are all standard dangers of making queries on a user's behalf.

Good list of ipv4 ranges you should not allow: https://github.com/robertdavidgraham/masscan/blob/master/dat...