Command execution is a vulnerability in which an attacker is able to execute arbitrary system commands. They type of attack is particularly dangerous as it exposes the base operating system rather than just the web application itself. So, how exactly does command execution work? Let me give an example.
Lets say you’re on a website, this website will compress a folder of images into a single .zip file. Pretty handy right! Well, rather than just use this website an attacker may begin to wonder how exactly these zip files are being created. On certain operating systems .zip files can be created using the zip command, this command will take a few options or arguments as they’re known and produce a .zip file, this is essentially a compressed folder that keeps all your files together. So lets take a look at how this zip command would look to an operating system.
zip -r outputfile.zip files_to_compress/So what’s happening here? Well, the web application is specifying that it’ll be using the zip program. Then its saying it will recursively -r compress all files in the later specified folder. Next it’s instructed what the final file will be called, in this case outputfile.zip and finally its specifying where all the soon to be compressed files are located. In this instance file_to_compress/. So, how is this vulnerable? Well what would happen if an attacker were to inject another command rather than the specified final file. Let me give an example below.
outputfile.zip files_to_compress/; whoami #Rather than specify outputfile.zip the attack could enter the command you see above, in this instances it would simply output the current user of the operating system however it could be far more severe. So, how does this work? For our filename we have completed the zip program requirements. From there we have added ; to state we’re moving onto our next command and finally we’ve added whoami #. The whoami command is a system command for determining what user is running on the operating system at that time and the # symbol is simply for commenting out the remainder of the original zip command.
Here’s how that full command would look to the operating system.
zip -r outputfile.zip files_to_compress/; whoami # outputfile.zip files_to_compress/Assuming the web application outputs the operating system response then the malicious user would be able to see the output of the whoami command.
Preventing command execution
There are a number of ways in which you may prevent command execution, to keep it simple we’ll simply refer to the examples above.The vulnerable part of the whole web application is the output filename, if we simply restrict the characters which can be used in filename then the command execution can never occur. Lets say, we only allow the following characters a-z A-Z 0-9 . . Since none of these characters can be used to complete the zip command then it will just use this for a name, no matter how obscure it seems. This approach is called a whitelist.
Another approach you could take would be to use a blacklist, this is essentially the opposite of the example above as you have to specify every character that’s banned rather than just the simple few that are allowed.
What can be achieved with command execution
With command execution attackers almost have free reign of the target operating system (depending on the current user privileges), the attacker may try to escalate privileges and become root or admin. They may try and move laterally and take over another account or system on the network. Should an attacker wish they may even have the ability to inject a shell meaning they’d be able to access your system through a backdoor anytime they wish, this is essentially a worst case scenario.
