| Attack Pattern ID | Pattern Abstraction: Standard 77 |
| Typical Severity | Very High |
| Description | Summary 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. Attack Execution Flow 1- The attacker communicates with the application server using a thin client (browser) or thick client. 2- While communicating with the server, the attacker finds that she can control and override a variable consumed by the application server. 3- The attacker overrides the variable and influences the normal behavior of the application server.
|
| Attack Prerequisites | A variable consumed by the application server is exposed to the client. A variable consumed by the application server can be overwritten by the user. The application server trusts user supplied data to compute business logic. The application server does not perform proper input validation. |
| Typical Likelihood of Exploit |
Very High
|
| Methods of Attack | |
| Examples-Instances | Description Attack Example: PHP Global Variables
PHP is a study in bad security. The main idea pervading PHP is “ease of use,” and the mantra “don’t make the developer go to any extra work to get stuff done” applies in all cases. This is accomplished in PHP by removing formalism from the language, allowing declaration of variables on first use, initializing everything with preset values, and taking every meaningful variable from a transaction and making it available. In cases of collision with something more technical, the simple almost always dominates in PHP.
One consequence of all this is that PHP allows users of a Web application to override environment variables with user-supplied, untrusted query variables. Thus, critical values such as the CWD and the search path can be overwritten and directly controlled by a remote anonymous user.
Another similar consequence is that variables can be directly controlled and assigned from the user-controlled values supplied in GET and POST request fields. So seemingly normal code like this, does bizarre things:
while($count < 10){
// Do something
$count++;
}
Normally, this loop will execute its body ten times. The first iteration will be an undefined zero, and further trips though the loop will result in an increment of the variable $count. The problem is that the coder does not initialize the variable to zero before entering the loop. This is fine because PHP initializes the variable on declaration. The result is code that seems to function, regardless of badness. The problem is that a user of the Web application can supply a request such as
GET /login.php?count=9
and cause $count to start out at the value 9, resulting in only one trip through the loop. Yerg.
Depending on the configuration, PHP may accept user-supplied variables in place of environment variables. PHP initializes global variables for all process environment variables, such as $PATH and $HOSTNAME. These variables are of critical importance because they may be used in file or network operations. If an attacker can supply a new $PATH variable (such as PATH='/var'), the program may be exploitable.
PHP may also take field tags supplied in GET/POST requests and transform them into global variables. This is the case with the $count variable we explored in our previous example.
Consider another example of this problem in which a program defines a variable called $tempfile. An attacker can supply a new temp file such as $tempfile = "/etc/passwd". Then the temp file may get erased later via a call to unlink($tempfile);. Now the passwd file has been erased—a bad thing indeed on most OSs.
Also consider that the use of include() and require() first search $PATH, and that using calls to the shell may execute crucial programs such as ls. In this way, ls may be “Trojaned” (the attacker can modify $PATH to cause a Trojan copy of ls to be loaded). This type of attack could also apply to loadable libraries if $LD_LIBRARY_PATH is modified.
Finally, some versions of PHP may pass user data to syslog as a format string, thus exposing the application to a format string buffer overflow.
Related Vulnerability File upload allows arbitrary file read by setting hidden form variables to match internal variable names (CVE-2000-0860) |
| Attacker Skill or Knowledge Required | Low: the malicious user can easily try some well known global variables and find one which matches.
Medium - the attacker can use automated tools to probe for variables that she can control. |
| Probing Techniques | The attacker can try to change the value of the variables that are exposed on the webpage's source code and send them back to the application server. Depending on what program is running on the application server, the attacker may know which variables should be targeted. The malicious user may try to guess a global variable just by blackbox testing at the request level. For instance it is possible to create a variable and assign it a value, then pass it along to the request made to the server. Web penetration tool can be used to automate the discovery of client controlled global variables. |
| Indicators-Warnings of Attack | A web penetration tool probing a web server may generate abnormal activities recorded on log files. Abnormal traffic such as a high number of request coming from the same client may also rise the warnings from a monitoring system or an intrusion detection tool. |
| Solutions and Mitigations | Do not allow override of global variables and do Not Trust Global Variables.
If the register_globals option is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request. This means that a malicious user may be able to set variables unexpectedly. For instance make sure that the server setting for PHP does not expose global variables. A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Separate the presentation layer and the business logic layer. Variables at the business logic layer should not be exposed at the presentation layer. This is to prevent computation of business logic from user controlled input data. Use encapsulation when declaring your variables. This is to lower the exposure of your variables. Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should be rejected by the program. |
| Attack Motivation-Consequences | - Data Modification
- Run Arbitrary Code
- Information Leakage
- Privilege Escalation
|
| Context Description | Technique: Leveraging Extraneous Variables
In many cases, software may come preset with various parameters set by default. In many cases, the default values are set with no regard for security. An attacker can leverage these broken defaults during an attack.
In the interest of convenience (laziness?), some programmers may integrate “secret variables” into their applications. A secret variable works like a code word. If this secret code word is used, the application opens the vault. An example is a Web application that distinguishes between normal users and administrators by checking for a hidden form variable with a particular value such as ADMIN=YES. This may sound crazy, but many internally developed Web-based applications used by the world’s largest banks operate this way. This is one of the tricks that software auditing teams look for.
Sometimes these types of problems are not intentional on the part of programmers, but rather come “by design” in a platform or language. This is the case with PHP global variables.
|
| Injection Vector | The user controlled variable. |
| Payload | The new value of the user controlled variable. |
| Activation Zone | The command or request interpreter on the server side is responsible for interpreting the global variables. Sometime the global variables are controlled by a setting. For instance in PHP, the boolean setting "register_globals" defines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables. As of PHP 4.2.0, this settings defaults to off. This directive was removed in PHP 6.0.0. |
| Payload Activation Impact | Changing the value of a server side variable may have many outcomes. In the case of a DEBUG related variable, there will be an information leak problem. Some other impacts can be privilege escalation, data modification, etc. It really depends on what the variable controls. If a global variable is used for authentication, there may be a vulnerability of privilege escalation. Another common variation of this last problem is to implement a "Remember My Login" feature by storing a user identifier in a cookie, allowing users to change their cookie value to login as whomever they want. |
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 473 | PHP External Variable Modification | Targeted | | 15 | External Control of System or Configuration Setting | Targeted | | 285 | Missing or Inconsistent Access Control | Secondary | | 302 | Authentication Bypass by Assumed-Immutable Data | Targeted | | 94 | Code Injection | Secondary | | 96 | Insufficient Control of Directives in Statically Saved Code (Static Code Injection) | Secondary |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 13 | Subverting Environment Variable Values | More Abstract | | | 10 | Buffer Overflow via Environment Variables | More Abstract | | | 22 | Exploiting Trust in Client (aka Make the Client Invisible) | More Detailed | |
|
| Related Guidelines | - Global variables used on the server side should not be trusted.
- Overide of Global variables should not be allowed.
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | All | All | All |
|
| References | G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Securing PHP: Step-by-Step, Artur Maj 2003-06-23, http://www.securityfocus.com/infocus/1706 Ten Security Checks for PHP, Part 1 - by Clancy Malcolm, 03/20/2003 "Chapter 29. Using Register Globals", from the Official PHP documentation: http://www.php.net/manual/en/security.globals.php |
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-03-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Eric Dalci | Cigital, Inc | 2007-02-13 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-07 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name, Description and Related Attack Patterns | | Sean Barnum | Cigital, Inc | 2007-04-16 | Modified pattern content according to review and feedback |
|
