BUT FIRST WHAT IS SSRF ?
Understanding Server-Side Request Forgery (SSRF) : Server-Side Request Forgery (SSRF) is a type of web vulnerability where an attacker tricks a website into making requests on their behalf.
Here’s an analogy to help understand SSRF: Think of the website as a person who can fetch things for you (i.e. web server). They have a list of approved places they can go to and bring back information. However, with SSRF, the attacker tricks this person( i.e. web server) into going to a different place(i.e. Backend server) without their knowledge. The attacker might give them a misleading or malicious URL that points to a sensitive internal resource or a different website altogether.
EXPLAINING ABOVE ANALOGY
The person goes to the URL provided by the attacker, thinking it’s a legitimate request. But behind the scenes, the attacker may be accessing private information, like internal databases, sensitive files, or even other websites that the person’s computer can reach. This can lead to unauthorized access, data leaks, or even attacks against other systems.
In summary, SSRF is a vulnerability where attackers trick a website into making requests on their behalf, potentially accessing sensitive information or launching attacks.
The SSRF and IMDSv1 Connection :
The connection between SSRF and IMDS lies in the fact that attackers can exploit SSRF vulnerabilities to access and abuse the IMDS service. Check this to understand more about IMDS.
Problem #1:
Weak Authentication: Authentication is like a lock on a door that ensures only authorized individuals can gain access. IMDsv1 lacked a strong authentication mechanism, meaning it relied solely on the fact that requests were coming from the cloud instance itself. It’s like a door that opens just because someone says they’re allowed, without checking their credentials. This made it easier for attackers to exploit a security vulnerability called SSRF, tricking IMDsv1 into providing sensitive information.
Problem #2:
Unrestricted Access to Sensitive Data: Imagine you have a personal diary with all your private thoughts and secrets. Now, picture if anyone could simply open it and read everything inside without any restrictions. That’s what happened with IMDsv1. It allowed attackers to access sensitive data, including temporary security credentials, which are like powerful keys that grant access to important resources
Example :
If there is a web server running on EC2 instance. This web server has a simple SSRF vulnerability, allowing us to make GET requests to arbitrary addresses. We can leverage this to make a request to http://169.254.169.254 via bypassing some factors.
To view all categories of metadata from within a running instance, you need to access the following :
http://169.254.169.254/latest/meta-data/
To determine if the EC2 instance has an IAM role associated with it, look for
http://169.254.169.254/latest/meta-data/iam/
response 404 indicates there is no IAM role associated.
If there is a valid role you can steal, make a request to :
http://169.254.169.254/latest/meta-data/iam/security-credentials/
This will return the name of the IAM role the credentials represent. Suppose the role name returned is ‘xxxx-role’.
To steal the credentials, append the role name(i.e. xxxx-role) to your previous query. For example, we’d query
http://169.254.169.254/latest/meta-data/iam/security-credentials/xxxx-role/.
AND BOOM 💥💥 !!!! , it will expose private creds, that should only be known to authorized individuals. This unrestricted access gave attackers a way to infiltrate the cloud environment and potentially cause more harm.
CONCLUSION:
While IMDsv1 served its purpose of providing important information to cloud instances, it had vulnerabilities that made it susceptible to exploitation. Weak authentication and unrestricted access to sensitive data were the primary concerns.
ENDING NOTE:
If you found this blog helpful in understanding the relationship between SSRF and IMDS vulnerabilities, please consider connecting with me on LinkedIn or Twitter. I would love to hear your feedback and engage in discussions about cloud security and best practices. Together, we can create a safer and more secure digital landscape.
Next time, we’ll talk about Protecting Against IMDsv1 Vulnerabilities.
Top comments (0)