<?xml version="1.0" encoding="UTF-8"?>
<Common_Attack_Pattern_Enumeration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ap_schema_v1.4.xsd">
	<Attack_Pattern CAPEC_ID="1" Name="Accessing Functionality Not Properly Constrained by ACLs">
		<Description>
			<Summary>In applications, particularly web applications, access to functionality is mitigated by the authorization framework, whose job it is to map ACLs to elements of the application's functionality; particularly URL's for web apps. In the case that the application deployer failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application or can run queries for data that he is otherwise not supposed to.
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>The attacker surveys the target application, possibly as a valid and authenticated user</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>At each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actions</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>Possibly as a valid user, the attacker then tries to access each of the noted acces mechanisms directly in order to perform functions not constrained by the ACLs.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>The application must be navigable in a manner that associates elements (subsections) of the application with ACLs.</Attack_Prerequisite>
			<Attack_Prerequisite>The various resources, or individual URLs, must be somehow discoverable by the attacker</Attack_Prerequisite>
			<Attack_Prerequisite>The deployer must have forgotten to asociate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Analysis</Method_of_Attack>
			<Method_of_Attack>Brute Force</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				Implementing the Model-View-Controller (MVC) within Java EE's Servlet paradigm using a "Single front controller" pattern that demands that brokered HTTP requests be authenticated before hand-offs to other Action Servlets. 
				If no security-constraint is placed on those Action Servlets, such that positively no one can access them, the front controller can be subverted.</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: In order to discover unrestricted resources, the attacker does not need special tools or skills. He only has to observe the resources or access mechanisms invoked as each action is performed and then try and acecss those access mechanisms directly.</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>No special resources are required for the exploit of this pattern.</Resources_Required>
		<Probing_Techniques>
			<Probing_Technique>In the case of web applications, use of a spider or other crawling software can allow an attacker to search for accessible pages not beholden to a security constraint.</Probing_Technique>
			<Probing_Technique>More generally, noting the target resource accessed upon performing specifc actions drives an understanding of the resources accessible from the current context.</Probing_Technique>
		</Probing_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>In a J2EE setting, deployers can associate a role that is impossible for the authenticator to grant users, such as "NoAccess", with all Servlets to which access is guarded by a limited number of servlets visible to, and accessible by, the user.. 
			Having done so, any direct access to those protected Servlets will be prohibited by the web container. 
			In a more general setting, the deployer must mark every resource besides the ones supposed to be exposed to the user as accessible by a role impossible for the user to assume. The default security setting must be to deny access and then grant access only to those resources intended by business logic.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>The context of this pattern's applicability is most likely a web-based application, subject to an authorization framework. </Context_Description>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>285</CWE_ID>
				<Weakness_Name>Missing or Inconsistent Access Control</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>276</CWE_ID>
				<Weakness_Name>Insecure Default Permissions</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Relevant_Security_Requirements>
			<Relevant_Security_Requirement>All resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logic</Relevant_Security_Requirement>
			<Relevant_Security_Requirement>In addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL.</Relevant_Security_Requirement>
		</Relevant_Security_Requirements>
		<Related_Security_Principles>
			<Related_Security_Principle>Failing Securely</Related_Security_Principle>
			<Related_Security_Principle>Least Privilege</Related_Security_Principle>
			<Related_Security_Principle>Reluctance To Trust</Related_Security_Principle>
			<Related_Security_Principle>Complete Mediation</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Use Authorization Mechanisms Correctly</Related_Guideline>
			<Related_Guideline>Design Configuration Subsystems Correctly and Distribute Safe Default Configurations</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>John Steven</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-10</Submission_Date>
				<Submission_Comment>Initial core pattern content</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Chiradeep B. Chhaya</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-23</Modification_Date>
				<Modification_Comment>Fleshed out pattern with extra content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Attack Execution Flow, Attack Prerequisites, Examples and Solutions</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="2" Name="Inducing Account Lockout">
		<Description>
			<Summary>
			An attacker leverages the security functionality of the system aimed at thwarting potential attacks to launch a denial of service attack against a legitimate system user.  Many systems, for instance, implement a password throttling mechanism that locks an account after a certain number of incorrect log in attempts.  An attacker can leverage this throttling mechanism to lock a legitimate user out of their own account.  The weakness that is being leveraged by an attacker is the very security feature that has been put  in place  to counteract attacks.
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>
						Investigate the security features present in the system that may trigger an account lockout.
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						Reproduce behavior that would result in an account being locked by one of the existing security features.
					</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				The system has a lockout mechanism.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
			An attacker must be able to reproduce behavior that would result in an account being locked. 
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Medium</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
			<Method_of_Attack>Flooding</Method_of_Attack>
			<Method_of_Attack>Brute Force</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					A famous example of this type an attack is the eBay attack.  eBay always displays the user id of the highest bidder.  In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time.  An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out.   Thus an attacker could win the auction.
				</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability/>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>Computer with access to the login portion of the target system</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
			Implement intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.   
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
			When implementing security features, consider how they can be misused and made to turn on themselves.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Related_Weaknesses>
			<!-- New CWE needed: "Overly Restrictive Account Lockout Mechanism" -->
			<Related_Weakness>
				<CWE_ID>400</CWE_ID>
				<Weakness_Name>Resource Exhaustion</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Source>
			<Submission>
				<Submitter>Eugene Lebanidze</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-26</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-01</Modification_Date>
				<Modification_Comment>Review and revision of content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Description and Solutions</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="3" Name="Using Leading 'Ghost' Character Sequences to Bypass Input Filters">
		<Description>
			<Summary>
An attacker intentionally introduces leading characters that enable getting the input past the filters.  The API that is being targetted, ignores the leading "ghost" characters, and therefore processes the attacker's input.  This occurs when the targetted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targetted API.

Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes.

One commonly used possibility involves adding ghost characters—extra characters that don’t affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.		
	    </Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>
						Determine if the source code is available and if so, examine the filter logic.
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						If the source code is not available, write a small program that loops through various possible inputs to given API call and tries a variety of alternate (but equivalent) encodings of strings with leading ghost characters.  Knowlege of frameworks and libraries used and what filters they apply will help to make this search more structured. 
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						 Observe the effects.  See if the probes are getting past the filters.  Identify a string that is semantically equivalent to that which an attacker wants to pass to the targeted API, but syntactically structured in a way as to get past the input filter.  That encoding will contain certain ghost characters that will help it get past the filters.  These ghost characters will be ignored by the targeted API.			
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						Once the "winning" alternate  encoding using (typically leading) ghost characters is identified, an attacker can launch the attacks against the targetted API (e.g. directory traversal attack, arbitrarary shell command execution, corruption of files)
					</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				The targetted API must ignore the leading ghost characters that are used to get past the filters for the semantics to be the same.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Medium</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Alternate Encoding with Ghost Characters in FTP and Web Servers

Some web and FTP servers fail to detect prohibited upward directory traversals if the user-supplied pathname contains extra characters such as an extra leading dot.  For example, a program that will disallow access to the pathname “../test.txt” may erroneously allow access to that file if the pathname is specified as “…/test.txt”.  This attack succeeds because 1) the input validation logic fails to detect the triple-dot as a directory traversal attempt (since it isn’t dot-dot), 2) some part of the input processing decided to strip off the “extra” dot, leaving the dot-dot behind.

Using the file system API as the target, the following strings are all equivalent to many programs:

.../../../test.txt
............/../../test.txt
..?/../../test.txt
..????????/../../test.txt
../test.txt

As you can see, there are many ways to make a semantically equivalent request. All these strings ultimately result in a request for the file ../test.txt.
				</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability/>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Medium
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required/>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Perform white list rather than black list input validation.   
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
			 Canonicalize all data prior to validation.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
			Take an iterative approach to input validation (defense in depth).
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		
Building “Equivalent” Requests

A large number of commands are subject to parsing or filtering. In many cases a filter only considers one particular way to format a command. The fact is that the same command can usually be encoded in thousands of different ways. In many cases, an alternative encoding for the command will produce exactly the same results as the original command. Thus, two commands that look different from the logical perspective of a filter end up producing the same semantic result. In many cases, an alternatively encoded command can be used to attack a software system, because the alternative command allows an attacker to perform an operation that would otherwise be blocked.

Mapping the API Layer

A good approach to help identify and map possible alternate encodings involves writing a small program that loops through all possible inputs to a given API call. This program can, for example, attempt to encode filenames in a variety of ways. For each iteration of the loop, the “mungified” filename can be passed to the API call and the result noted.

The following code snippet loops through many possible values that can be used as a prefix to the string \test.txt. Results of running a program like this can help us to determine which characters can be used to perform a ../../ (dots and slashes) relative traversal attack.

int main(int argc, char* argv[])
{
   for(unsigned long c=0x01010101;c != -1;c++)
   {
        char _filepath[255];
        sprintf(_filepath, &quot;%c%c%c%c\\test.txt&quot;, c &gt; 24, c &gt; 16, c &gt; 8, c&amp;0x000000FF );

        try
       {
       FILE *in_file = fopen(_filepath, &quot;r&quot;);

       if(in_file)
      {
             printf(&quot;checking path %s\n&quot;, _filepath);
             puts(&quot;file opened!&quot;);
             getchar();
             fclose(in_file);
      }
      }
      catch(...)
     {

     }
  }
  return 0;
}

Slight (but still automatic) modifications can be made to the string in creative ways. Ultimately, the modified string boils down to an attempt to use different tricks to obtain the same file. For example, one resulting attempt might try a command like this:

sprintf(_filepath, &quot;..%c\\..%c\\..%c\\..%c\\scans2.txt&quot;, c, c, c, c);

A good way to think about this problem is to think of layers. The API call layer is what the examples shown here are mapping. If an engineer has placed any filters in front of the API call, then these filters can be considered additional layers, wrapping the original set of possibilities. By pondering all the possible inputs that can be provided at the API layer, we can begin uncovering and exercising any filters that the software has in place. If we know that the software definitely uses file API calls, we can try all kinds of filename encoding tricks that we know about. If we get lucky, eventually one set of encoding tricks will work, and we can get our data successfully through the filters and into the API call.

Drawing on the techniques described in Chapter 5 of "Exploiting Software: How to Break Code" (See reference - G. Hoglund and G. McGraw) , we can list a number of possible escape codes that can be injected into API calls (many of which help with the filter avoidance problem). If the data are eventually being piped into a shell, for example, we might be able to get control codes to take effect. A particular call may write data to a file or a stream that are eventually meant to be viewed on a terminal or in a client program. As a simple example, the following string contains two backspace characters that
are very likely to show up in the terminal’s execution:

write(&quot;echo hey!\x08\x08&quot;);

When the terminal interprets the data we have passed in, the output will be missing the last two characters of the original string. This kind of trick has been used for ages to corrupt data in log files. Log files capture all kinds of data about a transaction. It may be possible to insert NULL characters (for
example, %00 or &apos;\0&apos;) or to add so many extra characters to the string that the request is truncated in the log. Imagine a request that has more than a thousand extra characters tacked on at the end. Ultimately, the string may be trimmed in the log file, and the important telltale data that expose an attack will be lost.

Ghost Characters

Ghost characters are extra characters that can be added to a request. The extra characters are designed not to affect the validity of the request. One easy example involves adding extra slashes to a filename. In many cases, the strings

/some/directory/test.txt

and

/////////////////some/////////////directory//////////////test.txt

are equivalent requests.		

From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley,	 February 2004.
		</Context_Description>
		<Injection_Vector>
				Web Form, URL, Network Socket, File
		</Injection_Vector>
		<Payload>
			The payload is the parameter that an attacker is supplying to the targetted API that will allow the attacker to elevate privilege and subvert the authorization service.
		</Payload>
		<Activation_Zone>
			The targetted API is the activation zone.  These attacks often target the file system or the shell to execute commands.
		</Activation_Zone>
		<Payload_Activation_Impact>
			Failure in authorization service may lead to compromises in data confidentiality and integrity.
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>173</CWE_ID>
				<Weakness_Name>Alternate encoding</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>41</CWE_ID>
				<Weakness_Name>Path Equivalence</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>172</CWE_ID>
				<Weakness_Name>Encoding Error</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>171</CWE_ID>
				<Weakness_Name>Cleansing, Canonicalization, and Comparison Errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>179</CWE_ID>
				<Weakness_Name>Early Validation Errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>180</CWE_ID>
				<Weakness_Name>Validate-Before-Canonicalize</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>181</CWE_ID>
				<Weakness_Name>Validate-Before-Filter</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>183</CWE_ID>
				<Weakness_Name>Permissive Whitelist</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>184</CWE_ID>
				<Weakness_Name>Incomplete Blacklist</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Security_Principles>
			<Related_Security_Principle>
				Defense in Depth
			</Related_Security_Principle>
			<Related_Security_Principle>
				Reluctance to Trust
			</Related_Security_Principle>
			<Related_Security_Principle>
				Least Privilege
			</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Perform input validation and filtering on data in its canonical form.</Related_Guideline>
			<Related_Guideline>Understand the APIs to which user input will be passed and know how permissive they are.  Perform appropriate input validation given that information.</Related_Guideline>
		</Related_Guidelines>
			<Purpose>Exploitation</Purpose>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Low</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley,	 February 2004.
				</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eugene Lebanidze</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-26</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Attack Execution Flow and Examples</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="4" Name="Using Alternative IP Address Encodings">
		<Description>
			<Summary>This attack relies on the attacker using unexpected formats for representing IP addresses. Networked applications may expect network location information in a specific format, such as fully qualified domains names, URL, IP address, or IP Address ranges. The issue that the attacker can exploit is that these design assumptions may not be validated against a variety of different possible encodings and network address location formats. Applications that use naming for creating policy namespaces for managing access control may be susceptible to queryin directly by IP addresses, which is ultimately  a more generally authoritative way of communicating on a network.
			Alternative IP addresses can be used by the attacker to bypass application access control in order to gain access to data that is only protected by obscuring its location. 
			In addition this type of attack can be used as a reconnaissance mechansim to provide entry point information that the attacker gathers to penetrate deeper into the system.</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				The target software must fail to anticipate all of the possible valid encodings of an IP/web address.
				</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → The attacker has only to try IP address combinations. 
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to communicate with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Default deny access control policies 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Design: Input validation routines should check and enforce both input data types and content against a positive specification. In regards to IP addresses, this should include the authorized manner for the application to represent IP addresses and not accept user specified IP addresses and IP address formats (such as ranges)
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform input validation for all remote content.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Alternative IP Addresses
		"IP address ranges can be represented using alternative methods. Here are some examples:
		192.168.0.0/24
		192.168.0.0/255.255.255.0
		192.168.0.*
		
		Classic encoding techniques can be directed against IP numbers as well."
		
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard input 
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. Malicious payload may be passed directly from appliation client, such as the web browser.
		</Payload>
		<Activation_Zone>
			Client machine and client network 
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to view and access unexpected network services.
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<!-- Need new CWE under Pathname Traversal and Equivalence Errors focused on IP address/domain name equivalence issues -->
			<Related_Weakness>
				<CWE_ID>291</CWE_ID>
				<Weakness_Name>
					Trusting Self-Reported Ip Address
				</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>180</CWE_ID>
				<Weakness_Name>Validate-Before-Canonicalize</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>41</CWE_ID>
				<Weakness_Name>Path Equivalence</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>345</CWE_ID>
				<Weakness_Name>Insufficient Verification of Data</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
				G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Attack Prerequisites,Resources Required and Method of Attack</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="5" Name="Analog In-band Switching Signals (aka Blue Boxing)">
		<Description>
			<Summary>
		This attack against older telephone switches and trunks has been around for decades. The signal is sent by the attacker to impersonate a supervisor signal. This has the effect of rerouting or usurping command of the line and call. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded telco infrastructure and so are vulnerable to Blue boxing.

		Blue boxing is a result of failure on the part of the system to enforce strong authentication for administrative functions. While the infrastructure is different than standard current applications like web applications, there are hisotrical lessons to be learned to upgrade the access control for administrative functions.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				System must use weak authentication mechanisms for administrative functions.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					Attacker identifies a vulnerable CCITT-5 phone line, and sends a combination tone to the switch in order to request administrative access. Based on tone and timing parameters the request is verified for access to the switch. Once the attacker has gained control of the switch launching calls, routing calls, and a whole host of opportunities are available.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low: Given a vulnerable phone system, the attacker's technical vector relies on attacks that are well documented in cracker 'zines and have been around for decades.
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			CCITT-5 or other vulnerable lines, with the ability to send tones such as combined 2,400 Hz and 2,600 Hz tones to the switch
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Implementation: Upgrade phone lines. Note this may be prohibitively expensive
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Use strong access control such as two factor access control for adminsitrative access to the switch
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Analog In-band Switching Signals (aka "Blue Boxing")
		Many people have heard of 2600, the frequency used in the United States to control telephone switches during the 1960s and 1970s. (Come to think of it, probably more people have heard of the hacker 'zine 2600 and its associated club than have heard of the reason for the name of the club,) Most systems are no longer vulnerable to ancient phreaking attacks. However older systems are still found internationally. Overseas trunk lines that use trans-Atlantic cabling are prone to the in-band signal problem, and they are too expensive a resource to abandon. Thus, many overseas (home-country direct) 800/888 numbers are known to have in-band signal problems even today.

		Consider the CCITT-5(C5) signaling system that is used internationally. This system does not use the commonly known 2,600 Hz, but instead uses 2,400Hz as a control signal. If you have ever heard the "pleeps" and chirps on the Pink Floyd album "The Wall," then you have heard C5 signals. There are millions of phone lines still in operation today that are routed through switches with in-band signaling.

		This attack pattern involves playing specific control commands across a normal voice link, thus seizing control of the line, rerouting calls, and so on."

		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Payload delivered through standard communication protocols.
		</Injection_Vector>
		<Payload>
			Command(s) executed directly on host
		</Payload>
		<Activation_Zone>
			Client machine and client network
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables calls to be rerouted.
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>264</CWE_ID>
				<Weakness_Name>Permissions, Privileges, and Access Controls</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Low</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>Medium</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>Other</Architectural_Paradigm>
			<Framework>Other</Framework>
			<Platform>Other</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="6" Name="Argument Injection">
		<Description>
			<Summary>
		An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be directly or indirectly applied as arguments, for example as shell commands. This may allow an attacker access to files, network resources, media, and in short anything accessible through the shell.

		The argument injection attack uses the exposed service or method as a launch pad to invoke other programs. If the service does not validate or filter the input data then the client program is granted access to execute commands using the server's privileges. The OS commands can be appended to standard input for shell programs, HTTP Requests, and XML messages. The ability to invoke commands is not necessarily sufficient for the attacker to collect the output of the attack. This may or may not be an issue depending on the attacker goal.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Target software fails to strip all user-supplied input of any content that could cause the shell to perform unexpected actions.</Attack_Prerequisite>
			<Attack_Prerequisite>
				Software must allow for unvalidated or unfiltered input to be executed on operating system shell, and, optionally, the system configuration must allow for output to be sent back to client.
				</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>A recent example instance of argument injection occurred against Java Web Start technology, which eases the client side deployment for Java programs. The JNLP files that are used to describe the properties for the program. The client side Java runtime used the arguments in the property setting to define execution parameters, but if the attacker appends commands to an otherwise legitimate property file, then these commands are sent to the client command shell.
					Source http://www.securityfocus.com/archive/1/393696</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Medium → The attacker has to identify injection vector, identify the operating system-specific commands, and optionally collect the output. 
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Do not program input values directly on command shell, instead treat user input as guilty until proven innocent. Build a function that takes user input and converts it to applications specific types and values, stripping or filtering out all unauthorized commands and characters in the process.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Design: Limit program privileges, so if metacharcters or other methods circumvent program input validation routines and shell access is attained then it is not running under a privileged account. chroot jails create a sandbox for the application to execute in, making it more difficult for an attacker to elevate privilege even in the case that a compromise has occurred.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Implement an audit log that is written to a separate host, in the event of a compromise the audit log may be able to provide evidence and details of the compromise.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Argument Injection
		"User input is directly pasted into the argument of a shell command. A number of third-party programs allow passthrough to a shell with little or no filtering."
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard input, the attacker inserts additional arguments on the application's standard interface 
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. Malicious payload either pass commands through valid paramters or supply metacharacters that cause unexpected termination that redirects to shell
		</Payload>
		<Activation_Zone>
			Client machine and client network (e..g Intranet)
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to execute server side code with any commands that the program owner has privileges to, this is particularly problematic when the sprogram is run as a system or privileged account.
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>77</CWE_ID>
				<Weakness_Name>Command Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>146</CWE_ID>
				<Weakness_Name>Delimiter between Expressions or Commands</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>184</CWE_ID>
				<Weakness_Name>Incomplete Blacklist</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>78</CWE_ID>
				<Weakness_Name>OS Command Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>185</CWE_ID>
				<Weakness_Name>Regular Expression Error</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Guidelines>
			<Related_Guideline>Never Use Input as Part of a Directive to any Internal Component</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Low</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Attack Prerequisites and Related Guidelines</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="7" Name="Blind SQL Injection">
		<Description>
			<Summary>Blind SQL Injection results from a &quot;Security by Obscurity&quot; approach to preventing SQL Injection. It is a common misconception that suppressing error messages from the database is an efficient means of thwarting SQL Injection. Blind SQL Injection is a form of SQL Injection that attempts to overcome a common defense against “regular” SQL Injection.  With Blind SQL Injection, the attacker assumes that the target software will suppress error messages from the SQL server under attack.  Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions.  The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not.  Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.
			In order to achieve this using Blind SQL Injection, an attacker:</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>Determines the user-controllable input susceptible to injection</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>Determines the type of the database, such as MS SQL Server or Oracle or MySQL, using logical conditions as part of the injected queries</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>Determines the number and types of parameters for boolean queries that the database executes if the injected condition is true and does not if the injected condition is false</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>Uses the information obtained in the first three steps to successfully inject the database in order to bypass checks or modify, add, retrieve or delete data from the database</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>SQL queries used by the application to store, retrieve or modify data.</Attack_Prerequisite>
			<Attack_Prerequisite>User-controllable input that is not properly validated by the application as part of SQL queries.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Analysis</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>In the PHP application TimeSheet 1.1, an attacker can successfully retrieve username and password hashes from the database using Blind SQL Injection. If the attacker is aware of the local path structure, the attacker can also remotely execute arbitrary code and write the output of the injected queries to the local path. Blind SQL Injection is possible since the application does not properly sanitize the $_POST['username'] variable in the login.php file.</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability>CVE-2006-4705</Example-Instance_Related_Vulnerability>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Medium - Determining the database type and version, as well as the right number and type of parameters to the query being injected in the absence of error messages requires greater skill than reverse-engineering database error messages.</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>None</Resources_Required>
		<Probing_Techniques>
			<Probing_Technique>In order to determine the right syntax for the query to inject, the attacker tries to determine the right number of parameters to the query and their types. This is achieved by formulating conditions that result in a true/false answer from the database. If the logical condition is true, the database will execute the rest of the query. If not, a custom error page or a default page is returned. Another approach is to ask such true/false questions of the database and note the response times to a query with a logically true condition and one with a false condition.</Probing_Technique>
		</Probing_Techniques>
		<Indicators-Warnings_of_Attack>
			<Indicator-Warning_of_Attack>The only indicators of successful Blind SQL Injection are the application or database logs that show similar queries with slightly differing logical conditions that increase in complexity over time. However, this requires extensive logging as well as knowledge of the queries that can be used to perform such injection and return meaningful information from the database.</Indicator-Warning_of_Attack>
		</Indicators-Warnings_of_Attack>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Security by Obscurity is not a solution to preventing SQL Injection. Rather than suppress error messages and exceptions, the application must handle them gracefully, returning either a custom error page or redirecting the user to a default page, without revealing any information about the database or the application internals.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>An attacker attempts Blind SQL Injection when traditional SQL Injection is not possible due to suppression of error messages.
		
				Blind SQL Injection is performed by appending logical conditions to the query being injected such that they evaluate to true or false in the context of the data stored in the database. The first step is to get the syntax for the injected query right. For example, consider a database that has a table named &quot;users&quot;. Consider the following query:
				SELECT fname, lname, dob, ssn, address FROM users WHERE userid=&quot;user1&quot; AND password=&quot;user1pwd&quot;;
				
				To determine whether the &quot;userid&quot; field is injectable or not, the attacker tries an input such as 
				user1&quot; AND 3&gt;1+1;--
				
				This causes the following query
				SELECT fname, lname, dob, ssn, address FROM users WHERE userid=&quot;user1&quot; AND 3&gt;1+1;--
				
				to be passed to the database. If the parameter is injectable, the database evaluates 3&gt;1+1 to be true and executes the query. If, on the other hand, a condition such as 3&lt;2 were passed, the database would return an error. Since the application suppresses such errors, the attacker never sees it. However, the application may simply hang or it may redirect to a custom error page or a default page, which is definitely an indication that the injected condition was evaluated to be false. The query can also fail if the original condition was within parentheses, such as
				
				WHERE (userid=&quot;johns&quot; AND password=&quot;abracadabra&quot;)
				
				In such a case, the attacker will have to try injection such that the parentheses match up.
				
				Once the attacker gets the syntax right, the next step is to identify the database. This can be achieved by using operators that are unique to each database engine. For example, a condition such as &quot;abc&quot; = &quot;a&quot;+&quot;bc&quot; evaluates to true on MS SQL Server whereas it evaluates to false on Oracle since the concatentation operator is ||. Another approach is using system-specific functions such as those for date and time.
				
				The next step is to determine the number and type of parameters. This can again be achieved by exploiting the SELECT...WHERE conditions or using UNION SELECT statements with dummy numeric or character-based parameters.
				
				Once the type of database as well as the structure of the query has been mapped out by asking a number of questions to the database, the attacker is in a position to inject the database and extract information from it.
				
				Blind SQL Injection is a classic example of solution by reduction where the domain to be attacked is successively narrowed down by the attacker through true or false queries to the database.
		</Context_Description>
		<Injection_Vector>User-controllable input to the application</Injection_Vector>
		<Payload>SQL statements intended to bypass checks or retrieve information about the database</Payload>
		<Activation_Zone>Back-end database</Activation_Zone>
		<Payload_Activation_Impact>The injected SQL statetements are such that they result in a true/false query to the database. If the database evaluates a statement to be logically true, it responds with the requested data. If the condition is evaluated to be logically false, an error is returned. The attacker modifies the boolean condition each time to gain information from the database.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>89</CWE_ID>
				<Weakness_Name>SQL Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>209</CWE_ID>
				<Weakness_Name>Error Message Information Leaks</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>390</CWE_ID>
				<Weakness_Name>Improper Error handling</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>66</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Occasionally Precedes</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Relevant_Security_Requirements>
			<Relevant_Security_Requirement>Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.</Relevant_Security_Requirement>
			<Relevant_Security_Requirement>Special characters in user-controllable input must be escaped before use by the application.</Relevant_Security_Requirement>
			<Relevant_Security_Requirement>Employ application-level safeguards to filter data and handle exceptions gracefully.</Relevant_Security_Requirement>
		</Relevant_Security_Requirements>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to Trust</Related_Security_Principle>
			<Related_Security_Principle>Failing Securely</Related_Security_Principle>
			<Related_Security_Principle>Defense in Depth</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Never Use Input as Part of a Directive to any Internal Component</Related_Guideline>
			<Related_Guideline>Handle All Errors Safely</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>CWE - Input Validation</Reference>
			<Reference>CWE - Improper Error Handling</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>Chiradeep B Chhaya</Submitter>
				<Submission_Date>2007-02-22</Submission_Date>
				<Submission_Comment>Third Draft - Revised to schema v1.4</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Malik Hamro</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-27</Modification_Date>
				<Modification_Comment>Reformat to new schema and review</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Description, Attack Prerequisites and Related Attack Patterns</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="96" Name="Block Access to Libraries">
		<Description>
			<Summary>
				An application typically makes calls to functions that are a part of libraries external to the application.  These libraries may be part of the operating system or they may be third party libraries.  It is possible that the application does not handle situations properly where access to these libraries has been blocked.  Depending on the error handling within the application, blocked access to libraries may leave the system in an insecure state that could be leveraged by an attacker.  
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>
					Determine what external libraries the application accesses.
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
					Block access to the external libraries accessed by the application.
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						Monitor the behavior of the system to see if it goes into an insecure/inconsistent state.
					</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>
						If the system does go into an insecure/inconsistent state, leverage that to obtain information about the system functionality or data, elevate access control, etc.  The rest of this attack will depend on the context and the desired goal.
					</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				An application requires access to external libraries.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
			   An attacker has the priviliges to block application access to external libraries.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Medium</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				A web-based system uses a third party cryptographic random number generation library that derives entropy from machine's hardware.  This library is used in generation of user session ids used by the applicatoin.  If the library is inaccessible, the application instead uses a software based weak pseudo random number generation library.  An attacker of the system blocks access of the application to the third party cryptographic random number generation library (by renaming it).  The application in turn uses the weak pseudo random number generation library to generate session ids that are predictable.  An attacker then leverages this weakness to guess a session id of  another user to perform a horizontal elevation of privilege escalation and gain access to another user's account.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low
		</Attacker_Skill_or_Knowledge_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
			Ensure that application handles situations where access to APIs in external libraries is not available securely. If the application cannot continue its execution safely it should fail in a consistent and secure fashion.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>589</CWE_ID>
				<Weakness_Name> Call to Limited API</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>227</CWE_ID>
				<Weakness_Name>API Abuse</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Security_Principles>
			<Related_Security_Principle>Failing Securely</Related_Security_Principle>
		</Related_Security_Principles>
		<Purpose>Exploitation</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Low</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>Sean Barnum</Submitter>
				<Submitter_Organization>Cigital, Inc.</Submitter_Organization>
				<Submission_Date>2007-03-25</Submission_Date>
				<Submission_Comment>Identified priority for pattern creation</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Evgeny Lebanidze</Modifier>
				<Modifier_Organization>Cigital, Inc.,</Modifier_Organization>
				<Modification_Date>2007-03-21</Modification_Date>
				<Modification_Comment>Fleshed out content for pattern</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-16</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="8" Name="Buffer Overflow in an API Call">
		<Description>
			<Summary>
		This attack targets libraries or shared code modules which are vulnerable to buffer overflow attacks. An attacker who has access to an API may try to embed malicious code in the API function call and exploit a buffer overflow vulnerability in the function's implementation. All clients that make use of the code library thus become vulnerable by association. This has a very broad effect on security across a system, usually affecting more than one software process. </Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>1- An attacker can call an API exposed by the target host.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>2- On the probing stage, the attacker injects malicious code using the API call and observes the results. The attacker's goal is to uncover a buffer overflow vulnerability.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>3- The attacker finds a buffer overflow vulnerability, crafts malicious code and injects it through an API call. The attacker can at worst execute remote code on the target host.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>The target host exposes an API to the user.</Attack_Prerequisite>
			<Attack_Prerequisite>One or more API functions exposed by the target host has a buffer overflow vulnerability.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Attack Example: Libc in FreeBSD

A buffer overflow in the FreeBSD utility setlocale (found in the libc module) puts many programs at risk all at once.
</Example-Instance_Description>
			</Example-Instance>
			<Example-Instance>
				<Example-Instance_Description>Xtlib

A buffer overflow in the Xt library of the X windowing system allows local users to execute commands with root privileges.
</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector.  The result can be a DoS.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.</Attacker_Skill_or_Knowledge_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Use a language or compiler that performs automatic bounds checking.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Use secure functions not vulnerable to buffer overflow.</Solution_or_Mitigation>
			<Solution_or_Mitigation>If you have to use dangerous functions, make sure that you do boundary checking.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Use OS-level preventative functionality. Not a complete solution.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Injection_Vector>The user supplied data.</Injection_Vector>
		<Payload>The buffer overrun by the attacker.</Payload>
		<Activation_Zone>When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.</Activation_Zone>
		<Payload_Activation_Impact>The most common is remote code execution.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>120</CWE_ID>
				<Weakness_Name>Unbounded Transfer ('classic overflow')</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>119</CWE_ID>
				<Weakness_Name>Buffer Errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>118</CWE_ID>
				<Weakness_Name>Range errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>100</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Relevant_Security_Requirements>
			<Relevant_Security_Requirement>Bound checking should be performed when copying data to a buffer.</Relevant_Security_Requirement>
		</Relevant_Security_Requirements>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to trust</Related_Security_Principle>
			<Related_Security_Principle>Defense in Depth</Related_Security_Principle>
		</Related_Security_Principles>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Reference>
			<Reference>CWE – Buffer Errors</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eric Dalci</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-13</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Description</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="9" Name="Buffer Overflow in Local Command-Line Utilities">
		<Description>
			<Summary>This attack targets command-line utilities available in a number of shells. An attacker can leverage a vulnerability found in a command-line utility to escalate privilege to root.</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>1- Attacker identifies command utilities exposed by the target host.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>2- On the probing stage, the attacker interacts with the command utility and observes the results of its input. The attacker's goal is to uncover a buffer oveflow in the command utility. For instance the attacker may find that input data are not properly validated.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>3- The attacker finds a buffer overflow vulnerability in the command utility and tries to exploit it. He crafts malicious code and injects it using the command utility. The attacker can at worst execute remote code on the target host.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>The target host exposes a command-line utility to the user.</Attack_Prerequisite>
			<Attack_Prerequisite>The command-line utility exposed by the target host has a buffer overflow vulnerability that can be exploited.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Attack Example: HPUX passwd

A buffer overflow in the HPUX passwd command allows local users to gain root privileges via a command-line option.&lt;/AttackExample&gt;
&lt;AttackExample&gt;Attack Example: Solaris getopt

A buffer overflow in Solaris’s getopt command (found in libc) allows local users to gain root privileges via a long argv[0].
</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector.  The result can be a DoS.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.</Attacker_Skill_or_Knowledge_Required>
		<Probing_Techniques>
			<Probing_Technique>The attacker can probe for services available on the target host. Many services may expose a command utility. For instance Telnet is a service which can be invoked through a command shell.</Probing_Technique>
		</Probing_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Carefully review the service's implementation before making it available to user. For instance you can use manual or automated code review to uncover vulnerabilities such as buffer overflow.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Use a language or compiler that performs automatic bounds checking.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Use an abstraction library to abstract away risky APIs. Not a complete solution.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Operational: Use OS-level preventative functionality. Not a complete solution.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Apply the latest patches to your user exposed services. This may not be a complete solution, specially against zero day attack.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Do not unnecessarily expose services.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Injection_Vector>The user supplied data.</Injection_Vector>
		<Payload>The buffer overrun by the attacker.</Payload>
		<Activation_Zone>When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.</Activation_Zone>
		<Payload_Activation_Impact>The most common is remote code execution.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>120</CWE_ID>
				<Weakness_Name>Unbounded Transfer ('classic overflow')</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>118</CWE_ID>
				<Weakness_Name>Range errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>119</CWE_ID>
				<Weakness_Name>Buffer Errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>100</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>10</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to trust</Related_Security_Principle>
			<Related_Security_Principle>Defense in Depth</Related_Security_Principle>
			<Related_Security_Principle>Least Privilege</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Bound checking should be performed when copying data to a buffer.</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Reference>
			<Reference>CWE – Buffer Errors</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eric Dalci</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-13</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Attack Execution Flow, Probing Techniques and Method of Attack</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="10" Name="Buffer Overflow via Environment Variables">
		<Description>
			<Summary>
		This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>1- The attacker tries to find an environment variable which can be overwritten for instance by gathering information about the target host (error pages, software's version number, etc.). </Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>2- The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>3- The attacker potentially leverages the buffer overflow to inject maliciously crafted code in an attempt to execute privileged command on the target environment.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>The application uses environment variables.</Attack_Prerequisite>
			<Attack_Prerequisite>An environment variable exposed to the user is vulnerable to a buffer overflow.</Attack_Prerequisite>
			<Attack_Prerequisite>The vulnerable environment variable uses untrusted data.</Attack_Prerequisite>
			<Attack_Prerequisite>Tainted data used in the environment variables is not properly validated. For instance boundary checking is not done before copying the input data to a buffer.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Attack Example: Buffer Overflow in $HOME

A buffer overflow in sccw allows local users to gain root access via the $HOME environmental variable.
</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability>CVE-1999-0906</Example-Instance_Related_Vulnerability>
			</Example-Instance>
			<Example-Instance>
				<Example-Instance_Description>Attack Example: Buffer Overflow in TERM

A buffer overflow in the rlogin program involves its consumption of the TERM environmental variable.
</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability>CVE-1999-0046</Example-Instance_Related_Vulnerability>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
		Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector.  The result can be a DoS.
		High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.</Attacker_Skill_or_Knowledge_Required>
		<Probing_Techniques>
			<Probing_Technique>While interacting with a system an attacker would typically investigate for environment variables that can be overwritten. The more a user knows about a system the more likely she will find a vulnerable environment variable.</Probing_Technique>
			<Probing_Technique>On a web environment, the attacker can read the client side code and search for environment variables that can be overwritten.</Probing_Technique>
			<Probing_Technique>There are tools such as Sharefuzz (http://sharefuzz.sourceforge.net/) which is an environment variable fuzzer for Unix that support loading a shared library. Attackers can use such tools to uncover a buffer overflow in an environment variable.</Probing_Technique>
		</Probing_Techniques>
		<Indicators-Warnings_of_Attack>
			<Indicator-Warning_of_Attack>If the application does bound checking, it should fail when the data source is larger than the size of the destination buffer. If the application's code is well written, that failure should triger an alert.</Indicator-Warning_of_Attack>
		</Indicators-Warnings_of_Attack>
		<Obfuscation_Techniques>
			<Obfuscation_Technique/>
		</Obfuscation_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Do not expose environment variable to the user.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Do not use untrusted data in your environment variables.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Use a language or compiler that performs automatic bounds checking</Solution_or_Mitigation>
			<Solution_or_Mitigation>There are tools such as Sharefuzz (http://sharefuzz.sourceforge.net/) which is an environment variable fuzzer for Unixes that support loading a shared library. You can use Sharefuzz to determine if you are exposing an environment variable vulnerable to buffer overflow.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Injection_Vector>The user modifiable environment variable.</Injection_Vector>
		<Payload>User supplied data potentially containing malicious code.</Payload>
		<Activation_Zone>When the subroutine which uses the environment variable returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.</Activation_Zone>
		<Payload_Activation_Impact>The most common is remote code execution.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>120</CWE_ID>
				<Weakness_Name>Unbounded Transfer ('classic overflow')</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>302</CWE_ID>
				<Weakness_Name>Authenticaiton Bypass by Assumed-Immutable Data</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>118</CWE_ID>
				<Weakness_Name>Range errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>119</CWE_ID>
				<Weakness_Name>Buffer Errors</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>99</CWE_ID>
				<Weakness_Name>Resource Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>100</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to trust</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Bound checking should be performed when copying data to a buffer.</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Reference>
			<Reference>CWE – Buffer Errors</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eric Dalci</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-13</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="11" Name="Cause Web Server Misclassification">
		<Description>
			<Summary>
			An attack of this type exploits a Web server's decision to take action based on filename or file extension. Because different file types are handled by different server processes, misclassification may force the Web server to take unexpected action, or expected actions in an unexpected sequence. This may cause the server to exhaust resources, supply debug or system data to the attacker, or bind an attacker to a remote process.
			This type of vulnerability has been found in many widely used servers including IIS, Lotus Domino, and Orion. The attacker's job in this case is straightforward, standard communication protocols and methods are used and are generally appended with malicious information at the tail end of an otherwise legitimate request. The attack paylod varies, but it could be special characters like a period or simply appending a tag that has a special meanning for operations on the server side like .jsp for a java application server. The essence of this attack is that the attacker deceives the server into executing functionality based on the name of the request, i.e. login.jsp, not the contents.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Web server software must rely on file name or file extension for processing.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				J2EE application servers are supposed to execute Java Server Pages (JSP). There have been disclosure issues relating to Orion Application Server, where an attacker that appends either a period (.) or space characters to the end of a legitimate Http request, then the server displays the full source code in the attacker's web browser. 
				
				http://victim.site/login.jsp.
				
				Since remote data and directory access may be accessed directly from the JSP, this is a potentially very serious issue.
				Reference http://www.securityfocus.com/bid/17204/info
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → To modify file name or file extension
			Medium →  To use misclassification to force the Web server to disclose configuration information, source, or binary data
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to execute HTTP request to Web server
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Implementation: Server routines should be determined by content not determined by filename or file extension.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Cause Web Server Misclassification
		A very famous set of classification problems occurs when a Web server examines the last few characters of a filename to determine what kind of file it is. There are many ways to take advantage of these kinds of problems-appending certain strings to filenames, adding dots, and so forth."
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard Web application calls, e.g. HTTP Request.
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. Malicious payload may alter or append filename or extension to communicate with processes in unexpected order.
		</Payload>
		<Activation_Zone>
			Client machine and client network 
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to force web server to disclose configuration, source, and data
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<!-- New CWE needed to describe the general weakness targeted by this attack -->
			<Related_Weakness>
				<CWE_ID>69</CWE_ID>
				<Weakness_Name>
					Windows:: DATA alternate data stream
				</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>77</CWE_ID>
				<Weakness_Name>
					Command Injection</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Purpose>Reconnaissance</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="12" Name="Choosing a Message/Channel Identifier on a Public/Multicast Channel">
		<Description>
			<Summary>Attackers aware that more data is being fed into a multicast or public information distribution means can 'select' information bound only for another client, even if the distribution means itself forces users to authenticate in order to connect initally. 
			Doing so allows the attacker to gain access to possibly privileged information, possibly perpetrate other attacks through the distribution means by impersonation.
			If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could change its identifier from a less privileged to more so privileged channel or command.
		</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>Determine the nature of messages being transported as well as the identifiers to be used as part of the attack</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>If required, authenticate to the distribution channel</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>If any particular client's information is available through the transport means simply by selecting a particular identifier, an attacker can simply provide that particular identifier.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>Attackers with client access connecting to output channels could change their channel identifier and see someone else's (perhaps more privileged) data.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Information and client-sensitive (and client-specific) data must be present through a distribution channel available to all users.
			</Attack_Prerequisite>
			<Attack_Prerequisite>Distribution means must code (through channel, message identifiers, or convention) message destination in a manner visible within the distribution means itself (such as a control channel) or in the messages themselves.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
			A certain B2B interface on a large application codes for messages passed over a MQSeries queue, on a single "Partners" channel. Messages on that channel code for their client destination based on a partner_ID field, held by each message. That field is a simple integer. Attackers having access to that channel, perhaps a particularly nosey partner, can simply choose to store messages of another parnter's ID and read them as they desire. Note that authentication does not prevent a partner from leveraging this attack on other partners. It simply disallows Attackers without partner status from conducting this attack.</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: All the attacker needs to discover is the format of the messages on the channel/distribution means and the particular identifier used within the messages.</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>The Attacker needs the ability to control source code or application configuration responsible for selecting which message/channel id is absorbed from the public distribution means.
		</Resources_Required>
		<Probing_Techniques>
			<Probing_Technique>Assisted protocol analysis: because the protocol under attack is a public channel, or one in which the attacker likely has authorized access to, they need simply to decode the aspect of channel or message interpretation that codes for message identifiers. 
			Probing is as simple as changing this value and watching its effect.
			</Probing_Technique>
		</Probing_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Associate some ACL (in the form of a token) with an authenticated user which they provide middleware. The middleware uses this token as part of its channel/message selection for that client, or part of a discerning authorization decision for privileged channels/messages. 
			The purpose is to architect the system in a way that associates proper authentication/authorization with each channel/message.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>Rearchitect system input/output channels as appropriate to distribute self-protecting data. That is, encrypt (or otherwise protect) channels/messages so that only authorized readers can see them.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>This pattern applies in circumstances in which publically accessible distribution means code (through channel, message identifiers, or convention) for client-specific subscription information about messages being distributed. Commonly, this will happen over message-oriented middleware buses, multicast channels, or feeds.
		</Context_Description>
		<Related_Weaknesses>
			<!-- New CWE needed titled "Access Control Bypass Through User-Controlled Key" as parent to "Access Control Bypass Through User-Controlled SQL Primary Key" -->
			<Related_Weakness>
				<CWE_ID>201</CWE_ID>
				<Weakness_Name>Information Leak Through Sent Data</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>306</CWE_ID>
				<Weakness_Name>No Authentication for Critical Function</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>21</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Similar</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Complete Mediation</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Use Authentication Mechanisms, Where Appropriate, Correctly</Related_Guideline>
			<Related_Guideline>Use Authorization Mechanisms Correctly: this refers to Ambiguity of authentication. Many authorization systems use ambiguous symbols (i.e., principal names) to identify principals allowing circumvention of authorization by using a different, though equivalent, principal name. For example, there are many implementations for restricting remote host access to local services that may allow many proper—but apparently different—names for unique hosts (e.g., fully qualified domain names, shortened names, CNAMEs, IPv4 addresses, IPv6 addresses). </Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
			<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
			<Architectural_Paradigm>SOA</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>John Steven</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-10</Submission_Date>
				<Submission_Comment>Initial core pattern content</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Chiradeep B. Chhaya</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-23</Modification_Date>
				<Modification_Comment>Fleshed out pattern with extra content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Description and Related Attack Patterns</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
	<Attack_Pattern CAPEC_ID="13" Name="Subverting Environment Variable Values">
		<Description>
			<Summary>The attacker directly or indirectly modifies environment variables used by or controlling the target software.  The attacker’s goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker.</Summary>
			<Attack_Execution_Flow>
				<Attack_Step>
					<Attack_Step_Description>1- The attacker probes the application for information. Which version of the application is running? Are there known environment variables? etc.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>2- The attacker gains control of an environment variable and ties to find out what process(es) the environment variable controls.</Attack_Step_Description>
				</Attack_Step>
				<Attack_Step>
					<Attack_Step_Description>3- The attacker modifies the environment variable to abuse the normal flow of processes or to gain access to privileged ressources.</Attack_Step_Description>
				</Attack_Step>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>An environment variable is accessible to the user.</Attack_Prerequisite>
			<Attack_Prerequisite>An environment variable used by the application can be tainted with user supplied data.</Attack_Prerequisite>
			<Attack_Prerequisite>Input data used in an environment variable is not validated properly.</Attack_Prerequisite>
			<Attack_Prerequisite>The variables encapsulation is not done properly. For instance setting a variable as public in a class makes it visible and an attacker may attemp to manipulate that variable.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
			<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Environment variables 

Changing the LD_LIBRARY_PATH environment variable in TELNET will cause TELNET to use an alternate (possibly Trojan) version of a function library. The Trojan library must be accessible using the target file system and should include Trojan code that will allow the user to log in with a bad password. This requires that the attacker upload the Trojan library to a specific location on the target.

As an alternative to uploading a Trojan file, some file systems support file paths that include remote addresses, such as \\172.16.2.100\shared_files\trojan_dll.dll.
</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability>Path Manipulation (CVE-1999-0073)</Example-Instance_Related_Vulnerability>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: In a web based scenario, the client controls the data that it submitted to the server. So anybody can try to send malicious data and try to bypass the authentication mechanism. 

Medium/High: Some more advanced attacks may require knowledge about protocols and probing technique which help controling a variable. The malicious user may try to understand the authentication mechanism in order to defeat it.</Attacker_Skill_or_Knowledge_Required>
		<Probing_Techniques>
			<Probing_Technique>An attacker can intentionally modify the client side parameter and monitor how the server behaves in response to that modification. For instance an attacker will look at the cookie data, the URL parameters, the hidden variables in forms, variables used in system calls, etc. </Probing_Technique>
			<Probing_Technique>If the client uses a program in binary format to connect to the server, disassembler can be used to identify parameter within the binary code, and then the attacker would try to simulate the client application and change some of the parameters sent to the server. For instance the attacker may find that a secret key or a path is hard coded in the binary client application.</Probing_Technique>
			<Probing_Technique>Environment variables are frequently stored in cleartext configuration files. If the attacker can modify those configuration files, he can control the environment variables. Even a read access can potentially be dangerous since this may give sensitive information to perform this type of attack. Indeed knowing which environment variables the application uses is a prerequisite to this type of attack.</Probing_Technique>
		</Probing_Techniques>
		<Obfuscation_Techniques>
			<Obfuscation_Technique>The attacker may try to obfuscate its attempts to subvert the target process (such as authentication) by using valid values for the variable she controls. By using valid values the user tries to understand the authentication mechanism. This would be in preparation to a more serious attack.</Obfuscation_Technique>
		</Obfuscation_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Protect environment variables against unauthorized read and write access.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Protect the configuration files which contain environment variables against illegitimate read and write access.</Solution_or_Mitigation>
			<Solution_or_Mitigation>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 not be permitted to enter into the system.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Apply the least privilege principles. If a process has no legitimate reason to read an environment variable do not give that privilege.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description/>
		<Injection_Vector>The client controlled parameter</Injection_Vector>
		<Payload>The new value of the client controlled parameter.</Payload>
		<Activation_Zone>The activation zone is the server side function where the client controlled parameter is consumed.</Activation_Zone>
		<Payload_Activation_Impact>Consuming an attacker contolled parameter can defeat the normal process of the application.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>353</CWE_ID>
				<Weakness_Name>Failure to add integrity check value</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>285</CWE_ID>
				<Weakness_Name>Missing or Inconsistent Access Control</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>302</CWE_ID>
				<Weakness_Name>Authenticaiton Bypass by Assumed-Immutable Data</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>74</CWE_ID>
				<Weakness_Name>Injection</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>15</CWE_ID>
				<Weakness_Name>Setting Manipulation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>73</CWE_ID>
				<Weakness_Name>Path Manipulation</Weakness_Name>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>20</CWE_ID>
				<Weakness_Name>Input Validation</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>200</CWE_ID>
				<Weakness_Name>Information Leak (information disclosure)</Weakness_Name>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Vulnerabilities>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-4244</Vulnerability_ID>
				<Vulnerability_Description>SQL-Ledger 2.4.4 through 2.6.17 authenticates users by verifying that the value of the sql-ledger-[username] cookie matches the value of the sessionid parameter, which allows remote attackers to gain access as any logged-in user by setting the cookie and the parameter to the same value.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-2734</Vulnerability_ID>
				<Vulnerability_Description>enter.asp in Mini-Nuke 2.3 and earlier makes it easier for remote attackers to conduct password guessing attacks by setting the guvenlik parameter to the same value as the hidden gguvenlik parameter, which bypasses a verification step because the guvenlik parameter is assumed to be immutable by the attacker.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-2527</Vulnerability_ID>
				<Vulnerability_Description>Admin/admin.php in phpBazar 2.1.0 and earlier allows remote attackers to bypass the authentication process and gain unauthorized access to the administrative section by setting the action parameter to edit_member and the value parameter to 1.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-1505</Vulnerability_ID>
				<Vulnerability_Description>base_maintenance.php in Basic Analysis and Security Engine (BASE) before 1.2.4 (melissa), when running in standalone mode, allows remote attackers to bypass authentication, possibly by setting the standalone parameter to &quot;yes&quot;.</Vulnerability_Description>
			</Related_Vulnerability>
		</Related_Vulnerabilities>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>77</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>76</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Abstract</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>14</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Occasionally Precedes</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>10</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Similar</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to trust</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Always perform wise data validation. Do not accept tainted data without validation. Do not simply base authentication on the client controlled parameter.</Related_Guideline>
			<Related_Guideline>Avoid relying on client side validation only.</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Reference>
			<Reference>CWE – Input Validation</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eric Dalci</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-13</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Description and Related Attack Patterns</Modification_Comment