Server side request forgery vulnerabilities (SSRF) – (Part 1)

I. Pose the problem

1. Introduction

Server-side request forgery (commonly referred to as SSRF) is a type of attack in which an attacker exploits a feature of a public server to gain unauthorized access to data from another specified website, usually web pages. back-end on the server itself. To better understand this type of vulnerability, let’s consider the following example:

In the image above, the attacker exchanges packets with a public server, taking advantage of this server to send requests to the back-end server (intranet). Now the back-end server parses and trusts this request because it is sent from the public server, then returns the response to the public server, and the public server continues to return data to the attacker. The attack process is complete, the way it works is the same as “borrowing a murder knife”! This is also why this type of attack is called “server-side request forgery” – attackers impersonate the server to “legitimately” retrieve sensitive data!

2. Influence

Attackers often take advantage of this type of attack to fake access requests to websites that require high permissions or are not within the reach of regular users, which can be admin pages, End points are only accessible locally or contain sensitive data. From there illegally collecting data or performing destructive acts, in some cases can escalate from SSRF attack to Command Injection attack. Server-side request forgery vulnerability is ranked at number

ten ten$10$ in Top Stats

ten ten$10$ in

2021 2021$2021$

II. Analyze and exploit Server-side request forgery vulnerabilities

1. SSRF Vulnerability in Some Languages

1.1. PHP language

SSRF vulnerabilities can appear in the PHP programming language when developers do not properly use some functions that work with URLs. For example consider the following code using the file_get_contents() function:

The above code prints the web page content through the url parameter passed by the user using the file_get_contents() function. Example with url=https://google.com :

Since the site doesn’t have any SSRF protection against it, an attacker can easily access the contents of the /etc/passwd file:

Or read the content at another open port of the server – which is only accessible through the local network:

In addition, other functions such as fscokopen() , curl_exec() , … if installed carelessly, can also cause SSRF vulnerabilities, you can learn more through the documents on Google.

1.2. Python language

Consider the following Python code using the Slack library:

Due to the failure to implement SSRF vulnerability prevention for the url parameter passed by the user, a website can be subjected to an SSRF attack as follows:

2. Local server access SSRF vulnerability

Attackers often take advantage of SSRF vulnerabilities to access websites that are intended for accounts that have administrator privileges or can only be accessed from the local server side. From there it is possible to use the functions of these websites. Local servers are usually identified with a URL of the form: http://127.0.0.1 or http://localhost . Consider the following lab:

Basic SSRF lab analysis against the local server

Description: The stock check function of the website retrieves data from the intranet and returns it to the user. Here contains SSRF vulnerability. To solve the lab, we need to exploit the SSRF vulnerability to access the admin page with the address http://localhost/admin and delete the carlos user account.

The website contains the function to check the amount of stock left in stock:

Observe the request and response in Burp Suite when using this function:

The stockApi parameter passed by the POST method to the value system is a URL http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1 . This address is only accessible from the local network.

Since the system takes stockApi as a URL, we can expect the snippet here to contain an SSRF vulnerability. Do the test: Using the Burp Collaborator , replace the stockApi value with the newly generated domain:

Send request, result at client collaborator receiving interactive request – DNS lookup successful:

Proving that the stock check function can interact with any URL, it is highly likely that it contains an SSRF vulnerability. Therefore, we can exploit the admin page access vulnerability in a number of ways as follows:

• Payload
  first first$1$ : stockApi=http://localhost/admin

• Payload
  2 2$2$ : stockApi=http://127.0.0.1/admin

Finally, delete the carlos user account by going to the path /admin/delete?username=carlos

Payload: stockApi=http://127.0.0.1/admin/delete?username=carlos

Completed lab:

References

• https://portswigger.net/web-security/ssrf
• https://www.geeksforgeeks.org/server-side-request-forgery-ssrf-in-depth/
• https://owasp.org/Top10/