(Portswigger/WebAcademy) - Server-side request forgery (SSRF)

Intro

This post/writeup is all about the Server-side request forgery (SSRF).

I’ll be using primarily Portswigger Web Academy Labs, but i do intent do throw other labs and writeups here as well.

TOC

• Intro
  • TOC
• Basic SSRF against the local server
• Basic SSRF against another back-end system
• SSRF with blacklist-based input filter
• SSRF with whitelist-based input filter
• SSRF with filter bypass via open redirection vulnerability
• Blind SSRF with out-of-band detection
• Blind SSRF with Shellshock exploitation
• SSRF via flawed request parsing

Basic SSRF against the local server

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

We can notice that we can check the stock of any product.

As it can be seen above, it seems like a normal response, however let’s check how this looks like in Burp.

We can see that we have URL in the POST body and response that corresponds with the one seen on the webpage, but it looks like we can trigger request to any url from the client, so let us do exactly that.

As seen above, our request does show contents of the /admin page and the path to delete the carlos user in order to solve the lab is served on a silver plate ==> /admin/delete?username=carlos

Basic SSRF against another back-end system

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.

We have same “Check stock” option, same is in the previous exercise:

Vulnerability also appears to be the same, we just now don’t know on which IP the admin interface resides. This is something where Burp Intruder might help us find that out.

Use Numbers as a payload set.

I’ve got a hit at .189:

Now delete carlos in order to solve the lab /admin/delete?username=carlos

SSRF with blacklist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

Like the previous lab, start the burp in the background and check the stock as in previous labs.

We can enter http://127.1 and observe that side will get loaded

If we add http://127.1/admin, we would see a "External stock check blocked for security reasons" Error, so admin appears to be on a blacklist.

Double encoding does the job.

In order to solve the lab, following request was issued

stockApi=http%3a//127.1/%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65/delete?username=carlos

SSRF with whitelist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed an anti-SSRF defense you will need to bypass.

In this lab, we again have to exploit the Check Stock function.

Let’s do that and observe the request in Burp.

Send the request to repeater and try some payload like http://127.0.0.1:

So we need to keep stock.weliketoshop.net in the SSRF Request.

Adding a parameter or puting the stock.weliketoshop.net after # did not work.

• stockApi=http://e@stock.weliketoshop.net = WORKS

• http://127.0.0.1e@stock.weliketoshop.net still WORKS

• stockApi=http://127.0.0.1%25%32%33@stock.weliketoshop.net WORKS where %25%32%33 is just double-encoded #
• stockApi=http://127.0.0.1%25%32%33@stock.weliketoshop.net/admin WORKS

Now it should be self-explainatory what to do to delete carlos.

SSRF with filter bypass via open redirection vulnerability

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.

The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.

Just like before, start the lab, choose a product, click on Check stock while having Burp open in the background. Let’s examine the request:

While checking the application following comes up

/product/nextProduct?currentProductId=1&path=/product?productId=2 

We’ve gotten into the admin portal! Can we delete carlos?

Yes we can!

Blind SSRF with out-of-band detection

This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.

To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.

This lab reacts with an server-side request forgery when we put out URL to the Referrer header.

Blind SSRF with Shellshock exploitation

Collaborator is needed which is why this lab will be done later at some point

SSRF via flawed request parsing

This lab is vulnerable to routing-based SSRF due to its flawed parsing of the request’s intended host. You can exploit this to access an insecure intranet admin panel located at an internal IP address. To solve the lab, access the internal admin panel located in the 192.168.0.0/24 range, then delete the user carlos.

There isn’t much going on on the page, but as the title suggests it has something to do with how request is being parsed, and indeed, if we swap the host header and use the collaborators URL as path we get a callback (note the string in response which usually comes from collaborator):

Now our job is simple, we just need an intruder to bruteforce the last octet in the 192.168.0.0/24.

When we’ve found the IP we can append /admin to the request and grab the form in order to delete carlos user.

Carlos has been deleted and lab has been solved.