Server Side Request Forgery (SSRF) is considered slightly unknown attack, and most people confuse how the attack actually works. This post will clear the basic working of the attack along with a practical demonstration.
SSRF refers to an attack scenario against a vulnerable web application exploited by sending a maliciously crafted request. The malicious request, in this case, will target an internal system protected possibly by firewalls, IDS/IPS, etc, and thus is inaccessible from the external network.
Let’s take a moment to understand where the vulnerability resides. It is common for any online application to include external resources for its functioning. For example, to share this post on Twitter, for example, Twitter server would need to make a request to this page in order to extract all the information it needs, like the images and description. The vulnerability lies in this link expansion and Twitter, too, was vulnerable to SSRF until recently.
As I’ve already mentioned, SSRF attacks target internal protected systems that would not be accessible to an attacker through external network. Additionally, an attacker can also leverage SSRF attack to access services from the victim server itself that is listening on the loopback interface (127.0.0.1)
The following section would describe the attack scenario step-by-step.
Attack Scenario
The goal is to reach the internal server, and since the attacker cannot send requests to it directly, to scan the internal network, the attacker has to go through the following steps:
Figure 1
Types of SSRF
1. Direct SSRF
There are a couple of ways, that fall under Direct SSRF category, which can be used to confirm whether an attack has taken place.
The first one, Content based SSRF, as the name suggests, shows the content of the specified URL in the server’s response.
The second way is Boolean based SSRF, which contains just the HTTP status code. In case the specified URL is unreachable, the response would be a status code like 404 or 500 specifying that the request was invalid.
Thus, attackers can use these methods to confirm whether server has visited the specified address.
2. Indirect SSRF
The above mentioned ways are helpful, but there are cases when no status code, or content is returned to identify if the host is up.
For such scenarios, an indirect SSRF type called Blind SSRFis used. We use the time difference between the the possible cases to identify whether host is up. If the server takes too much time to respond, we can conclude that the host is not up. This is because, in this case, the server makes multiple attempts to reach the host, thus delay in time.
It is relatively much more difficult to exploit, since there is no response to check if payload is sent successfully.
Exploitation
I will be using bWAPP Vulnerable application to demonstrate this exploit.
To view steps to download and install bWAPP, you can search online or refer to this blog below:
Windows: https://dunnesec.com/2014/10/01/bwapp-bee-bug-installation/
Linux: http://lgogua.blogspot.com/2014/03/bwapp-pentest-lab-installation-on-kali.html
After successful installation, you’ll find a web application as shown below
Figure 2
Step 1 : Let’s browse to SSRF by choosing it from the drop-down list in the portal above.
Figure 3
Step 2: The page specifies three ways to exploit SSRF. The first one seems basic and is the right one start practicing SSRF exploit. “Port Scanhosts on the internal network using RFI”
So, we’ll browse to the “Local and Remote File Inclusion (LFI/RFI) page from the portal
Figure 4
A language parameter appears in the URL after selection a language from the drop-down list. This seems like a good user input to manipulate the URL.
Step 3 : Let’s test if the language parameter allows us to perform an SSRF exploit.
Enter the following value in the language parameter : “http://www.google.com”
Figure 5
It worked! We were able to get the vulnerable bWAPP server to fetch the requested web page. Thus, we can conclude that the application is vulnerable to SSRF attack.
Step 4 : Now, we’ll try to perform a port scan on the internal network hosting the web application
http://localhost/bWAPP/rlfi.php?language=http://localhost&action=go
Figure 6
bWAPP directly gave us response for multiple ports, but another way, since most websites won’t give a response like this, is to try accessing each port and checking the response.
Here, you can make use of the three different ways we discussed earlier to check if application is vulnerable.
So, if you get a different response content, or HTTP status code, or time for the response of a particular port as compared to the response for other ports, it’s a good indication that the particular port is open.
Impact
A successful SSRF exploitation attack can let the attacker do the following:
- Abuse the trust relationship between the vulnerable server and others.
- Bypass IP whitelisting.
- Extract information not accessible to the public, such as trace.axd in ASP.NET or metadata.
- APIs in an AWS environment.
- Scan the internal network to which the server is connected to.
- Extract sensitive information such as an internal IP address of a web server behind a reverse proxy
Remediations
- Response handling
One way is to check the response before sending it to the attacker and filter out any data that is not expected by the server to be sent to the attacker.Only limited necessary content should be allowed in response body to prevent leakage of data.
- Disable unused URL schemas
Disabling URL schemas will help prevent the use of potentially dangerous URL schemas like “ftp://” or “file://” which can be exploited by an attacker.
For example, if an application requires only HTTPS to make requests, restrict the application to use only that URL schema and disable all others.
- Whitelists and DNS resolution
Lastly, one of the most robust way, to prevent Server Side Request Forgery attack is to whitelist only those DNS names or IP addresses that the application requires access to.
In cases where this is not possible, a blacklist approach can be used, provided user input validation is implemented properly.
Article Link: https://blog.lucideus.com/2019/03/what-is-server-side-request-forgery.html