Command injection is a cyberattack that involves the execution of arbitrary commands on a host operating system (OS). Typically, the threat actor injects the commands by exploiting an application vulnerability, such as insufficient input validation.
Requirements:
- Systems – Different types of systems
- Programming – High programming skills
Responsibility:
In this tutorial we will use hacking techniques, with the only purpose of learning. We do not promote its use for profitable or improper purposes. We are not responsible for any damage or impairment that may be generated in the systems used. The responsibility lies entirely with the user of this tutorial.
Knowledge:
- Linux – High
- Programming – High
- Kali Linux – High
- Windows – Not applicable
- Networks – Bass
Overall Tutorial Level: High
Ideal for: Code Developers, Security Engineers, Pentesters, Security Engineers
For example, a threat actor can use insecure transmissions of user data, such as cookies and forms, to inject a command into the system shell on a web server. The attacker can then leverage the privileges of the vulnerable application to compromise the server.
Command injection takes many forms, including direct execution of shell commands, injection of malicious files into a server’s execution environment, and exploitation of vulnerabilities in configuration files such as XML external entities (XXE).
Code Injection vs. Command Injection
Code injection is a generic term for any type of attack that involves an injection of code interpreted/executed by an application. This type of attack takes advantage of mishandling of untrusted data inputs. It is made possible by the lack of proper validation of input/output data.
One of the main limitations of code injection attacks is that they are limited to the targeted application or system. If an attacker can inject PHP code into an application and execute it, the malicious code will be limited by the functionality of PHP and the permissions granted to PHP on the host machine.
Command injection usually involves executing commands in a system shell or other parts of the environment. The attacker extends the default functionality of a vulnerable application, causing it to pass commands to the system shell, without the need to inject malicious code. In many cases, command injection gives the attacker greater control over the target system.
Command injection vulnerability examples
Here are three examples of how an application vulnerability can lead to command injection attacks. These examples are based on code provided by OWASP.
Example 1: Filename as command argument
This is an example of a program that allows remote users to view the contents of a file, without being able to modify or delete it. The program runs with root privileges:
int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}Although the program is supposedly innocuous – it only allows read access to files – it allows a command injection attack. If the attacker passes, instead of a file name, a string such as:
";rm -rf /"
The system() call will fail to execute, and then the operating system will perform a recursive wipe of the root disk partition.
Example 2: Manipulation of the environment variable APPHOME
The following code fragment determines the installation directory of a given application using the $APPHOME environment variable and executes a script in that directory.
...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
…The problem is that the code does not validate the contents of the initialization script. If the attacker manages to modify the $APPHOME variable to a different path, with a malicious version of the script, this code will execute the malicious script. This constitutes a command injection attack.
Example 3: Manipulation of the $PATH variable
The following code can be used in a program that changes passwords on a server, and runs with root permissions:
system("cd /var/yp && make &> /dev/null");The problematic part of this code is the use of make. While the attacker cannot change the code itself, because it does not accept user input, he can modify the $PATH variable. This can cause the command to run in a different path controlled by the attacker. In that other folder path, the attacker can plant a malicious version of the make binary.
Since the parent program has root privileges, the malicious version of make will now run with root privileges.
The conclusion from the three examples is that any command that invokes system-level functions such as system() and exec() can lend its root privileges to other programs or commands running within them.
Command injection methods
These are some of the vulnerabilities that commonly lead to a command injection attack.
Injection of arbitrary commands
Some applications may allow users to execute arbitrary commands, and execute these commands as if they were to the underlying host.
Arbitrary file uploads
If an application allows users to upload files with arbitrary file extensions, these files could include malicious commands. On most web servers, placing such files in the web root will result in command injection.
Insecure serialization
Server-side code is typically used to deserialize user input. If deserialization is performed without proper verification, it can result in command injection.
Server-Side Template Injection (SSTI)
Many web applications use server-side templates to generate dynamic HTML responses. This makes it possible for attackers to insert malicious server-side templates. SSTI occurs when user input is embedded into a template in an insecure way, and the code is executed remotely on the server.
XML External Entity Injection (XXE)
XXE occurs in applications that use an improperly configured XML parser to parse user-controlled XML input. This vulnerability can cause exposure of sensitive data, server-side request forgery (SSRF) or denial-of-service attacks.
Command injection prevention
Below are several practices you can implement to avoid command injections:
- Prevent system calls and user input: to prevent threat actors from inserting characters into the operating system command.
- Set up input validation to prevent attacks such as XSS and SQL Injection.
- Create a whitelist of possible entries, to ensure that the system only accepts pre-approved entries.
- Use only safe APIs-when executing system commands like execFile()
- Use execFile() safely: prevent users from gaining control of the program name. You must also map user input to command arguments in a way that ensures that user input is not passed as-is to program execution.
I hope you find it helpful.
