Instance metadata service(IMDS) exposes three categories of data using linked-local address 169.254.169.254
- dynamic
- meta-data
- user-data
dynamic data exposes instance identity in plaintext JSON format.This gets attached to it whenever instance is either stopped and started, restarted or launched. It is recommended to verify the identity document retrieved from IMDS url.PlainText instance identity document is accompanied by 3 hashed and encrypted signatures.These signatures can be used to verify the origin and authenticity of the instance identity document.AWS releases the regional public certificates. Depending on the region it is mandatory for users to use correct public certificate during verification.Contents of instance-identity document cosnists of details such as imageId, instanceId and privateIp associated with instance.
meta-data exposes the information about the running instance that can be used during automation.If AWS releases new category of the meta-data then it may not be readily available on the running instance.The most sensitive information available in the meta-data is the identity-credentials.STS token that is assigned to instance can be found here and can become a tool for exploitation.
user-data are set of commands that are entered during instance launch time to perform configuration activities.These commands are run with root privileges and it is a best practice to not enter any sensitive information such as credentials in the user data sections as it is available in plain text format.
Introduction of IMDSv2
AWS have released v2 of IMDS to fix the security issues related to original service. Unlike v1 , IMDSv2 requires users to provide additional session token while invoking IMDS url. Also as per default settings of IMDSv2 TTL is set
to 1 which means response from IMDS is now valid only till single hop or local instance.This protects users from accidentally exposing IMDS endpoints via misconfigured reverse-proxies.
Top comments (0)