Introduction to SSRF Exploitation: A Practical Tutorial for Ethical Hackers

Server-side request forgery (SSRF) is a type of web application vulnerability that allows an attacker to send a crafted request from a vulnerable web application to an arbitrary destination. This can include internal systems, such as a database server or a file server.

The vulnerability occurs when the web application takes an unsanitized user-supplied input and uses it to build a request.
In this way is possible to craft a malicious request and force the vulnerable server to send it.

For example, imagine a web application that:

• takes a URL as an input
• displays the content of the associated web page.

Suppose the web application does not properly validate or sanitize the user input. In that case, an attacker could enter a URL that points to an internal system and then retrieve sensitive information.

What is the difference between CSRF and SSRF?

It often turns out that the difference between SSRF and CSRF is not clear enough. However, in this paragraph, I will do my best to make it as plain as possible.
Let’s waste no more time and see how the two vulnerabilities in question differ and what are their impacts.

CSRF allows an attacker to send a malicious request to a web application on behalf of a victim. And the attacker typically follows the steps :

• Tricks the victim into clicking a link or loading a malicious website that sends the request.
• That request contains the victim’s authentication credentials, so the target web application treats it as if it came from the victim.
• This can allow the attacker to perform actions on the web application as if he were the victim, such as:
  • Changing passwords
  • Making unauthorized purchases.
  • Post something on the victim’s socials.

SSRF, on the other hand, is a vulnerability that allows an attacker to send a request from a vulnerable web application to an arbitrary destination. This can include internal systems that are not normally accessible from the internet. The vulnerability occurs when the web application takes a plain user’s input to construct a request to another server or service.

SSRF VS CSRF in a nutshell:

Just to further clarify the difference:

• CSRF: the target is a user/client and he has to perform some actions, to become a victim. The vulnerability does not depend directly on him, but on the server hosting a potentially vulnerable application.
• SSRF: a hacker can use the application itself to send malicious requests from a trusted domain. In this case, the vulnerability does not depend on external factors but directly on the application’s code.

What are the few preventive measures against SSRF attacks?

Once we’ve seen how the vulnerability works, maybe you want to know how to prevent it.
There are several preventive measures that can be taken to protect against Server-Side Request Forgery (SSRF) attacks:

1. Input validation and sanitization: Ensure that all user-supplied input is properly validated and sanitized before using it to construct a request.
2. Limit the scope of requests: Limit the scope of requests that the web application can make to internal systems and services. For example by limiting the IP addresses or domain names that the application can connect to.
3. Network monitoring: Monitor network traffic to detect and block suspicious activity. This can include monitoring for unexpected connections to internal systems, or for large volumes of requests to a single destination.
4. Use of security scanner: Use a security scanner to identify the vulnerability and penetration test the web application to identify the vulnerability and fix them.
5. Provide training for developers: Provide training for developers to ensure that they understand the risks associated with SSRF and know how to properly validate and sanitize user-supplied input.

It’s important to note that SSRF is a complex vulnerability that can be difficult to detect and prevent.
So an IT worker has to stay up-to-date with the latest security practices and tools to protect against these types of attacks.

Server-Side Request Forgery attack by example

In this short hands-on, we will perform a very simple exploit on a badly coded server. This is not a real situation but can help a lot to understand the vulnerability.

What I’m going to do is prepare our Kali Machine in VirtualBox in a way that we have two servers running:

• The first one is the vulnerable application (inside the project’s main directory).
• The second one is a server that shows the content of a secret directory and is only visible from localhost (runs inside a secret directory).

Now let’s create our directories and create the following structure in your lab:

If you have doubts you can find the whole code in the GitHub repository.

The SSRF-vulnerable server

Before writing the code of the vulnerable server we need the IP address, so let’s type on a terminal:

ifconfig

After taking the IP we can write the code of a vulnerable application.
For example, if it was 192.168.1.116 this will be the related code to run a server in LAN on port 8000.

from flask import Flask, request
import requests


app = Flask(__name__)

my_ip = '192.168.1.116'

@app.route("/")
def index():
    url = request.args.get("url")
    response = requests.get(url)
    return response.text


if __name__ == "__main__":
    app.run(host=my_ip, port=8000)

Let’s comment a bit on this code, even if it’s self-explanatory.

This application has a single endpoint that takes a URL as a query parameter and makes a GET request to that URL using the requests library. The response from the request is then returned to the user.

In this way, we can force the webserver to show us what it can see, even if we don’t have the rights.

We can run the application by typing in our terminal:

python vulnerable_application.py

If you don’t have flask installed, you should do it with the command:

pip install flask

The vulnerability in this application is that it allows an attacker to craft a URL that points to an internal service but let’s see how to do it.

The Internal Service

I want to make this introduction as simple as possible, so to run an internal service I’m going to use a python internal module: http.server.
We want to run it on localhost on port 8888:

1. Open a terminal or command prompt.
2. Navigate to the directory “supersecretdir” that contains the flag.
3. Type the following command to start the server:

python -m http.server 8888

Exploit SSRF

It’s time to exploit, and if everything is clear, you could do it autonomously. However, I’m going to show the steps:

• Move on your host machine
• Open the browser
• Try to connect to this URL: http://192.168.1.116:8000?url=http://localhost:8888

And that’s what we get!

So we got access to an internal server that we couldn’t normally access!
As we expected the exploit is working fine!

Conclusion

We have seen just a simple proof of concept even though in real-world scenarios, the vulnerability could be more complex to exploit and prevent. However, I hope this article has been interesting and has provided value to those looking to learn more about Server Side Request Forgery (SSRF).

With the increasing prevalence of web applications and cloud infrastructure, it is more important than ever to be aware of the potential security vulnerabilities posed by SSRF attacks. By understanding the basics of SSRF, its impact, and how to prevent it, we can better protect our systems and data from malicious actors. Remember, prevention is always better than reaction, and by taking proactive steps towards securing our web applications, we can avoid potentially disastrous consequences down the line.

If you found this article informative, then I invite you to follow my blog for more insights on cybersecurity.
Stay up-to-date on the latest trends and techniques to protect your systems from potential threats. Don’t hesitate to leave a comment or share this article with others who may find it useful.
Thank you for reading and we look forward to seeing you on the blog!