Writeup — Basic SSRF Against Another Back-End System

This lab discusses a Server-Side Request Forgery (SSRF) vulnerability that allows an attacker to use the application server to access internal systems that cannot be reached directly from the outside network. In this scenario, the product stock check feature uses a URL that is controlled by the user. The server then accesses this URL to fetch stock information from a back-end system.

The goal of this lab is to use the SSRF vulnerability to scan the internal network (192.168.0.X), find the administrator interface running on port 8080, and use that access to delete the user 'carlos'.

I started by visiting one of the product pages and clicking the "Check stock" button. I intercepted the request sent by the application using Burp Suite and forwarded it to Intruder for further analysis.

Inside this request, I noticed a stockApi parameter containing the destination URL that the server would access. This parameter became my main target because the server uses its value directly to make requests to the back-end system.

Once the request was in Intruder, I changed the value of the stockApi parameter to:

http://192.168.0.1:8080/admin

http://192.168.0.1:8080/admin

Next, I highlighted the last octet of the IP address (the 1) and added an Intruder payload marker. By doing this, I could automatically change the last part of the IP address to scan the entire internal network range.

The goal of this step was to find the internal host that had an active administrator page on port 8080.

In the Payloads tab, I selected the "Numbers" payload type and configured it to:

From : 1
To   : 255
Step : 1

From : 1
To   : 255
Step : 1

This configuration made Burp Intruder send requests to every single address from:

192.168.0.1
192.168.0.2
192.168.0.3
...
192.168.0.255

192.168.0.1
192.168.0.2
192.168.0.3
...
192.168.0.255

Each request used the application server as a middleman to access these internal addresses through SSRF.

After the automated attack finished, I sorted the results by the Status column. Out of all the responses, there was only one host that returned a 200 OK status.

This status indicated that this specific IP address (in my case, 192.168.0.153) had an accessible administrator page. I selected that request and sent it to the Repeater for a closer look.

Looking at the response, I could see the actual contents of the administrator page. After checking the returned HTML, I found the endpoint used to delete a user:

/admin/delete?username=carlos

/admin/delete?username=carlos

This showed that the administrator panel had an account deletion function accessible through that specific URL.

To finish the exploit, I modified the stockApi parameter to point directly to that user deletion endpoint :

http://192.168.0.153:8080/admin/delete?username=carlos

http://192.168.0.153:8080/admin/delete?username=carlos

by replacing the IP with the internal one I just found

When I sent the request, the application server reached out to the internal system and ran the user deletion function on its own behalf.

The exploit was successful, and the user 'carlos' was deleted from the system! This proves that the stockApi parameter is highly vulnerable to SSRF and can be used to reach internal services that should be completely hidden from external users.

A Quick Breakdown Uhuk!!

This SSRF vulnerability allowed me to use the application server as a proxy to access the internal network. By enumerating the IP range 192.168.0.x, I successfully found the hidden administrator interface running on port 8080. Once I gained access to that page, I was able to run an administrative function to delete the user 'carlos' and complete the lab.