Code Injection [CWE-94] — The Hacktivists

Code Injection weakness describes improper control of code generation.

Table of Content
1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring

1. Description
………………………………

This weakness describes a situation where the software uses untrusted input to contrast all parts of code and does not perform or incorrectly performs neutralization of special characters that might influence syntax or behavior of the code segment.

Basically, an attacker might be able to inject and execute arbitrary code within the application. The following example in PHP demonstrates the usage of the eval() function in untrusted input:

$var ="param";
$sInput = $_GET["param"];
Eval("\$var=\$sInput;");

An attacker is able to pass in the “param” parameter arbitrary PHP code, which will be executed:

http://[host]/script.php?param=1;phpinfo();

The above example demonstrates a call to the phpinfo() function. This weakness could be exploited further to execute arbitrary OS commands on the target system via system() call.

2. Potential impact
………………………………

The maximum impact of this weakness depends on software design and implementation. This weakness may allow an attacker to execute arbitrary code within the application and compromise the vulnerable system.

3. Attack patterns
………………………………

There are the following CAPEC attack patterns that correspond to this weakness:

❏ CAPEC-35: Leverage Executable Code in Nonexecutable Files
❏ CAPEC-77: Manipulating User-Controlled Variables

This weakness is not described as an attack technique in the WASC Threat Classification database.

4. Affected software
………………………………

Any software that evaluates untrusted input or uses it to construct code is potentially vulnerable to this weakness.

5. Exploitation Examples
………………………………

Let’s have a look at the HTB23070 security advisory (CVE-2012–0993).

Successful exploitation of the vulnerability requires that the “viewer_size_image” plugin is active.

To demonstrate the vulnerability, we will use a simple telnet utility to alter the HTTP query and set a specially crafted COOKIE value for the “viewer_size_image_saved” parameter, as shown in the image below:

The server will return the following data containing the output of the injected command:

The output contains details of the installed PHP version, and this means that the “phpinfo()” function is executed successfully. An attacker can execute arbitrary PHP code on the target system and gain complete control over it.

6. Severity and CVSS Scoring
……………………………………..

The severity of the vulnerability depends on the language that was used to create the application. If injection occurs within the javascript code, the maximum potential impact is cross-site scripting. In the case of reflected XSS, it should be scored as:
6.1 [CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N] — Medium severity.

If javascript code can be stored in a database or files and then executed in the browser, it should be scored as:
But if injection occurs within PHP code, the vulnerability could be used to compromise the entire system, and it should be scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] — Critical severity.

Credits: https://www.immuniweb.com/