Level 5: Metadata Exposure

Task

This EC2 has a simple HTTP only proxy on it. Here are some examples of it's usage:

• http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/

• https://cleargrandquietbirds.neverssl.com/online/

• http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/

See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it.

Resolution

Reading the articles provided, we learn that AWS has the IP 169.254.169.254, known as the "magic IP". This IP contains the metadata service, and with improper configuration, credentials can be exposed.

By accessing:

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/

We can see the credentials.

Once we have this, we create an AWS user in the console:

sudo vim ~/.aws/credentials

Now, we list the contents of the Level 6 bucket.

Finally, we simply navigate to:

<level6_URL>/ddcc78ff

Lesson Learned

The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use Metadata-Flavor: Google as an HTTP header and refusing requests with an X-Forwarded-For header. AWS has recently created a new IMDSv2 that requires special headers, a challenge and response, and other protections, but many AWS accounts may not have enforced it. If you can make any sort of HTTP request from an EC2 to that IP, you'll likely get back information the owner would prefer you not see.

Examples of this problem

• Nicolas Grégoire discovered that prezi allowed you point their servers at a URL to include as content in a slide, and this allowed you to point to 169.254.169.254 which provided the access key for the EC2 intance profile (link). He also found issues with access to that magic IP with Phabricator and Coinbase.

A similar problem to getting access to the IAM profile's access keys is access to the EC2's user-data, which people sometimes use to pass secrets to the EC2 such as API keys or credentials.

Avoiding the mistake

Ensure your applications do not allow access to 169.254.169.254 or any local and private IP ranges. Additionally, ensure that IAM roles are restricted as much as possible.