Cloud instances need to know things about themselves, and the cloud provider tells them through a local service. That convenience is also a target. MITRE tracks the abuse as T1552.005, Cloud Instance Metadata API, a Credential Access technique for IaaS.
How attackers use it
Most cloud providers offer a Cloud Instance Metadata API to running virtual instances. It returns information such as name, security group and other metadata, including sensitive data like credentials and UserData scripts that may hold more secrets. It exists to help manage applications, and MITRE stresses it is accessible by anyone who can reach it from the instance. MITRE adds that a cloud metadata API has been used in at least one high profile compromise.
The de facto standard address is 169.254.169.254, over plain HTTP.
MITRE documents two routes.
- Presence on the instance. If an adversary is running on the virtual instance, they can query the API directly for credentials that grant access to more resources.
- Server-Side Request Forgery (SSRF). If a public-facing web proxy or application can be made to fetch a URL of the attacker's choosing, the attacker can get it to request the metadata address and return the response.
The second is the one defenders underestimate. The application does not need to be compromised in the usual sense. It only needs to make a request on someone else's behalf, and the credentials come back in the response.
How to detect it
MITRE's detection strategy covers access attempts to metadata endpoints such as 169.254.169.254 from virtual machines or containerized workloads, including both direct access and patterns that look like SSRF exploitation.
Useful ways to apply that.
- Log outbound connections to the metadata address per workload, and learn which workloads legitimately use it.
- Alert on a web-facing application process that suddenly requests it.
- Follow credential use afterward. Credentials issued to an instance that appear in use from an unfamiliar network location are a strong signal.
How to reduce the risk
MITRE lists three mitigations.
- Disable or Remove Feature or Program: disable unnecessary metadata services, and restrict or disable insecure versions of the services you do use.
- Filter Network Traffic: limit access to the Instance Metadata API. A properly configured Web Application Firewall can help stop external adversaries from using SSRF to reach it.
- Limit Access to Resource Over Network: limit access with a host-based firewall such as
iptables.
Providers differ in what they offer. As one example, AWS provides a session token based version of its metadata service, IMDSv2, and allows requiring it. Check what your own provider documents, and keep the roles attached to instances narrow, so that a leaked credential opens little.
Check your own environment
A read-only AWS CLI query that lists, per instance, whether tokens are required for metadata requests.
aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]" --output text
Instances that show optional accept the older, token-free requests. Then ask these questions.
- Which web-facing services accept a URL from the user and fetch it? Can they reach the metadata address?
- Which roles are attached to those instances, and how much can each one do?
- Do containers on a node have a path to the node's metadata service?
Connecting cloud accounts into one inventory helps you answer those questions across regions. The interactive demo shows the idea.
Click through it at your own pace, or open it full screen.
Quick check
Why can an SSRF bug expose cloud credentials?
The vulnerable application can be tricked into requesting the local metadata address and returning the result, which may include credentials.
Which address is the de facto standard for the metadata API?
169.254.169.254.
Sources
- MITRE ATT&CK, Unsecured Credentials: Cloud Instance Metadata API: https://attack.mitre.org/techniques/T1552/005
