Much has been written about how COVID-19 has impacted cybersecurity during 2020, from heightened cybersecurity threats to foundationally challenging business resiliency. However, there are other lessons for cybersecurity which are unnoticed or under-emphasized. Swiss...
Abusing AWS Metadata Service
AWS EC2 has a feature called the Instance Metadata Service (official documentation). This enables any EC2 instance to access a REST API running on 169.254.169.254, which returns data about the instance itself. Some examples include the instance name, the instance image (AMI) ID, and a bunch of other sensitive data.
On an AWS instance, the following command retrieves the security credentials for an IAM role named s3access.
The following is example output.
This is the list of IAM roles attached to the machine. IAM (which stands for Identity Access Management) is the AWS service allowing you to manage users, roles and permissions. We see here that a single role, s3access, is attached to it and can therefore access the credentials attached to this role using the Metadata API. That’s a mechanism that allows you to attach roles to machines instead of hardcoding AWS API keys into your application code.
How do we use this? …SSRF
If you ever encounter a web application vulnerability that allows a URL to be requested by the server, you likely have SSRF. Server Side Request Forgery (SSRF) refers to an attack where in an attacker is able to send a crafted request from a vulnerable web application. SSRF is usually used to target internal systems behind firewalls that are normally inaccessible to an attacker from the external network. Additionally, it’s also possible for an attacker to leverage SSRF to access services from the same server that is listening on the loopback interface (127.0.0.1).
Typically Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the request that is being sent. A common example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party service.
On your next pentest, find a SSRF vulnerability and if its running on AWS try hitting these examples:
