Command Injection

• Detecting command injection vulnerabilities follows the same process as detecting other injection vulnerabilities: try injecting commands into relevant input fields and check for different responses.

• Most applications apply a blacklist for input sanitization. The newline operator often isn't blacklisted, but identifying the applied sanitization controls requires manual testing to effectively mitigate it.

Example Bypassing Techniques

• Whitespace blacklisting can be bypassed by using tabs instead of spaces. In Linux, you can also use ${IFS} to bypass whitespace blacklisting, as the default value for this variable is a space. Another technique is using bash brace expansion (e.g., {Command1,Argument}) to automatically separate commands.

• In many applications, / is blacklisted. In Linux, this can be bypassed using environment variables. For example, ${PATH:0:1} gives /, and ${LS_COLORS:10:1} gives ;. You can try running printenv to display the environment variables. In Windows, similar methods apply with different environment variables; for example, $env:HOMEPATH[0] gives /, and Get-ChildItem Env: can be used to print the environment variables with the equivalent for Linux being, printenv.

• Some applications might blacklist specific words as a sanitization technique. To bypass this, you can use single or double quotation marks between the letters, but ensure that the number of quotes is even and that you don't mix single and double quotes—it's either one or the other. This works for both operating systems. In Linux, characters like $@ and \ can be used, while in Windows, the ^ character can be used.

• Another command obfuscation technique is case manipulation, which works in Windows because it's case-insensitive. You can also use this in Linux by using a command that transforms the case-manipulated text to normal lowercase (e.g., $(tr "[A-Z]" "[a-z]"<<<"WhOaMi") or $(a="WhOaMi";printf %s "${a,,}")). One more method is using reversed commands and then reversing them again (e.g., $(rev<<<'imaohw') for Linux, and in Windows: iex "$('imaohw'[-1..-20] -join '')").

• One more method is using reversed commands and then reversing them again (e.g., $(rev<<<'imaohw') for Linux, and in Windows: iex "$('imaohw'[-1..-20] -join '')").

• Another technique involves encoding commands. For example, echo -n 'cat /etc/passwd | grep 33' | base64 to get the base64 output and then reconvert it: bash<<<$(base64 -d<<<Base64). The Windows equivalent: iex "$([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('Base64')))".

• For automation, Linux users can use Bashfuscator to obfuscate commands, while Windows users can use DOSfuscation.

• Injection Operators:

Injection Character	Executed Command
;	Both
\n	Both
&	Both (second output generally shown first)
|	Both (only second output is shown)
&&	Both (only if first succeeds)
||	Second (only if first fails)
''	Both (Linux-only)
$()	Both (Linux-only)

Securing Against Command Injection

• To secure against command injection, avoid using functions that execute system commands, especially when user input is involved. Instead, use built-in functions that perform the needed functionality, as back-end languages usually have secure implementations for these tasks. Whether using built-in functions or system command execution functions, always validate and sanitize user input.

• Since front-end validation can be easily bypassed, input validation should be done on both the front-end and back-end. Use regex if there's no prebuilt function for validating the expected input.

• After input validation, input sanitization (removing any unnecessary special characters from user input) should always be performed. In cases where all special characters need to be allowed (e.g., user comments), you can use the same function used for input validation and apply a function like, escapeshellcmd to escape any special characters, preventing injections.

• Finally, ensure that your back-end server is securely configured to minimize the impact if the web server is compromised. This includes enforcing least privilege, limiting visibility/accessibility for the web server account, etc.