I had a recent spell with OS Command Injection that left me feeling raw. Wish I could explain but sadly I can’t. I was glad to see there was some light relief in the form of Damn Vulnerable Web App. OS Command Injection all set up ready and waiting to play with.
I do remember about 6 months ago looking at DVWA Command Injection and embarrassingly not being able to do it. To be fair, I didn’t make any effort to look it up or review the source code. I hadn’t come across it. This industry has a funny way of showing you things you sidelined.
Security Level: Low
DVWA comes out of the box set to ‘Impossible’ security. Yeah ok, let’s get it changed.
On entering the Command Injection link on DVWA you are given the option to ping a device. For this purposes of speed, I just pinged localhost.
Entering the localhost IP into the box returns what you might expect.
In the bottom right of the screen you have the option reviewing the source PHP code of the web application.
On reviewing the code the web app on the ‘low’ setting;
- Takes in the requesting IP and passes it to the variable ‘$target’
- Determines the OS type
- Executes a direct command on the Operating System using PHP Shell_Exec
There is no sanitisation of any inputs given to the web application. It performs a direct command to the OS via shell_exec.
Given that in any environment you can chain commands together using certain operators it’s worth a try in this instance.
Chaining commands works as it would in a linux terminal. A successful output of /etc/passwd to the web page.
How did this happen?
The web developer didn’t write any protection measures in place to prevent users from chaining commands together. Due to the direct nature of the way this web app passes commands to the OS, the OS will run anything it is given. The web app is designed to display what is displayed back in the terminal so to speak.
Security Level: Medium
Remember to set the security to ‘Medium’ before trying the next part.
There’s an assumption that the security of the web application will be tighter so it’s worth reviewing the source code before running a previously successful command.
Right away there is some differences to the code. Essentially the same as the ‘low’ setting in the way it handles the variables and passes them to the OS.
- Takes a variable and passes it to ‘$target’
- Creates an array of blacklisted characters for checking in a ‘$substitutions’ variable
- Passes the command to the OS using shell_exec removing any blacklisted characters.
The developer has only blacklisted 2 operators. Both ‘&&’ and ‘;’ do similar things. You can read about operators and their functions here
There are several other operators you can use to chain commands together in Linux.
The web application only looks for 2. You can pipe commands together too, as I have done here.
Why did this work?
The web developer did not fully sanitise all possible operators. The OS did not ping ‘127.0.0.1’ but instead ran our command ‘cat /etc/passwd’ instead. I’ll no doubt investigate why it did this, but for now it’s good that it returned what I needed.
Security Level: High
This is where it gets interesting. First off, let’s set the security level to High.
On reviewing the source PHP code the developer has taken our advice about tightening the security and has placed all known operators in their blacklist. This could prove difficult.
For now it seems that there is no way of chaining commands under these new rules.
On the bottom line the developer has blacklisted the double pipe operator ‘||’ the OR statement. In linux this character is called a metacharacter. It is not constrained by spaces on either side. The web application is strictly looking for ‘||’ with no spaces. Once this condition is true the operator will be blacklisted.
In my example inserting spaces between the pipes escapes any checks from the source code.
127.0.0.1| |cat /etc/passwd
How did this work?
Technically this should not work as it errors on a linux terminal, however, when playing around on the web app it worked everytime. I’m not happy with the discrepancies here so further investigation is needed I think, however, for the purposes of running OS Command Injection on High within DVWA it was a good exercise.
I think I’ve learned a good number of things I do wish I knew before. Working through the problem, reviewing the source code and following the code is really useful. If you can explain to yourself how the simple web app works, then you can bypass it’s security more easily.
Erm, I have reviewed the source code. This is what I know so far
- Splits up the IP address into octets
- Checks that it’s been passed an integer (a number)
- Merges the IP address before running the command.
I’m sure I’ll get to that one day. There’s a ton of other things to learn 🙂
Thanks for reading…