Introduction
Many cloud service providers offer a "metadata" service on their virtual machines. These services offer sensitive details about the instance and cloud operating environment.
Metadata services offer REST APIs to programmatically retrieve this data. Amazon’s AWS service defined the IMDSv1 “standard” on their EC2 instances, and since then many others have adopted this IMDSv1 scheme as well, including AWS, Google, and Azure.
The services have generally settled on the IP address 169.254.169.254 for metadata access, with the exception of Alibaba's 100.100.100.200.
For security reasons, this service can generally only be accessed via the localhost. Upon a server compromise or SSRF vulnerability, however, this service can be accessible to attackers (there have been more than a few disclosures and bounties paid).
Another possible vector to access the metadata service is via misconfigured reverse proxies (which some people do classify as SSRF).
A primer on open proxy types
- Forward: typical use case is allowing private network users to access the internet via a common egress point. This allows an organization to make rules for which types of internet services are accessible to users.
- Reverse: typical use case is to allow internet users access to certain services accessible to the internet via the gateway and block access to other backend systems. This is done for many reasons including load balancing, failover, security, etc., and when helps limit attack surface from the internet.
When improperly configured, a reverse proxy can allow access beyond intention to other hosts the proxy can access, including itself on the local interface.
If the proxy service is running on a cloud system with IMDS, the metadata service is therefore accessible since the proxied request is coming from the localhost (a byproduct of how reverse proxies work).
Let’s take a closer look at how the attack works compared to a normal reverse proxy.
As shown above, the clients can access any host due to an improper (or lacking) proxy rule. This can lead to private network access (to any host accessible by the VM running the proxy) as well as the metadata service.
When a client is configured to use a proxy, the HTTP request follows a format such as:
GET http://example.com/page.html HTTP/1.1
Host: example.comThis will direct the proxy to fetch “page.html” from example.com and provide the results to the client.
As an attacker, we can modify the target site and the Host header to access the IMDSv1 service (Digital Ocean):
GET http://169.254.169.254/metadata/v1/ HTTP/1.1
Host: 169.254.169.254
If the service is accessible, we will receive the instance metadata.
Since metadata services are well-documented, an attacker can then explore the paths provided via the API. If cloud roles, account names, keys, or passwords are found it may be possible to pivot to host access or other cloud services (e.g., s3).
As it is becoming more common for companies to outright block incoming requests with metadata IPs somewhere in them, the nuclei templates also use hostnames that resolve to the correct IP addresses for the metadata services.
Nuclei now include templates to look for this issue across several cloud providers. All can be found in the misconfigurations/proxy/ directory with names metadata-[servicename].yaml that includes services listed below:
- Amazon AWS
- Google Cloud Platform (GCP)
- Alibaba
- OpenStack
- Microsoft Azure
- Digital Ocean
- Oracle
- Hetzner Cloud
Check out Abusing Reverse Proxies, Part 2: Internal Access for more proxy abuse!
