Improper Control of Generation of Code

CWE:94

What is Code Injection?

Code injection is the malicious injection or introduction of code into an application. Such attacks can plague applications that depend on user input for execution.

Types of Code Injection:

1.SQL injection 2.Script injection 3.Shell injection 4.Dynamic evaluation 5.Object injection 6.Remote file injection

Read more on Code injection..

Click here to navigate to CWE:94

Learn more from Wiki

Mode of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The maximum impact of this weakness depends on the software design and implementation phase.

Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be a high likelihood that weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope Impact
Confidentiality The injected code could access restricted data/files.
Authentication In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Access Control Injected code can access resources that the attacker is directly prevented from accessing.
Integrity Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.
Accountability Often the actions performed by injected control code are unlogged.

####Attack Patterns

There are following CAPEC attack patterns which correspond to this weakness:

#####CAPEC-35: Leverage Executable Code in Nonexecutable Files

An attack of this type exploits a system’s trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

Navigate to CAPEC-77

#####CAPEC-77: Manipulating User-Controlled Variables

This attack targets user-controlled variables (DEBUG=1, PHP Globals, and So Forth). An attacker can override environment variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the attacker can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.

Navigate to CAPEC-77

Mitigation:

Code injection vulnerabilities range from easy to difficult-to-find ones. Many solutions have been developed for thwarting these types of code injection attacks, for both application and architecture domain. Some examples include input validation, parameterization, privilege setting for different actions, the addition of an extra layer of protection and others.

What are some steps to mitigate code injection?

Here are some of the possible steps you can take to avoid code injection on your web- application

  1. Input Sanitization - Injection attacks are performed by including special characters in the parameters sent from the client to the server. The most effective mitigation mechanism is to assume all user inputs are potentially malicious and perform data validation and sanitization for all user-submitted input content before sending the queries to the server for execution. Here are some common good practices:

  2. Error message handling - Hackers can learn a great deal about the system architecture from error messages, detailed error information can be used to refine the original attack and increase the chances of success for hacking. Therefore, it should ensure that they display as little information as possible. Besides, it is better to use the generic error messages on the local machine while ensuring that an external hacker gets nothing more than the fact that his/her actions resulted in an unhandled error.

  3. Appropriate Least user privileges - Web applications should never connect to your database using an account with admin-level privileges (e.g. “root” account). All application processes should be executed with the minimal privileges required. In addition, processes must release privileges as soon as they no longer require them. Best practice is to create an isolated account specifically for each application and deny access to all objects that are unnecessary to be used by the applications.

  4. Source Code Review - To guard against the injection flaws, code writers should refer to their internal coding guideline or OWASP injection prevention cheat sheet during the development phase. In addition, code writers or reviewers can utilize source code scanning tools to review and look for injection flaws and then fix the vulnerabilities. Some useful scanning tools can be in the marketplace included: UrlScan, WebInspect, Scrawlr, W3AF, LDAP Injector, and JBroFuzz

Example:

$MessageFile = "cwe-94/messages.out";
if ($_GET["action"] == "NewMessage") 
{
$name = $_GET["name"]; 
$message = $_GET["message"];
$handle = fopen($MessageFile, "a+");
fwrite($handle, "<b>$name</b> says '$message'<hr>\n");
fclose($handle);
echo "Message Saved!<p>\n";}
else if ($_GET["action"] == "ViewMessages"){
include($MessageFile);}
Input:

name=h4x0r message=%3C?php%20system(%22/bin/ls%20-l%22);?%3E

Code decode:
<?php system("/bin/ls -l");?>

These codes are demonstrated using a bWAPP bee box. bWAPP, or a buggy web application, is a free and open source deliberately insecure web application. It helps security enthusiasts, developers and students to discover and to prevent web vulnerabilities. bWAPP prepares one to conduct successful penetration testing and ethical hacking projects. bWAPP is a PHP application that uses a MySQL database. It can be hosted on Linux/Windows with Apache/IIS and MySQL. It can also be installed with WAMP or XAMPP. Another possibility is to download the bee-box, a custom Linux VM pre-installed with bWAPP. The following is the link we use to play with the above php code,

Username: Bee Password: Bug http://localhost/bWAPP/phpi.php?message= “?