Searching for Command Injection

Manual Static Code Analysis Methodologies

It’s not uncommon for pentesters to gain access to application source code; either via white-card or exploiting an arbitrary file read vulnerability.  Ideally, commercial static code analysis tools can be deployed against the code to expeditiously identify potential vulnerabilities. This option is however often financially infeasible; the cost of software licenses and setup time can be prohibitive.  Simple OS search utilities (grep/findstr) can be used in lieu of costly commercial products to help hunt for a way to breach the application’s defenses.

The methodologies that detailed below will explain how to search for a command injection using nothing more than OS utilities.

Step One – Dangerous API:

Research applicable coding languages to identify common methods for executing an OS command.  Each language has one or two really common methods for instantiating an command to the operating system; e.g. java.lang.Runtime.exec or System.Diagnostics.Process.Start.

Java: exec
C/C++: system, exec, ShellExecute, start
Python: exec, eval, system, popen, call
PHP: system, shell_exec, exec, proc_open, eval
ActionScript: fscommand

Search the codebase (findstr or grep) to identify all the places where these methods are being used.  For each instance, review surrounding code logic and determine if the relevant variables can be influenced by input from the user.  If so, you may have identified a successful command injection.

Step Two – Arbitrary File Upload:

If you can’t find a pre-existing command injection vulnerability, then create one.  This can be accomplished by identifying an arbitrary file upload vulnerability within the codebase and uploading a custom webshell.

Programming languages usually have multiple methods for writing data to the file system.  Research the applicable language’s methods to write to the file system. Key phrases will often include “save”, “write”, “copy”, or  “upload”. Ideally, code logic surrounding these phrases will highlight a method to craft your malicious file in an executable directory.  

Ethical Hackers BEWARE!  Remember that you are introducing a vulnerability into the system by uploading a webshell.  Take all necessary protective measures to defend the webshell from being exploited by malicious users.  Minimum safeguards should include restricting access to the webshell via IP and using username/password authentication.  Further safeguards may be necessary based on customer requirements.

Step Three – SQL Injection:

The impact of a SQLI on the system is ultimately controlled by two factors: the skill of the hacker and the attentiveness of the target system’s DBA.  A properly configured database will lessen the impact of a SQLI. Whereas, a poorly configured database could allow an attacker to translate a simple SQLI into arbitrary OS commands; commonly stemming from either stored procedures or writing a malicious file to the system.

Its common for SQLI vulnerable code logic to utilize string concatenation in close proximity to sql commands.  Searching for this signature within source code is best done by combining multiple search commands. The example snippet below uses grep to (1) retrieve all code files with references to “sql”, (2) grabs several lines of code surrounding any query logic, (3) and then prints lines with logic that involves concatenation.  Ultimately, the analysts will need to assess the returned values and open a subset of the files to identify a valid/exploitable SQLI.

Automated tools are available to help exploit a SQLI after its been identified; such as Nmap.  Deploying these pentesting tools against a live system is definitely risky. A desire to not impede system dependability/integrity leads most pentesters to prefer manually exploiting these vulnerabilities against production systems.

Step Three – Tertiary Triggers:

It’s time to get creative if all the above methods have failed to yield command execution.  In short, look for methods to attack the application’s trust boundary.

Applications often retrieve and utilize data from within server-side trusted locations.  These data repositories include environment variables, session memory, and databases. Identifying methods to poison data residing within these trusted zones could also yield command injection.  For example, corrupting the $PATH environment variable could result in the server launching files that have been uploaded in untrusted directories. Burrow into all code that touches trusted zones to determine if a similar attack vector is possible.

The above script attempts to filter relevant code logic by finding method calls that interact with the session/environment variables.  The script also performs applies rudimentary filter to ignore code logic that levies static string values; strings provided by the developer.