How to Compromise AWS Using the Metadata Service

The AWS Metadata service facilitates information access for applications running on a given EC2 instance. This is provided to aid the configuration and management of tooling and is accessible only by the instance itself.

Per Amazon:

However, as you may have noticed, the Metadata service possesses one unique characteristic that is useful to attackers. Along with providing information access to the given instance, it also provides credentials.

Why does this matter?

This effectively means that an attacker who compromised an AWS instance can query the Metadata service for credentials that can then be used for lateral movement to other cloud resources.

Attack Breakdown

Let’s say an attacker has compromised a host and acquired access using SSH. From a shell, the Metadata service can be accessed using:
curl http://169.254.169.254.

The Metadata service can then be more directly queried through the /latest/meta-data path on this URL.

The attacker can request a fresh pair of AWS access keys using the complete path of:
http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

And just like that, an attacker has a separate pair of credentials! These keys can then be used for lateral movement after an initial breach or persistence.

But Wait There’s More

So, while the first example is only limited to an attacker somehow acquiring a shell on a resource, it is actually not the most realistic attack scenario that exploits the Metadata service.

Instead, a web application exploitation method known as Server-Side Request Forgery (SSRF) is the most likely way for attackers to gain the ability to target the metadata service.
The interesting thing about this attack chain is that it immediately shifts the threat model of an organization from its web application environment to its infrastructure. This breaks the common assumption that a web application vulnerability can only impact the application itself. In some cases, this can be devastating for an organization.

SSRF

To understand how this works, one must know what an SSRF vulnerability looks like. For example, consider a web application hosted on AWS that has the following URL:

This URL allows the application to load images from disparate locations that are used in the web application. However, an attacker notices this and changes the remote parameter to an IP address under their control.

Once the new URL is accessed, the attacker checks their server logs and notes a hit from the web application server.

This is an SSRF vulnerability, as the attacker can convince the web application into making requests to unintended resources.

When exploited in web applications that run on AWS, this kind of weakness can be catastrophic. Consider an attacker who takes advantage of the same URL by issuing this request:

When this is issued, the web application tries to fetch the “image” and store it in the web application, but it is, in reality, fetching a fresh pair of AWS credentials that can be used by the attacker:

Mitigation: IMDSv2

AWS has since released Instance Metadata Service v2 (IMDSv2), which adds an additional layer of protection to the metadata service by requesting session authentication.

This is achieved by requiring a PUT request to be used initially to gather a secret token. This token is then used as a password for performing additional actions with the metadata service, including still requesting credentials.

Therefore, IMDSv2 does not fix metadata service credential leakage entirely but makes it more difficult to achieve through a generic SSRF vulnerability.

Alternatively, the metadata service can be completely disabled on EC2 instances, although this remediation path may have drawbacks should your assets utilize the service.