We can hack a machine to gain access to its internal server resources with Server-Side Request Forgery. Let’s learn how.
Time for another #FromZeroToHacker challenge.
| Table of contents |
| Introduction |
| What I have learnt today? |
| Stats |
| Resources |
Introduction to SSRF
What is an SSRF?
SSRF stands for Server-Side Request Forgery, a vulnerability that allows a hacker to force the webserver to make additional and/or edited HTTP requests of the attacker’s choosing.
Types of SSRF
There are two types of SSRF: The first is a regular SSRF where the data is returned to the attacker’s screen. The second one is a Blind SSRF, where an SSRF occurs, but no information is returned to the attacker’s screen.
What’s the impact?
A successful SSRF attack can result in one or more of the following:
- Access to unauthorised areas.
- Access to customer/organisational data.
- Ability to scale to internal networks.
- Reveal authentication tokens and credentials.
SSRF examples
Here, a hacker requests data from the internal API, returning the data back to the user instead of the normal data:
Using Directory Traversal, a File Inclusion method used to request internal data from the user:
A hacker can control the payload to modify the URL with parameters to access internal information, by using the API and adding &= at the end to ignore the rest of the URL:
We can also force a webserver to request a malicious file (our file) to be executed on the server side, revealing more internal information:
Finding an SSRF
Potential SSRF vulnerabilities can be spotted in web applications in different ways. Here are four of the most common places to look at:
When a full URL is used in a parameter in the address bar
In a hidden field in a form:
A partial URL as just the hostname
The only path in the URL:
If it is a normal SSRF, everything is alright, but if we are working with a blind SSRF (Where no output is reflected back to us), we will need an external HTTP logging tool to monitor requests, such as www.requestbin.com, our own HTTP server or Burp Suite client.
Defeating common SSRF defenses
Security-aware developers that know the risks of SSRF vulnerabilities present, may implement checks in their applications to make sure the requested resource meets specific rules. They have two ways to set this: A deny list or an allow list.
Deny list
A Deny list is where all requests are accepted apart from resources specified in a list, or matching a particular pattern. A specific endpoint to restrict is the localhost, which may contain server performance data or sensitive information.
Attackers can bypass this by using alternative localhost references such as 0, 0.0.0.0, 127.1, 2130706433, 017700000001, etc.
Allow list
An allow list is where all requests are denied unless they are on a list or match a particular pattern.
An attacker can circumvent this rule by creating a subdomain on an attacker’s domain name. For example, if we are attacking https://www.website.com and the allow list says that the website has to match https://www.website.com, we can create https://www.website.com.my-domain.com.
Open redirect
If the above bypasses don’t work, there is one more trick we have as attackers: Open redirect.
An Open redirect is an endpoint on the server where a website visitor is redirected to another website address, for example, www.website.com/link?url=https://internet.com.
Imagine there was a potential SSRF vulnerability with a rule that only allows URLs beginning with www.website.com. An attacker could use the above feature to redirect the internal HTTP request to a domain of the attacker’s choice.
Summary
We have learnt a lot about SSRF vulnerabilities, including:
- What an SSRF is.
- How we can find them.
- How developers can defend against common SSRF attacks.
- How to bypass their defenses.
Stats
From 162.870th to 159.044th. Still in the top 8% in TryHackMe!
Here is also the Skill Matrix:
Resources
Path: Web Fundamentals
Introduction to Web Hacking
Other resources
www.requestbin.com
File Inclusion method
