Introduction
This is the first post within the category: “Theoretical Practise”. In these series I will use information available in the Internet to build a working Proof of Concept and to test dangerous functions in different languages with the objective to understand basic Web Exploitation vectors. In this chapter, I have built a Proof of Concept in relation to the exploitation of Command Injection and Argument Injection, using PHP language. Existent PoC can be (found or obtained) here
Command Injection VS Argument Injection
Since this is the first post in which I talk about these two vulnerabilities, let me explain in a nutshell how they work. Command Injection occurs when we provide to any kind of command interpreter as sh/bash/cmd a string directly coming from an uncontrolled user input. An example of vulnerable code is detailed as follows:
Our PHP cheat sheet aims to help anyone trying to get proficient in or improve their knowledge of PHP. The programming language is among the most popular in web development. It’s in the heart of WordPress, the world’s most popular CMS, and also forms the base of other platforms like Joomla and Drupal. To avoid code injection, we recommend that you disable exec, shellexec, passthru, and system functions in PHP configuration unless it is absolutely necessary to use them. You can also create a whitelist of accepted commands/arguments. Read more PHP security tips. Use builtin APIs instead of OS commands. As we noticed in the earlier articles, Command injection occurs due to the fact that code is written to execute OS commands and an attacker can manipulate this behaviour to execute more commands than what the system is intended for. Types of Injection and their CHEAT SHEET Xpath Injection: XPath injection is an attack targeting Web sites that create XPath queries from user-supplied data. If an application embeds unprotected data into an XPath query, the query can be altered so that it is no longer parsed in the manner originally intended. It's been a few months since my last article, but here is my follow up post describing how to defend against Command Injection. We know that this vulnerability is a result of poor coding practices. In order to prevent system commands being passed from the web application to the operating system we can implement a few things: input validation.
In these functions, if the user can control the $userInput string used by any of these functions, he or she could perform an a Command Injection attack as follows:
On the other hand, an Argument Injection is different; it is triggered when an attacker injects arguments/parameters to the Executable called by these functions. This situation happens when the user input is being filtered to escape only shell special characters,or is not possible to inject them, but the injection of spaces is totally possible. By using spaces, an attacker can forge a malicious string that adds arguments, parameters, or new options to the target executable, effectively amending its behaviour.
In an Argument Injection, the ability to exploit the vulnerability depends on the nature of the target executable. The capability to create a successful attack vector will depend on our knowledge of possible parameters/configurations of it. As a last resource, an attacker/we could try to create a low-level exploit in case the executable is a C binary, or to concatenate other vulnerabilies if it is a script. It all depends how deep into the rabbit hole the attacker is willing to go to exploit it.
The following bash script shows a useful way to debug Argument Injection attaks when the executable that is being employed is known / has been identified:
This will help us understand what is being passed from the side of the web app to the operating system executable. Later on we will use it to show how this PoC works.
Proof of concept: Command Injection
The following PoC consists in a simple PHP web application that uses dangerous functions to perform a call to the sendmail/exim4 executable. The Command Injection takes place into the $emailFrom variable as the user input is not properly sanitized
The way to test this Command Injection is very simple; we just provide the previous payloads in the “emailFrom” input and click Command Injection. By accessing to /var/log/apache2/access.log in the target PoC server, we can see that the “wget” command is being performed correctly.
In this example anything was escaped,so the payloads were obvious. Sometimes developers will try to mitigate these vulnerabilities by creating their own escaping functions. This usually introduces new errors that can be further exploited, so trying different payloads is always recommended.
Creativity and knowledge of the sh/bash/cmd software and Operating System will allow attackers to use complex attack vectors to exploit Command Injections. A good example of this was the famous bug CVE-2014-6271 ShellShock. In this case, the injection took place into system environment variables which were supposed to be safe, but this last bug made it critical in some CGI servers.
Proof of concept: Argument Injection
In the second option of the PoC we use a function accessible by PHP to escape possible dangerous shell characters that would allow an attacker to concatenate commands. The used code is as follows:
This function will escape symbols as “;|{} …”. But this php function will not escape spaces, the injection of them will be the key to exploiting the Argument Injection. As I mentioned before, by analyzing the used executable, we are able to obtain an exploitation vector. The target executable is “sendmail”, which in most of Unix OS is a soft link to the target binary to study: “exim4”. Legal hackers has performed an outstanding study of it with, making his exploitation possible: PHPMAILER CVE-2016-10033
Coming from the link above, “exim4” has an argument “-be” that grants us access to run shell commands in the operating system. Basically, it is possible to run something like this in bash to test the functionality:
So at first instance, we would think that a payload like the following would easily to the job:
Unfortunately, this is not going to work. To easily figure out what is going on, we need to use the little bash script we mention before (commanddebugger inside the PoC) and configure the server where the PoC is running as follows:
If we run again the previous payload, we can see at /tmp/outgoing-command in the following:
This is thanks to escapeshellcmd() escaping every forbidden character inside closed quotes. If we try to use the same payload without quotes we will encounter another problem:
The space that let us performing the Argument Injection now is backfiring our ability to exploit it. An awesome study by Legal Hackers about the target binary properties let us know that we can exploit the use of characters inside environmental variables strings of exim4 (more details in the previous link).
Finally we achieve a successful Argument Injection exploitation.
Proof of concept: 99% safe?
In the last part of this PoC we use the right escape function to avoid the exploitation of these dangerous functions: escapeshellarg(). Add single quotes around the string so that neither spaces or any special bash symbols are interpreted by shell/bash.
As we can see spaces are no longer effective; we can trust that our dangerous functions are as secure as possible.
Command Injection Cheat Sheet
Conclusions
Php Cheat Sheet Pdf
In an attacker perspective, if we see data that could be passed as a string to a dangerous function like the following URL:
Php Commands
We should try a series of command Injection Payloads for a linux/windows based operating system and check if our external server has been reached. Argument Injection is much trickier. For that, we will need to figure out vulnerable 3PP (third party library software) used by the target web application.
From a defensive point of view, it is critical to escape any input that goes into dangerous functions. Defender should avoid abusing these functions to perform the application logic, but if he uses it, he should be very careful. The Dangerous Functions that I know so far will be listed here
References