This is a guest diary contributed by Remco Verhoef. Interested in publishing a guest diary? Sent us your idea via our contact form.

Most cloud providers offer metadata using private urls. Those urls are used to retrieve metadata for the current configuration of the instance and passing userdata. The configuration contains data like security groups, public ip addresses, private addresses, public keys configured and event rotating secret keys. The userdata can contain everything like initialization scripts, variables, passwords etc.

The metadata urls will vary per cloud provider, I’ve written a few down together with their metadata url and a link to the documentation.

Google
http://169.254.169.254/computeMetadata/v1/
https://cloud.google.com/compute/docs/storing-retrieving-metadata

Amazon
http://169.254.169.254/latest/meta-data/hostname
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Openstack
http://169.254.169.254/2009-04-04/meta-data/instance-id
https://blogs.vmware.com/openstack/introducing-the-metadata-service/

Dreamhost
http://169.254.169.254/metadata/v1/hostname
https://developers.digitalocean.com/documentation/metadata/

Azure
http://169.254.169.254/metadata/v1/maintenance

The configuration and userdata is used by scripts, automating tasks and applications, but the danger is that it can be abused to leak information about the current instance. Information an attacker needs to elevate privileges or move laterally. This information can contain usernames, passwords, configuration, keys or scripts.

When your application accepts remote urls as data like a proxy server, vpn server or a web application (think about wordpress plugins for embedding remote content, web screenshotting applications and many more), you need to be sure the metadata url is not accessible. If you install a default squid proxy for example, just executing this command:

$ http_proxy=proxy:3128 curl http://169.254.169.254/latest/dynamic/instance-identity/document                                                                                                                 {
 "devpayProductCodes" : null,
 "privateIp" : "172.31.9.215",
 "availabilityZone" : "eu-west-1c",
 "version" : "2010-08-31",
 "region" : "eu-west-1",
 "instanceId" : "i-*****",
 "billingProducts" : null,
 "pendingTime" : "2017-02-03T20:21:11Z",
 "instanceType" : "m3.medium",
 "accountId" : "*****",
 "architecture" : "x86_64",
 "kernelId" : null,
 "ramdiskId" : null,
 "imageId" : "ami-e31bab90"
}

This will return all metadata of the proxy server.

Anyhow the metadata contains information you don't want to disclose. You’ll be safe when the private ip has been blocked, but this is not always possible (in the case of the rotating secret keys for example). Blocking the requests can be done using good old iptables:

$ iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP

This will only allow root to access the metadata url, allowing the boot sequence to use the metadata and disallowing the web servers to use the metadata.