Abusing Reverse Proxies, Part 1: Metadata

Abusing Reverse Proxies, Part 1: Metadata


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 for metadata access, with the exception of Alibaba's

Blue Team: block incoming requests to metadata IPs on the perimeter if your usage allows. And if technically possible, block any inbound requests with names that resolve to the metadata IPs.

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.
Internal private network clients access the internet via a proxy server.
  • 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.
Internet users use the proxy to retrieve information from the content servers.

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).

IMDSv1 (discussed here) lacks any authentication/authorization. Many services offer IMDSv2 which does require authentication/authorization. It is highly recommended using this more secure version, if available.

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.com

This 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):

The intended functionality is to access the content servers, however, the misconfiguration allows access to the metadata API.

If the service is accessible, we will receive the instance metadata.

Instance metadata from a Digital Ocean virtual machine.

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).

An example of the OpenStack user_data method from bug bounty testing. In this case, the build script contained the encrypted root password.

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!

Subscribe to our newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox. It's free!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!