<?xml version="1.0" encoding="UTF-8"?>

<Attack_Pattern_Catalog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Catalog_Name="CAPEC"
	Catalog_Version="1.4" Catalog_Date="2009-09-22"
	xsi:noNamespaceSchemaLocation="http://capec.mitre.org/data/xsd/ap_schema_v2.0.xsd">
	<Views>
		<View ID="1000" Name="Mechanism of Attack" Status="Draft">
			<View_Structure>Graph</View_Structure>
			<View_Objective/>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>118<!--Data Leakage Attacks--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>119<!--Resource Depletion--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>152<!--Injection (Injecting Control Plane content through the Data Plane)--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>156<!--Spoofing--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>172<!--Time and State Attacks--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>210<!--Abuse of Functionality--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>223<!--Probabilistic Techniques--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>225<!--Exploitation of Authentication--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>232<!--Exploitation of Privilege/Trust--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>255<!--Data Structure Attacks--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>262<!--Resource Manipulation--></Relationship_Target_ID>
				</Relationship>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>HasMember</Relationship_Nature>
					<Relationship_Target_ID>286<!--Network Reconnaissance--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</View>
		<View ID="2000" Name="Comprehensive CAPEC Dictionary" Status="Draft">
			<View_Structure>Implicit_Slice</View_Structure>
			<View_Objective>
				<Text>This view (slice) covers all the elements in CAPEC.</Text>
			</View_Objective>
			<View_Filter>true()</View_Filter>
		</View>
		<View ID="282" Name="Meta Abstractions" Status="Draft">
			<View_Structure>Implicit_Slice</View_Structure>
			<View_Objective>
				<Text>This view (slice) covers meta abstraction attack patterns.</Text>
			</View_Objective>
			<View_Filter>.//@Pattern_Abstraction='Meta'</View_Filter>
		</View>
		<View ID="283" Name="Standard Abstractions" Status="Draft">
			<View_Structure>Implicit_Slice</View_Structure>
			<View_Objective>
				<Text>This view (slice) covers standard abstraction attack patterns.</Text>
			</View_Objective>
			<View_Filter>.//@Pattern_Abstraction='Standard'</View_Filter>
		</View>
		<View ID="284" Name="Detailed Abstractions" Status="Draft">
			<View_Structure>Implicit_Slice</View_Structure>
			<View_Objective>
				<Text>This view (slice) covers detailed abstraction attack patterns.</Text>
			</View_Objective>
			<View_Filter>.//@Pattern_Abstraction='Detailed'</View_Filter>
		</View>
	</Views>
	<Categories>
		<Category ID="118" Name="Data Leakage Attacks" Status="Draft">
			<Description>
				<Description_Summary>An attacker uses well-formed requests to an application,
					service, or device that results in the inadvertant disclosure of sensitive
					information by exploiting weaknesses in the design or configuration of the
					target resulting in the target revealing more information to an attacker than
					intended. The attacker may collect this information through a variety of methods
					including active querying as well as passive observation. Information may
					include details regarding the configuration or capabilities of the target, clues
					as to the timing or nature of activities, or otherwise sensitive information.
					Often this sort of attack is undertaken in preparation for some other type of
					attack, although the collection of information may be the end goal of the
					attacker in some cases. Information retrieved may aid the attacker in making
					inferences about potential weaknesses, vulnerabilities, or techniques that
					assist the attacker's objectives. Data leaks may come various forms, including
					confidential information stored in inscure directories, or via services that
					provide rich error or diagnostic messages in response to normal
					queries.</Description_Summary>
			</Description>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>404</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target must have some piece of sensitive information that can
						collected by an attacker.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>The attacker must have tools to collect the information from the target. This
					requires a client capable of interacting with the target. For web applications,
					a web browser or tools such as MITM (Man-In-the-Middle) Proxy.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="119" Name="Resource Depletion" Status="Draft">
			<Description>
				<Description_Summary>An attacker depletes a resource to the point that the target's
					functionality is affected. Virtually any resource necessary for the target's
					operation can be targeted in this attack. The result of a successful resource
					depletion attack is usually the degrading or denial of one or more services
					offered by the target. Resources required will depend on the nature of the
					resource to be depleted, the amount of the resource the target has access to,
					and other mitigating circumstances such as the target's ability to shift load,
					detect and mitigate resource depletion attacks, or acquire additional resources
					to deal with the depletion. The more protected the resource and the greater the
					quantity of it that must be consumed, the more resources the attacker will need
					to have at their disposal.</Description_Summary>
			</Description>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>404</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target must rely on a vulnerable resource for its operations and be
						unable to replace it in a reasonable amount of time if it is
						unavailable.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The attacker must have the ability to consume, destroy, or disrupt a
						resource required for normal operation of the target.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>In order to deplete the target's resources the attacker must interact with the
					target in a programmatic way. Depending on the nature of the resource the
					attacker may need a client or script capable of making repeated requests over a
					network, or the ability to craft specific requests, such as an HTTP request
					containing thousands of slashes. If the attacker has some privileges on the
					system the required resource will likely be the ability to run a binary or
					upload a compiled exploit, or write and execute a script or program that
					consumes resources. Depending on the defenses of the targeted system, the
					attacker may need access to extensive computational and network resources in
					order to overwhelm the target.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="126" Name="Path Traversal" Status="Draft">
			<Description>
				<Description_Summary>An attacker uses path manipulation methods to exploit
					insufficient input validation of a target to obtain access to data that should
					be not be retrievable by ordinary well formed requests. A typical variety of
					this attack involves specifiying a path to a desired file together with
					dot-dot-slash characters, resulting in the file access API or function
					traversing out of the intended directory structure and into the root file
					system. By replacing or modifying the expected path information the access
					function or API retrieves the file desired by the attacker.These attacks either
					involve the attacker providing a complete path to a targeted file or using
					control characters (e.g. path separators (/ or \) and/or dots (.)) to reach
					desired directories or files.</Description_Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The attacker must be able to control the path that is requested of the
						target.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The target must fail to adequately sanitize incoming paths</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>The ability to manually manipulate path information either directly through a
					client application relative to the service or application or via a proxy
					application.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>154<!--Resource Location Attacks--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="152" Name="Injection (Injecting Control Plane content through the Data Plane)"
			Status="Draft">
			<Description>
				<Description_Summary>An attacker is able to control or disrupt the behavior of an
					target through crafted input data submitted using an interface functioning to
					process data input. This happens when the attacker adds material to their input
					that is interpreted by the application causing the targeted application to
					perform steps unintended by the application manager or causing the application
					to enter an unstable state. This attack differs from Data Structure Attacks in
					that the latter attacks subvert the underlying structures that hold
					user-provided data, either pre-empting interpretation of the input (in the case
					of Buffer Overflows) or resulting in values that the targeted application is
					unable to handle correctly (in the case of Integer Overflows). In Injection
					attacks, the input is interpreted by the application, but the attacker has
					included instructions to the interpreting functions that the target application
					then follows.</Description_Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target application must accept input from the user. In virtually all
						cases, this must be string input.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The attacker must fail to adequately filter the user input against the
						insertion of instructions to the input interpreter.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>No special resources are required for most variants of this attack.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="156" Name="Spoofing" Status="Draft">
			<Description>
				<Description_Summary>An attacker constructs a message such that the constructed
					message is capable of masquerading as an authorized message from some other
					principal. As a result, consumers of these messages can be manipulated into
					responding or processing the deceptive message. Spoofing attacks assume that
					some piece of content or functionality is associated with an identity and that
					the content is trusted by the target because of this association. Spoofing
					refers to the falsification of the content and/or identity in such a way that
					the target will incorrectly trust the legitimacy of the content. The attacker
					then uses this content to execute an attack. For example, an attacker may modify
					a financial transaction between two parties so that the participants remain
					unchanged but the amount of the transaction is increased. If the recipient
					cannot detect the change, they may incorrectly assume the modified message
					originated with the original sender. Spoofing may involve an attacker crafting
					the content from scratch or capturing and modifying legitimate
					content.</Description_Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The targeted content must be associated (possibly implicitly) with an
						identity and the targeted application or user must hold some trust about the
						content this identity is providing.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text> The attacker must be able to change the content, identity, or both in a
						way that is not detectable to the recipient and the recipient must fail to
						verify authenticity to the supposed source of the data. Cryptographic
						identity verification schemes can prevent this type of attack.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>No special resources are required for most versions of this attack. If the
					attack involves modification of ongoing transactions, the attacker must be able
					to intercept communications between the sender and the target.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="172" Name="Time and State Attacks" Status="Draft">
			<Description>
				<Description_Summary>An attacker exploits weaknesses in timing or state maintaining
					functions to perform actions that would otherwise be prevented by the execution
					flow of the target code and processes. An example of a state attack might
					include manipulation of an application's information to change the apparent
					credentials or similar information, possibly allowing the application to access
					material it would not normally be allowed to access. A common example of a
					timing attack is a test-action race condition where some state information is
					tested and, if it passes, an action is performed. If the attacker can change the
					state between the time that the application performs the test and the time the
					action is performed, then they might be able to manipulate the outcome of the
					action to malicious ends.</Description_Summary>
			</Description>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>665</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Virtually all applications can be subject to time or state attacks in some
						form.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Resources_Required>
				<Text>State attacks require the ability to manipulate the underlying state of an
					application. If that state is stored in a simple file, this can be relatively
					easy. If the state is stored internally, this can be more difficult. Timing
					attacks rely on being able to control when an application's thread is
					interrupted in order to insert the malicious action. Even then, if the actions
					in the sequence happen quickly, then success can largely be a matter of luck. As
					such, having many opportunities to attempt the attack is usually a requirement
					since and individual attack may have a low probability of success.</Text>
			</Resources_Required>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="210" Name="Abuse of Functionality" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="212" Name="Functionality Misuse" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>210<!--Abuse of Functionality--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="216" Name="Abuse of Communication Channels" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>210<!--Abuse of Functionality--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="223" Name="Probabilistic Techniques" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="224" Name="Fingerprinting" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>281<!--Analytic Attacks--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="225" Name="Exploitation of Authentication" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="232" Name="Exploitation of Privilege/Trust" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="233" Name="Privilege Escalation" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>232<!--Exploitation of Privilege/Trust--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="253" Name="Remote Code Inclusion" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>152<!--Injection (Injecting Control Plane content through the Data Plane)--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="255" Name="Data Structure Attacks" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="262" Name="Resource Manipulation" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>View</Relationship_Target_Form>
					<Relationship_Nature>MemberOf</Relationship_Nature>
					<Relationship_Target_ID>1000<!--Mechanism of Attack--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
		<Category ID="278" Name="Web Services Protocol Manipulation" Status="Draft">
			<Description>
				<Description_Summary/>
			</Description>
			<Relationships>
				<Relationship>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Category</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>272<!--Protocol Manipulation--></Relationship_Target_ID>
				</Relationship>
			</Relationships>
		</Category>
	</Categories>
	<Attack_Patterns>
		<Attack_Pattern ID="1" Name="Accessing Functionality Not Properly Constrained by ACLs"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Survey</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker surveys the target application,
												possibly as a valid and authenticated user</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Spidering web sites for all available
												links</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Brute force guessing of resource
												names</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Brute force guessing of user names /
												credentials</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Brute force guessing of function names /
												actions</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>ACLs or other access control mechanisms are
												present in the software</Text>
												</Indicator_Description>
												<Environments>env-Web
												env-ClientServer</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>User IDs or other credentials are present in
												the software</Text>
												</Indicator_Description>
												<Environments>env-Web
												env-ClientServer</Environments>
											</Indicator>
											<Indicator ID="3" type="Positive">
												<Indicator_Description>
												<Text>Operating modes with different privileges
												are present in the software</Text>
												</Indicator_Description>
												<Environments>env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
										</Indicators>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Identify
											Functionality</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>At each step, the attacker notes the resource or
												functionality access mechanism invoked upon
												performing specific actions</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use the web inventory of all forms and
												inputs and apply attack data to those
												inputs.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Use a packet sniffer to capture and record
												network traffic</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-CommProtocol</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Execute the software in a debugger and
												record API calls into the operating system or
												important libraries. This might occur in an
												environment other than a production environment,
												in order to find weaknesses that can be exploited
												in a production environment.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The attacker produces a list of
												functionality or data that can be accessed through
												the system.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Iterate over access
											capabilities</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Possibly as a valid user, the attacker then tries
												to access each of the noted access mechanisms
												directly in order to perform functions not
												constrained by the ACLs.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Fuzzing of API parameters (URL parameters,
												OS API parameters, protocol parameters)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-Local env-Embedded
												env-ClientServer</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Negative">
												<Indicator_Description>
												<Text>Attempts to create a catalog of access
												mechanisms and data have failed.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Functionality is accessible to
												unauthorized users.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The application must be navigable in a manner that associates elements
						(subsections) of the application with ACLs.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The various resources, or individual URLs, must be somehow discoverable by
						the attacker</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The deployer must have forgotten to associate an ACL or has associated an
						inappropriately permissive ACL with a particular navigable resource.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very High</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
						<Text>If no security-constraint is placed on those Action Servlets, such
							that positively no one can access them, the front controller can be
							subverted.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>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
							access those access mechanisms directly.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>No special resources are required for the exploit of this pattern.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>More generally, noting the target resource accessed upon performing
						specific actions drives an understanding of the resources accessible from
						the current context.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>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.</Text>
					<Text>Having done so, any direct access to those protected Servlets will be
						prohibited by the web container.</Text>
					<Text>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.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>285</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>276</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>721</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>122<!--Exploitation of Authorization--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>All resources must be constrained to be inaccessible by default followed
						by selectively allowing access to resources as dictated by application and
						business logic</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>In addition to a central controller, every resource must also restrict,
						wherever possible, incoming accesses as dictated by the relevant ACL.</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Failing Securely</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Reluctance To Trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Complete Mediation</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Use Authorization Mechanisms Correctly</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Design Configuration Subsystems Correctly and Distribute Safe Default
						Configurations</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
					<Modification>
						<Modifier>Paco Hope</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-20</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="2" Name="Inducing Account Lockout" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Investigate account lockout behavior of
											system</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Investigate the security features present in the
												system that may trigger an account lockout</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Analyze system documentation to find list of
												events that could potentially cause account
												lockout</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Obtain user account in system and attempt to
												lock it out by sending malformed or incorrect data
												repeatedly</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Determine another user's login ID, and
												attempt to brute force the password (or other
												credentials) for it a predetermined number of
												times, or until the system provides an indication
												that the account is locked out.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>System provides error message stating that
												account being attacked is locked out.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>After a certain number of login attempts
												with a given user ID, the amount of time it takes
												for system to respond to further login attempts
												changes noticably.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
											<Indicator ID="3" type="Negative">
												<Indicator_Description>
												<Text>System has no automatic signup mechanism,
												and system provides no indication as to whether
												the attacker is entering incorrect credentials or
												the account is locked out during the login
												process.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker determines at least
												one way to lock out
												accounts.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>System provides no indication
												that account lockouts are
												possible</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Repeated failed login
												attempts in application/system
												logs.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Do not provide any
												indication to users that their accounts are locked
												out. Provide a simple error message such as:
												"Login failed. Try again or contact your
												administrator" regardless of why a login attempt
												fails.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Obtain list of user accounts to lock
											out</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Generate a list of valid user accounts to lock
												out</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Obtain list of authorized users using
												another attack pattern, such as SQL
												Injection.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Attempt to create accounts if possible;
												system should indicate if a user ID is already
												taken.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Attempt to brute force user IDs if system
												reveals whether a given user ID is valid or not
												upon failed login attempts.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>System indicates which user IDs are valid
												and which are not to unauthenticated users.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker gathers list of user
												IDs</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Inconclusive">
												<Outcome_Description>Attacker is unable to gather
												list of valid user IDs; attacker may still be able
												to lock out accounts by blindly guessing user IDs
												and performing a lockout procedure with each
												one.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>Avoid providing any
												indication regarding the validity of user IDs upon
												failed login attempts. Provide a simple error
												message such as: "Login failed. Try again or
												contact your administrator" regardless of why a
												login attempt
												fails.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Lock Out Accounts</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Perform lockout procedure for all accounts that
												the attacker wants to lock out.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>For each user ID to be locked out, perform
												the lockout procedure discovered in the first
												step.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Success outcome in first step</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Failure outcome in first step</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Amount of work required by an
												attacker to lock out a large number of accounts is
												at least an order of magnitude smaller than the
												amount of work required to unlock the accounts
												thereafter.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>The large amount of work
												required by an attacker to lock out a large number
												of accounts makes this an unattractive
												attack.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The system has a lockout mechanism.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>An attacker must be able to reproduce behavior that would result in an
						account being locked.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Medium</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Computer with access to the login portion of the target system</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Implement intelligent password throttling mechanisms such as those which
						take IP address into account, in addition to the login name.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>When implementing security features, consider how they can be misused and
						made to turn on themselves.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>400</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>212<!--Functionality Misuse--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eugene Lebanidze</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-02-26</Submission_Date>
					</Submission>
				</Submissions>
				<Modifications>
					<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>
					<Modification>
						<Modifier>Amit Sethi</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-29</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="3"
			Name="Using Leading 'Ghost' Character Sequences to Bypass Input Filters"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
					<Text>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.</Text>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Determine if the source code is available and if
												so, examine the filter logic.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.
											</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="4">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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)</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The targetted API must ignore the leading ghost characters that are used
						to get past the filters for the semantics to be the same.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Medium</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</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>
						<Text>Alternate Encoding with Ghost Characters in FTP and Web Servers</Text>
						<Text>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.</Text>
						<Text>Using the file system API as the target, the following strings are all
							equivalent to many programs:</Text>
						<Block>
							<Code>.../../../test.txt</Code>
							<Code>............/../../test.txt</Code>
							<Code>..?/../../test.txt</Code>
							<Code>..????????/../../test.txt</Code>
							<Code>../test.txt</Code>
						</Block>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Perform white list rather than black list input validation.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Canonicalize all data prior to validation.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Take an iterative approach to input validation (defense in depth).</Text>
				</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>
			<Injection_Vector>
				<Text>Web Form, URL, Network Socket, File</Text>
			</Injection_Vector>
			<Payload>
				<Text>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.</Text>
			</Payload>
			<Activation_Zone>
				<Text>The targetted API is the activation zone. These attacks often target the file
					system or the shell to execute commands.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Failure in authorization service may lead to compromises in data
					confidentiality and integrity.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>173</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>41</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>172</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>171</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>179</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>180</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>181</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>183</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>184</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>707</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>267<!--Leverage Alternate Encoding--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Defense in Depth</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Reluctance to Trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Perform input validation and filtering on data in its canonical
						form.</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Understand the APIs to which user input will be passed and know how
						permissive they are. Perform appropriate input validation given that
						information.</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Low</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code.
							Addison-Wesley, February 2004.</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="4" Name="Using Alternative IP Address Encodings"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
					<Text>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. </Text>
					<Text>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.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target software must fail to anticipate all of the possible valid
						encodings of an IP/web address.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>The attacker has only to try IP address combinations.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to communicate with server. Optionally, ability to capture output
					directly through synchronous communication or other method such as FTP.</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Default deny access control policies</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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)</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Perform input validation for all remote content.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Malicious input delivered through standard input </Text>
			</Injection_Vector>
			<Payload>
				<Text>Varies with instantiation of attack pattern. Malicious payload may be passed
					directly from appliation client, such as the web browser.</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network </Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to view and access unexpected network services.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>291</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>180</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>41</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>345</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>707</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>267<!--Leverage Alternate Encoding--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="5" Name="Analog In-band Switching Signals (aka Blue Boxing)"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
					<Text>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.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>System must use weak authentication mechanisms for administrative
						functions.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>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</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Implementation: Upgrade phone lines. Note this may be prohibitively
						expensive</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use strong access control such as two factor access control for
						adminsitrative access to the switch</Text>
				</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>
			<Injection_Vector>
				<Text>Payload delivered through standard communication protocols.</Text>
			</Injection_Vector>
			<Payload>
				<Text>Command(s) executed directly on host</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables calls to be rerouted.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>264</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>152<!--Injection (Injecting Control Plane content through the Data Plane)--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Medium</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Other</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>Other</Framework>
				</Frameworks>
				<Platforms>
					<Platform>Other</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="7" Name="Blind SQL Injection" Pattern_Completeness="Complete"
			Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>Blind SQL Injection results from an insufficient mitigation for SQL
						Injection. Although suppressing database error messages are considered best
						practice, the suppression alone is not sufficient to prevent SQL Injection.
						Blind SQL Injection is a form of SQL Injection that overcomes the lack of
						error messages. 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.</Text>
					<Text>For example, an attacker may try entering something like "username' AND
						1=1; --" in an input field. If the result is the same as when the attacker
						entered "username" in the field, then the attacker knows that the
						application is vulnerable to SQL Injection. The attacker can then ask yes/no
						questions from the database server to extract information from it. For
						example, the attacker can extract table names from a database using the
						following types of queries:</Text>
					<Block>
						<Code>"username' AND ascii(lower(substring((SELECT TOP 1 name FROM
							sysobjects WHERE xtype='U'), 1, 1))) &gt; 108".</Code>
						<Code>If the above query executes properly, then the attacker knows that the
							first character in a table name in the database is a letter between m
							and z. If it doesn't, then the attacker knows that the character must be
							between a and l (assuming of course that table names only contain
							alphabetic characters). By performing a binary search on all character
							positions, the attacker can determine all table names in the database.
							Subsequently, the attacker may execute an actual attack and send
							something like:</Code>
						<Code>"username'; DROP TABLE trades; --</Code>
					</Block>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Hypothesize SQL queries in
											application</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Generated hypotheses regarding the SQL queries in
												an application. For example, the attacker may
												hypothesize that his input is passed directly into a
												query that looks like:</Text>
											<Block>
												<Code>"SELECT * FROM orders WHERE ordernum =
												_____"</Code>
												<Code>or</Code>
												<Code>"SELECT * FROM orders WHERE ordernum IN
												(_____)"</Code>
												<Code>or</Code>
												<Code> "SELECT * FROM orders WHERE ordernum in
												(_____) ORDER BY _____"</Code>
											</Block>
											<Text>Of course, there are many other
												possibilities.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Research types of SQL queries and determine
												which ones could be used at various places in an
												application.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine how to inject information into
											the queries</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Determine how to inject information into the
												queries from the previous step such that the
												injection does not impact their logic. For example,
												the following are possible injections for those
												queries:</Text>
											<Block>
												<Code> "5' OR 1=1; --"</Code>
												<Code>and</Code>
												<Code>"5) OR 1=1; --"</Code>
												<Code>and</Code>
												<Code>"ordernum DESC; --"</Code>
											</Block>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Add clauses to the SQL queries such that the
												query logic does not change.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Add delays to the SQL queries in case server
												does not provide clear error messages (e.g.
												WAITFOR DELAY '0:0:10' in SQL Server or
												BENCHMARK(1000000000,MD5(1) in MySQL). If these
												can be injected into the queries, then the length
												of time that the server takes to respond reveals
												whether the query is injectable or not.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>At least one way to complete a
												hypothesized SQL query that would violate the
												application developer's
												assumptions.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine user-controllable input
											susceptible to injection</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Determine the user-controllable input susceptible
												to injection. For each user-controllable input that
												the attacker suspects is vulnerable to SQL
												injection, attempt to inject the values determined
												in the previous step. If an error does not occur,
												then the attacker knows that the SQL injection was
												successful.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use web browser to inject input through text
												fields or through HTTP GET parameters.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Use a web application debugging tool such as
												Tamper Data, TamperIE, WebScarab,etc. to modify
												HTTP POST parameters, hidden fields, non-freeform
												fields, etc.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Use network-level packet injection tools
												such as netcat to inject input</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Use modified client (modified by reverse
												engineering) to inject input.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Attacker receives normal response from
												server.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Response takes expected amount of time after
												delay is injected.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="3" type="Negative">
												<Indicator_Description>
												<Text>Server sends a specific error message that
												indicates programmatic parsing of the input data
												(e.g. NumberFormatException)</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>At least one user-controllable
												input susceptible to injection
												found.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>No user-controllable input
												susceptible to injection
												found.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Unusual queries such
												as the ones described in the previous step, in
												application logs. Log files may contain unusual
												messages such as "User bob' OR 1=1; -- logged in".
												Operators should be alerted when such SQL commands
												appear in the logs.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Input validation of
												user-controlled data before including it in a SQL
												query</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Use APIs that help
												mitigate SQL injection (such as PreparedStatement
												in Java)</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine database
											type</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Determines the type of the database, such as MS
												SQL Server or Oracle or MySQL, using logical
												conditions as part of the injected queries</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Try injecting a string containing
												char(0x31)=char(0x31) (this evaluates to 1=1 in
												SQL Server only)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Try injecting a string containing 0x313D31
												(this evaluates to 1=1 in MySQL only)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Inject other database-specific commands into
												input fields susceptible to SQL Injection. The
												attacker can determine the type of database that
												is running by checking whether the query executed
												successfully or not (i.e. wheter the attacker
												received a normal response from the server or
												not).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Success outcome in previous step</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Failure outcome in previous step</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Database platform in use
												discovered.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Database platform in use not
												discovered.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Extract information about database
											schema</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Extract information about database schema by
												getting the database to answer yes/no questions
												about the schema.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Automatically extract database schema using
												a tool such as Absinthe.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Manually perform the blind SQL Injection to
												extract desired information about the database
												schema.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Success outcome in previous step.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Failure outcome in previous step.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Desired information about
												database schema extracted.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Desired information about
												database schema could not be
												extracted.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Large number of
												unusual queries in database
												logs.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Exploit SQL Injection
											vulnerability</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Use the information obtained in the previous steps
												to successfully inject the database in order to
												bypass checks or modify, add, retrieve or delete
												data from the database</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use information about how to inject commands
												into SQL queries as well as information about the
												database schema to execute attacks such as
												dropping tables, inserting records, etc.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Success outcome in previous step.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Failure outcome in previous step.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker achieves goal of
												unauthorized system access, denial of service,
												etc.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Attacker cannot exploit the
												information gathered by blind SQL
												Injection</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>SQL queries used by the application to store, retrieve or modify
						data.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>User-controllable input that is not properly validated by the application
						as part of SQL queries.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2006-4705</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>None</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>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.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</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>
			<Injection_Vector>
				<Text>User-controllable input to the application</Text>
			</Injection_Vector>
			<Payload>
				<Text>SQL statements intended to bypass checks or retrieve information about the
					database</Text>
			</Payload>
			<Activation_Zone>
				<Text>Back-end database</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The injected SQL statements 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.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>89</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>209</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>390</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>713</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>707</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>CanPrecede</Relationship_Nature>
					<Relationship_Target_ID>66<!--SQL Injection--></Relationship_Target_ID>

				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>66<!--SQL Injection--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>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.</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>Special characters in user-controllable input must be escaped before use
						by the application.</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>Employ application-level safeguards to filter data and handle exceptions
						gracefully.</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to Trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Failing Securely</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Defense in Depth</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Never Use Input as Part of a Directive to any Internal Component</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Handle All Errors Safely</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>CWE - Input Validation</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Improper Error Handling</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
					<Modification>
						<Modifier>Amit Sethi</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-29</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="96" Name="Block Access to Libraries" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Determine what external libraries the application
												accesses.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Block access to the external libraries accessed by
												the application.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Monitor the behavior of the system to see if it
												goes into an insecure/inconsistent state.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="4">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>An application requires access to external libraries.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text> An attacker has the priviliges to block application access to external
						libraries.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Medium</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</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>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</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>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>589</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>227</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>176<!--Configuration/Environment manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Failing Securely</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Low</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="8" Name="Buffer Overflow in an API Call" Pattern_Completeness="Complete"
			Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>An attacker can call an API exposed by the target
												host.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target host exposes an API to the user.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>One or more API functions exposed by the target host has a buffer overflow
						vulnerability.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</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>
						<Text_Title>Attack Example: Libc in FreeBSD</Text_Title>
						<Text>A buffer overflow in the FreeBSD utility setlocale (found in the libc
							module) puts many programs at risk all at once.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text_Title>Xtlib</Text_Title>
						<Text>A buffer overflow in the Xt library of the X windowing system allows
							local users to execute commands with root privileges.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>An attacker can simply overflow a buffer by inserting a long string
							into an attacker-modifiable injection vector. The result can be a
							DoS.</Text>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use a language or compiler that performs automatic bounds checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use secure functions not vulnerable to buffer overflow.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>If you have to use dangerous functions, make sure that you do boundary
						checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use OS-level preventative functionality. Not a complete solution.</Text>
				</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>
				<Text>The user supplied data.</Text>
			</Injection_Vector>
			<Payload>
				<Text>The buffer overrun by the attacker.</Text>
			</Payload>
			<Activation_Zone>
				<Text>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.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The most common is remote code execution.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>119</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>118</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>733</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>Bound checking should be performed when copying data to a buffer.</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Defense in Depth</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Buffer Errors</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="9" Name="Buffer Overflow in Local Command-Line Utilities"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Attacker identifies command utilities exposed by
												the target host.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target host exposes a command-line utility to the user.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The command-line utility exposed by the target host has a buffer overflow
						vulnerability that can be exploited.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</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>
						<Block>
							<Text_Title>Attack Example: HPUX passwd</Text_Title>
							<Text>A buffer overflow in the HPUX passwd command allows local users to
								gain root privileges via a command-line option.</Text>
						</Block>
						<Block>
							<Text_Title>Attack Example: Solaris getopt</Text_Title>
							<Text>A buffer overflow in Solaris's getopt command (found in libc)
								allows local users to gain root privileges via a long
								argv[0].</Text>
						</Block>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>An attacker can simply overflow a buffer by inserting a long string
							into an attacker-modifiable injection vector. The result can be a
							DoS.</Text>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use a language or compiler that performs automatic bounds checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use an abstraction library to abstract away risky APIs. Not a complete
						solution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Operational: Use OS-level preventative functionality. Not a complete
						solution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Apply the latest patches to your user exposed services. This may not be a
						complete solution, specially against zero day attack.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Do not unnecessarily expose services.</Text>
				</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>
				<Text>The user supplied data.</Text>
			</Injection_Vector>
			<Payload>
				<Text>The buffer overrun by the attacker.</Text>
			</Payload>
			<Activation_Zone>
				<Text>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.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The most common is remote code execution.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>118</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>119</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>733</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>10<!--Buffer Overflow via Environment Variables--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Defense in Depth</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Bound checking should be performed when copying data to a buffer.</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Buffer Errors</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="10" Name="Buffer Overflow via Environment Variables"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.).</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker manipulates the environment variable
												to contain excessive-length content to cause a
												buffer overflow.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker potentially leverages the buffer
												overflow to inject maliciously crafted code in an
												attempt to execute privileged command on the target
												environment.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The application uses environment variables.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>An environment variable exposed to the user is vulnerable to a buffer
						overflow.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The vulnerable environment variable uses untrusted data.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>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.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text_Title>Attack Example: Buffer Overflow in $HOME</Text_Title>
						<Text>A buffer overflow in sccw allows local users to gain root access via
							the $HOME environmental variable.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-1999-0906</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text_Title>Attack Example: Buffer Overflow in TERM</Text_Title>
						<Text>A buffer overflow in the rlogin program involves its consumption of
							the TERM environmental variable.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-1999-0046</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>An attacker can simply overflow a buffer by inserting a long string
							into an attacker-modifiable injection vector. The result can be a
							DoS.</Text>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>On a web environment, the attacker can read the client side code and
						search for environment variables that can be overwritten.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>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.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Do not expose environment variable to the user.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Do not use untrusted data in your environment variables.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use a language or compiler that performs automatic bounds checking</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</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>
				<Text>The user modifiable environment variable.</Text>
			</Injection_Vector>
			<Payload>
				<Text>User supplied data potentially containing malicious code.</Text>
			</Payload>
			<Activation_Zone>
				<Text>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.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The most common is remote code execution.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>302</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>118</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>119</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>99</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>733</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>77<!--Manipulating User-Controlled Variables--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to trust</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Bound checking should be performed when copying data to a buffer.</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Buffer Errors</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="12"
			Name="Choosing a Message/Channel Identifier on a Public/Multicast Channel"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
					<Text>Doing so allows the attacker to gain access to possibly privileged
						information, possibly perpetrate other attacks through the distribution
						means by impersonation.</Text>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Determine the nature of messages being transported
												as well as the identifiers to be used as part of the
												attack</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>If required, authenticate to the distribution
												channel</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>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.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="4">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Attackers with client access connecting to output
												channels could change their channel identifier and
												see someone else's (perhaps more privileged)
												data.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Information and client-sensitive (and client-specific) data must be
						present through a distribution channel available to all users.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>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.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>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.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>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.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
					<Text>Probing is as simple as changing this value and watching its
						effect.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>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.</Text>
					<Text>The purpose is to architect the system in a way that associates proper
						authentication/authorization with each channel/message.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</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>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>201</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>306</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>PeerOf</Relationship_Nature>
					<Relationship_Target_ID>21<!--Exploitation of Session Variables, Resource IDs and other Trusted Credentials--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>216<!--Abuse of Communication Channels--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Complete Mediation</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Use Authentication Mechanisms, Where Appropriate, Correctly</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>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).</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>Low</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
					<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
					<Architectural_Paradigm>SOA</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="13" Name="Subverting Environment Variable Values"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>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.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker probes the application for
												information. Which version of the application is
												running? Are there known environment variables?
												etc.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker gains control of an environment
												variable and ties to find out what process(es) the
												environment variable controls.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker modifies the environment variable to
												abuse the normal flow of processes or to gain access
												to privileged ressources.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>An environment variable is accessible to the user.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>An environment variable used by the application can be tainted with user
						supplied data.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>Input data used in an environment variable is not validated
						properly.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>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.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very High</Likelihood>
				<Explanation/>
			</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>
						<Text>Environment variables</Text>
						<Text>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.</Text>
						<Text>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.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>Path Manipulation (CVE-1999-0073)</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>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.</Text>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>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.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Obfuscation_Techniques>
				<Obfuscation_Technique>
					<Text>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.</Text>
				</Obfuscation_Technique>
			</Obfuscation_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Protect environment variables against unauthorized read and write
						access.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Protect the configuration files which contain environment variables
						against illegitimate read and write access.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Apply the least privilege principles. If a process has no legitimate
						reason to read an environment variable do not give that privilege.</Text>
				</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>
			<Injection_Vector>
				<Text>The client controlled parameter</Text>
			</Injection_Vector>
			<Payload>
				<Text>The new value of the client controlled parameter.</Text>
			</Payload>
			<Activation_Zone>
				<Text>The activation zone is the server side function where the client controlled
					parameter is consumed.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Consuming an attacker contolled parameter can defeat the normal process of the
					application.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>353</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>285</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>302</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>15</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>73</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>200</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Vulnerabilities>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2006-4244</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>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.</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2006-2734</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>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.</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2006-2527</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>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.</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2006-1505</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>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 "yes".</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
			</Related_Vulnerabilities>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>77<!--Manipulating User-Controlled Variables--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>CanPrecede</Relationship_Nature>
					<Relationship_Target_ID>14<!--Client-side Injection-induced Buffer Overflow--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>PeerOf</Relationship_Nature>
					<Relationship_Target_ID>10<!--Buffer Overflow via Environment Variables--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>264<!--Environment variable manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to trust</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Always perform wise data validation. Do not accept tainted data without
						validation. Do not simply base authentication on the client controlled
						parameter.</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Avoid relying on client side validation only.</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Input Validation</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
					</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="14" Name="Client-side Injection-induced Buffer Overflow"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>This type of attack exploits a buffer overflow vulnerability in targeted
						client software through injection of malicious content from a custom-built
						hostile service.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker creates a custom hostile
												service</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker acquires information about the kind
												of client attaching to her hostile service to
												determine if it contains an exploitable buffer
												overflow vulnerability.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker intentionally feeds malicious data to
												the client to exploit the buffer overflow
												vulnerability that she has uncovered.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="4">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker leverages the exploit to execute
												arbitrary code or to cause a denial of
												service.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The targeted client software communicates with an external server.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The targeted client software has a buffer oveflow vulnerability.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</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>
						<Text_Title>Attack Example: Buffer Overflow in Internet Explorer 4.0 Via
							EMBED Tag</Text_Title>
						<Text>Authors often use &lt;EMBED&gt; tags in HTML documents. For
							example</Text>
						<Block>
							<Code>&lt;EMBED TYPE="audio/midi" SRC="/path/file.mid"
								AUTOSTART="true"&gt;</Code>
						</Block>
						<Text>If an attacker supplies an overly long path in the SRC= directive, the
							mshtml.dll component will suffer a buffer overflow. This is a standard
							example of content in a Web page being directed to exploit a faulty
							module in the system. There are potentially thousands of different ways
							data can propagate into a given system, thus these kinds of attacks will
							continue to be found in the wild.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>To achieve a denial of service, an attacker can simply overflow a
							buffer by inserting a long string into an attacker-modifiable injection
							vector.</Text>
						<Text>High : Exploiting a buffer overflow to inject malicious code into the
							stack of a software system or even the heap requires a more in-depth
							knowledge and higher skill level.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>The server may look like a valid server, but in reality it may be a
						hostile server aimed at fooling the client software. For instance the server
						can use honey pots and get the client to download malicious code.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>Once engaged with the client, the hostile server may attempt to scan the
						client's host for open ports and potential vulnerabilities in the client
						software.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The hostile server may also attempt to install and run malicious code on
						the client software. That malicious code can be used to scan the client
						software for buffer overflow.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>An example of indicator is when the client software crashes after
						executing code downloaded from a hostile server.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>The client software should not install untrusted code from a non
						authenticated server.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>The client software should have the latest patches and should be audited
						for vulnerabilities before being used to communicate with potentially
						hostile servers.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Perform input validation for length of buffer inputs.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use a language or compiler that performs automatic bounds checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use an abstraction library to abstract away risky APIs. Not a complete
						solution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Ensure all buffer uses are consistently bounds-checked.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use OS-level preventative functionality. Not a complete solution.</Text>
				</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-Consequences>
			<Injection_Vector/>
			<Payload>
				<Text>Attacker-supplied data potentially containing malicious code.</Text>
			</Payload>
			<Activation_Zone>
				<Text>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 malicious code.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The most common are remote code execution or denial of service.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>353</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>118</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>119</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>713</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>8<!--Buffer Overflow in an API Call--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to Trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Defense in Depth</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
					<Architectural_Paradigm>Other</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Buffer Errors</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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 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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="15" Name="Command Delimiters" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attack of this type exploits a programs' vulnerabilities that allows an
						attacker's commands to be concatenated onto a legitimate command with the
						intent of targeting other resources such as the file system or database. The
						system that uses a filter or a blacklist input validation, as opposed to
						whitelist validation is vulnerable to an attacker who predicts delimiters
						(or combinations of delimiters) not present in the filter or blacklist. As
						with other injection attacks, the attacker uses the command delimiter
						payload as an entry point to tunnel through the application and activate
						additional attacks through SQL queries, shell commands, network scanning,
						and so on.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Assess Target Runtime
											Environment</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>In situations where the runtime environment is not
												implicitly known, the attacker makes connections to
												the target system and tries to determine the
												system's runtime environment. Knowing the
												environment is vital to choosing the correct
												delimiters.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Port mapping using network connection-based
												software (e.g., nmap, nessus, etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-ClientServer env-Embedded
												env-CommProtocol env-Peer2Peer
												env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Port mapping by exploring the operating
												system (netstat, sockstat, etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>TCP/IP Fingerprinting</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Induce errors to find informative error
												messages</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>The target software accepts connections via
												the network.</Text>
												</Indicator_Description>
												<Environments>env-Web env-CommProtocol env-Peer2Peer
												env-Embedded</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Operating environment
												(operating system, language, and/or middleware) is
												correctly identified.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Inconclusive">
												<Outcome_Description>Multiple candidate operating
												environments are suggested.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>Provide misleading
												information on TCIP/IP fingerprints (some
												operating systems can be configured to send
												signatures that match other operating
												systems).</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Provide misleading
												information at the server level (e.g., Apache,
												IIS, WebLogic, etc.) to announce a different
												server software.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Detective">
												<Security_Control_Description>Some fingerprinting
												techniques can be detected by operating systems or
												by network IDS systems because they leave the
												network connection half-open, or they do not
												belong to a valid, open
												connection.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="-1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Survey the
											Application</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker surveys the target application,
												possibly as a valid and authenticated user</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Spidering web sites for all available
												links</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Inventory all application inputs</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="-1" type="Positive">
												<Indicator_Description>
												<Text>Attacker develops a list of valid
												inputs</Text>
												</Indicator_Description>
												<Environments>env-Web
												env-ClientServer</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="0" type="Success">
												<Outcome_Description>The attacker develops a list of
												likely command delimiters.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="0" type="Detective">
												<Security_Control_Description>Monitor velocity of
												page fetching in web logs. Humans who view a page
												and select a link from it will click far slower
												and far less regularly than tools. Tools make
												requests very quickly and the requests are
												typically spaced apart regularly (e.g. 0.8 seconds
												between them).</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="0" type="Detective">
												<Security_Control_Description>Create links on some
												pages that are visually hidden from web browsers.
												Using IFRAMES, images, or other HTML techniques,
												the links can be hidden from web browsing humans,
												but visible to spiders and programs. A request for
												the page, then, becomes a good predictor of an
												automated tool probing the
												application.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="0" type="Preventative">
												<Security_Control_Description>Actively monitor the
												application and either deny or redirect requests
												from origins that appear to be
												automated.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="0" type="Detective">
												<Security_Control_Description>Monitor velocity of
												feature activations (non-web software). Humans who
												activate features (click buttons, request actions,
												invoke APIs, etc.) will do so far slower and far
												less regularly than tools. Tools make requests
												very quickly and the requests are typically spaced
												apart regularly (e.g. 0.8 seconds between
												them).</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Attempt delimiters in
											inputs</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker systematically attempts variations of
												delimiters on known inputs, observing the
												application's response each time.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Inject command delimiters using network
												packet injection tools (netcat, nemesis,
												etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-CommProtocol env-Web env-Peer2Peer
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Inject command delimiters using web test
												frameworks (proxies, TamperData, custom programs,
												etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Enter command delimiters directly in input
												fields.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local
												env-ClientServer</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Attack step 2 is successful.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>One or more command delimiters
												for the platform provokes an unexpected response
												from the software, which can be varied by the
												attacker based on the input.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Use malicious command
											delimiters</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker uses combinations of payload and
												carefully placed command delimiters to attack the
												software.</Text>
										</Attack_Step_Description>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The software performs as
												expected by the attacker.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description/>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Software's input validation or filtering must not detect and block
						presence of additional malicious command.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>By appending special characters, such as a semicolon or other commands
							that are executed by the target process, the attacker is able to execute
							a wide variety of malicious commands in the target process space,
							utilizing the target's inherited permissions, against any resource the
							host has access to. The possibilities are vast including injection
							attacks against RDBMS (SQL Injection), directory servers (LDAP
							Injection), XML documents (XPath and XQuery Injection), and command line
							shells. In many injection attacks, the results are converted back to
							strings and displayed to the client process such as a web browser
							without tripping any security alarms, so the network firewall does not
							log any out of the ordinary behavior.</Text>
						<Text>LDAP servers house critical identity assets such as user, profile,
							password, and group information that is used to authenticate and
							authorize users. An attacker that can query the directory at will and
							execute custom commands against the directory server is literally
							working with the keys to the kingdom in many enterprises. When user,
							organizational units, and other directory objects are queried by
							building the query string directly from user input with no validation,
							or other conversion, then the attacker has the ability to use any LDAP
							commands to query, filter, list, and crawl against the LDAP server
							directly in the same manner as SQL injection gives the ability to the
							attacker to run SQL commands on the database.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>The attacker has to identify injection vector, identify the specific
							commands, and optionally collect the output, i.e. from an interactive
							session.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to communicate synchronously or asynchronously with server.
					Optionally, ability to capture output directly through synchronous communication
					or other method such as FTP.</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Perform whitelist validation against a positive specification for
						command length, type, and parameters.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Limit program privileges, so if commands circumvent program input
						validation or filter routines then commands do not running under a
						privileged account</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Perform input validation for all remote content.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Use type conversions such as JDBC prepared
						statements.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Malicious input delivered through appending delimiters to standard input
				</Text>
			</Injection_Vector>
			<Payload>
				<Text>Command(s) appended to valid parameters to enable attacker to execute commands
					on host</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to execute server side code with any commands that the
					program owner has privileges to.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>146</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>77</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>184</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>78</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>185</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>93</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>140</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>157</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>138</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>154</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>713</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>6<!--Argument Injection--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>248<!--Command Injection--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>Paco Hope</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-20</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="97" Name="Cryptanalysis" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>Cryptanalysis is a process of finding weaknesses in cryptographic
						algorithms and using these weaknesses to decipher the ciphertext without
						knowing the secret key (instance deduction). Sometimes the weakness is not
						in the cryptographic algorithm itself, but rather in how it is applied that
						makes cryptanalysis successful. An attacker may have other goals as well,
						such as:</Text>
					<Block Block_Nature="List">
						<Text>1. Total Break - Finding the secret key</Text>
						<Text>2. Gobal Deduction - Finding a functionally equivalent algorithm for
							encryption and decryption that does not require knowledge of the secret
							key.</Text>
						<Text>3. Information Deduction - Gaining some information about plaintexts
							or ciphertexts that was not previously known</Text>
						<Text>4. Distinguishing Algorithm - The attacker has the ability to
							distinguish the output of the encryption (ciphertext) from a random
							permutation of bits</Text>
					</Block>
					<Text>The goal of the attacker performing cryptanalysis will depend on the
						specific needs of the attacker in a given attack context. In most cases, if
						cryptanalysis is successful at all, an attacker will not be able to go past
						being able to deduce some information about the plaintext (goal 3). However,
						that may be sufficient for an attacker, depending on the context.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>An attacker discovers a weakness in the
												cryptographic algorithm or a weakness in how it was
												applied to a particular chunk of plaintext.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>An attacker leverages the discovered weakness to
												decrypt, partially decrypt or infer some information
												about the contents of the encrypted message. All of
												that is done without knowing the secret key.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target software utilizes some sort fo cryptographic algorithm.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>An underlying weaknesses exists either in the cryptographic algorithm used
						or in the way that it was applied to a particular chunk of plaintext.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The encryption algorithm is known to the attacker.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>An attacker has access to the ciphertext.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very Low</Likelihood>
				<Explanation/>
			</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>
						<Text>A very easy to understand (but totally inapplicable to modern
							cryptographic ciphers) example is a cryptanalysis technique called
							frequency analysis that can be successfully applied to the very basic
							classic encryption algorithms that performed monoalphabetic substitution
							replacing each letter in the plaintext with its predetermined mapping
							letter from the same alphabet. This was considered an improvement over a
							more basic technique that would simply shift all of the letters of the
							plaintext by some constant number of positions and replace the original
							letters with the new letter with the resultant alphabet position. While
							monoalphabetic substitution ciphers are resilient to blind brute force,
							they can be broken easily with nothing more than a pen and paper.
							Frequency analysis cryptanalysis uses the fact that natural language is
							not random and monoalphabetic substitution does not hide the statistical
							properties of the natural language. So if the letter "E" in an English
							language occurs with a certain known frequency (about 12.7%), whatever
							"E" was substituted with to get to the ciphertext, will occur with the
							similar frequency. Having this frequency information allows the
							cryptanalyst to quickly determine the substitutions and decipher the
							ciphertext. Frequency analysis techniques are not applicable to modern
							ciphers as they are all resilient to it (unless this is a very bad case
							of a homegrown encryption algorithm). This example is just here to
							illustrate a rudimentary example of cryptanalysis.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>High</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>Cryptanalysis generally requires a very significant level of
							understanding of mathematics and computation.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Computing resource requirements will vary based on the complexity of a given
					cryptanalysis technique. Access to the encryption/decryption routines of the
					algorithm is also required.</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use proven cryptographic algorithms with recommended key sizes.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Ensure that the algorithms are used properly. That means:</Text>
					<Block Block_Nature="List">
						<Text>1. Not rolling out your own crypto; Use proven algorithms and
							implementations.</Text>
						<Text>2. Choosing initialization vectors with sufficiently random
							numbers</Text>
						<Text>3. Generating key material using good sources of randomness and
							avoiding known weak keys</Text>
						<Text>4. Using proven protocols and their implementations.</Text>
						<Text>5. Picking the most appropriate cryptographic algorithm for your usage
							context and data</Text>
					</Block>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<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/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>327</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>719</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Nature>CanFollow</Relationship_Nature>
					<Relationship_Target_ID>20<!--Encryption Brute Forcing--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>281<!--Analytic Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Reconnaissance</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>Wikipedia (Cryptanalysis): www.wikipedia.org</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Evgeny Lebanidze</Modifier>
						<Modifier_Organization>Cigital, Inc.,</Modifier_Organization>
						<Modification_Date>2007-03-20</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="16" Name="Dictionary-based Password Attack"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>An attacker tries each of the words in a dictionary as passwords to gain
						access to the system via some user's account. If the password chosen by the
						user was a word within the dictionary, this attack will be successful (in
						the absence of other mitigations). This is a specific instance of the
						password brute forcing attack pattern.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine application's/system's password
											policy</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Determine the password policies of the target
												application/system.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Determine minimum and maximum allowed
												password lengths.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Determine format of allowed passwords
												(whether they are required or allowed to contain
												numbers, special characters, etc., or whether they
												are allowed to contain words from the
												dictionary).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Determine account lockout policy (a strict
												account lockout policy will prevent brute force
												attacks).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Passwords are used in the
												application/system</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Passwords are not used in the
												application/system.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Select dictionaries</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Pick the dictionaries to be used in the attack
												(e.g. different languages, specific terminology,
												etc.)</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Select dictionary based on particular users'
												preferred languages.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Select dictionary based on the
												application/system's supported languages.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine username(s) to
											target</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Determine username(s) whose passwords to
												crack.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Obtain username(s) by sniffing network
												packets.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-CommProtocol env-Peer2Peer
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Obtain username(s) by querying
												application/system (e.g. if upon a failed login
												attempt, the system indicates whether the entered
												username was valid or not)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Obtain usernames from filesystem (e.g. list
												of directories in C:\Documents and Settings\ in
												Windows, and list in /etc/passwd in UNIX-like
												systems)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Negative">
												<Indicator_Description>
												<Text>Remote application or system provides no
												indication regarding whether a given username is
												valid or not.</Text>
												</Indicator_Description>
												<Environments>env-ClientServer env-Peer2Peer env-Web
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>At least one valid username
												found.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Presence of any valid usernames
												could not be established.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>Do not reveal
												information regarding validity of particular
												usernames to users.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Corrective">
												<Security_Control_Description>Lock out accounts
												whose usernames are suspected to have been
												compromised.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Use dictionary to crack
											passwords.</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Use a password cracking tool that will leverage
												the dictionary to feed passwords to the system and
												see if they work. </Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Try all words in the dictionary, as well as
												common misspellings of the words as passwords for
												the chosen username(s).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Try common combinations of words in the
												dictionary, as well as common misspellings of the
												combinations as passwords for the chosen
												username(s).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Negative">
												<Indicator_Description>
												<Text>Application/system does not use password
												authentication.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker determines correct
												password for a user ID and obtains access to
												application or system.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Attacker is unable to determine
												correct password for a user ID and obtain access
												to application or system.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Large number of
												authentication failures in
												logs.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Enforce strict account
												lockout policies.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Enforce strong
												passwords (having sufficient length and containing
												mix of lower case and upper case letters, numbers,
												and special
												characters)</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The system uses one factor password based authentication.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The system does not have a sound password policy that is being
						enforced.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The system does not implement an effective password throttling
						mechanism.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Brute Force</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>A system user selects the word "treacherous" as their passwords
							believing that it would be very difficult to guess. The password-based
							dictionary attack is used to crack this password and gain access to the
							account.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The Cisco LEAP challenge/response authentication mechanism uses
							passwords in a way that is susceptible to dictionary attacks, which
							makes it easier for remote attackers to gain privileges via brute force
							password guessing attacks.</Text>
						<Text>Cisco LEAP is a mutual authentication algorithm that supports dynamic
							derivation of session keys. With Cisco LEAP, mutual authentication
							relies on a shared secret, the user's logon password—which is known by
							the client and the network, and is used to respond to challenges between
							the user and the Remote Authentication Dial-In User Service (RADIUS)
							server.</Text>
						<Text>Methods exist for someone to write a tool to launch an offline
							dictionary attack on password-based authentications that leverage
							Microsoft MS-CHAP, such as Cisco LEAP. The tool leverages large password
							lists to efficiently launch offline dictionary attacks against LEAP user
							accounts, collected through passive sniffing or active
							techniques.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2003-1096</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>A variety of password cracking tools and dictionaries are available to
							launch this type of an attack.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>A machine with sufficient resources for the job (e.g. CPU, RAM, HD).
					Applicable dictionaries are required. Also a password cracking tool or a custom
					script that leverages the dictionary database to launch the attack.</Text>
			</Resources_Required>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>Many invalid login attempts are coming from the same machine (same IP
						address) or for the same log in name. The login attempts use passwords that
						are dictionary words.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Obfuscation_Techniques>
				<Obfuscation_Technique>
					<Text>Employ IP spoofing to make it seem like login attempts are coming from
						different machines.</Text>
				</Obfuscation_Technique>
			</Obfuscation_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Create a strong password policy and ensure that your system enforces this
						policy.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implement an intelligent password throttling mechanism. Care must be taken
						to assure that these mechanisms do not excessively enable account lockout
						attacks such as CAPEC-02.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>521</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>262</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>263</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>49<!--Password Brute Forcing--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eugene Lebanidze</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-02-26</Submission_Date>
					</Submission>
				</Submissions>
				<Modifications>
					<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
							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>
					<Modification>
						<Modifier>Amit Sethi</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-29</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="17" Name="Accessing, Modifying or Executing Executable Files"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attack of this type exploits a system's configuration that allows an
						attacker to either directly access an executable file, for example through
						shell access; or in a possible worst case allows an attacker to upload a
						file and then execute it. Web servers, ftp servers, and message oriented
						middleware systems which have many integration points are particularly
						vulnerable, because both the programmers and the administrators must be in
						synch regarding the interfaces and the correct privileges for each
						interface.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>System's configuration must allow an attacker to directly access
						executable files or upload files to execute. This means that any access
						control system that is supposed to mediate communications between the
						subkect and the object is set incorrectly or assumes a benign
						environment.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Consider a directory on a web server with the following
							permissions</Text>
						<Block>
							<Code>drwxrwxrwx 5 admin public 170 Nov 17 01:08 webroot</Code>
						</Block>
						<Text>This could allow an attacker to both execute and upload and execute
							programs' on the web server. This one vulnerability can be exploited by
							a threat to probe the system and identify additional vulnerabilities to
							exploit.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>To identify and execute against an overprivileged system
							interface</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to communicate synchronously or asynchronously with server that
					publishes an overprivileged directory, program, or interface. Optionally,
					ability to capture output directly through synchronous communication or other
					method such as FTP.</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Enforce principle of least privilege</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Run server interfaces with a non-root account and/or utilize
						chroot jails or other configuration techniques to constrain privileges even
						if attacker gains some limited access to commands.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Perform testing such as pentesting and vulnerability
						scanning to identify directories, programs, and interfaces that grant direct
						access to executables.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Payload delivered through standard communication protocols.</Text>
			</Injection_Vector>
			<Payload>
				<Text>Command(s) executed directly on host</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to execute server side code with any commands that the
					program owner has privileges to.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>285</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>272</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>59</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>282</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>275</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>264</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>270</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>1<!--Accessing Functionality Not Properly Constrained by ACLs--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>233<!--Privilege Escalation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>165<!--File Manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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,
							Description 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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="20" Name="Encryption Brute Forcing" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attacker, armed with the cipher text and the encryption algorithm used,
						performs an exhaustive (brute force) search on the key space to determine
						the key that decrypts the cipher text to obtain the plaintext.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Determine the ciphertext and the encryption
												algorithm.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Perform an exhaustive brute force search of the
												keyspace, producing candidate plaintexts and
												observing if they make sense.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Ciphertext is known.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>Encryption algorithm and key size are known.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Low</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Low</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Brute Force</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>In 1997 the original DES challenge used distributed net computing to
							brute force the encryption key and decrypt the ciphertext to obtain the
							original plaintext. Each machine was given its own section of the
							keyspace to cover. The ciphertext was decrypted in 96 days.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>Brute forcing encryption does not require much skill.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>A powerful enough computer for the job with sufficient CPU, RAM and HD. Exact
					requirements will depend on the size of the brute force job and the time
					requirement for completion. Some brute forcing jobs may require grid or
					distributed computing (e.g. DES Challenge).</Text>
				<Text>On average, for a binary key of size N, 2^(N/2) trials will be needed to find
					the key that would decrypt the ciphertext to obtain the original
					plaintext.</Text>
				<Text>Obviously as N gets large the brute force approach becomes infeasible.</Text>
			</Resources_Required>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>None. This attack happens offline.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use commonly accepted algorithms and recommended key sizes. The key size
						used will depend on how important it is to keep the data confidential and
						for how long.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>In theory a brute force attack performing an exhausitve keyspace search
						will always succeed, so the goal is to have computational security. Moore's
						law needs to be taken into account that suggests that computing resources
						double every eighteen months.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>326</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>719</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>112<!--Brute Force--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eugene Lebanidze</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-02-26</Submission_Date>
					</Submission>
				</Submissions>
				<Modifications>
					<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 Description,
							Resources Required and Context 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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="21"
			Name="Exploitation of Session Variables, Resource IDs and other Trusted Credentials"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>Attacks on session IDs and resource IDs take advantage of the fact that
						some software accepts user input without verifying its authenticity. For
						example, a message queueing system that allows service requesters to post
						messages to its queue through an open channel (such as anonymous FTP),
						authorization is done through checking group or role membership contained in
						the posted message. However, there is no proof that the message itself, the
						information in the message (such group or role membership), or indeed the
						process that wrote the message to the queue are authentic and authorized to
						do so.</Text>
					<Text>Many server side processes are vulnerable to these attacks because the
						server to server communications have not been analyzed from a security
						perspective or the processes "trust" other systems because they are behind a
						firewall. In a similar way servers that use easy to guess or spoofable
						schemes for representing digital identity can also be vulnerable. Such
						systems frequently use schemes without cryptography and digital signatures
						(or with broken cryptography). Session IDs may be guessed due to
						insufficient randomness, poor protection (passed in the clear), lack of
						integrity (unsigned), or improperly correlation with access control policy
						enforcement points.</Text>
					<Text>Exposed configuration and properties files that contain system passwords,
						database connection strings, and such may also give an attacker an edge to
						identify these identifiers.</Text>
					<Text>The net result is that spoofing and impersonation is possible leading to
						an attacker's ability to break authentication, authorization, and audit
						controls on the system.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Survey the application for Indicators of
											Susceptibility</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Using a variety of methods, until one is found
												that applies to the target system. the attacker
												probes for credentials, session tokens, or entry
												points that bypass credentials altogether.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Spider all available pages</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Attack known bad interfaces</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-CommProtocol
												env-ClientServer env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Session IDs are used</Text>
												</Indicator_Description>
												<Environments>env-Web env-Peer2Peer env-ClientServer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Open access points exist that use no user
												IDs or passwords, but determine authorization
												based on message content</Text>
												</Indicator_Description>
												<Environments>env-Web env-Peer2Peer env-CommProtocol
												env-ClientServer env-Local</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Session IDs are
												identifiable</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Success">
												<Outcome_Description>Open channels are
												available</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor velocity of
												page fetching in web logs. Humans who view a page
												and select a link from it will click far slower
												and far less regularly than tools. Tools make
												requests very quickly and the requests are
												typically spaced apart regularly (e.g. 0.8 seconds
												between them).</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Detective">
												<Security_Control_Description>Create links on some
												pages that are visually hidden from web browsers.
												Using IFRAMES, images, or other HTML techniques,
												the links can be hidden from web browsing humans,
												but visible to spiders and programs. A request for
												the page, then, becomes a good predictor of an
												automated tool probing the
												application.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Actively monitor the
												application and either deny or redirect requests
												from origins that appear to be
												automated.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="4" type="Detective">
												<Security_Control_Description>Monitor velocity of
												feature activations (non-web software). Humans who
												activate features (click buttons, request actions,
												invoke APIs, etc.) will do so far slower and far
												less regularly than tools. Tools make requests
												very quickly and the requests are typically spaced
												apart regularly (e.g. 0.8 seconds between
												them).</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Fetch samples</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>An attacker fetches many samples of a session ID.
												This may be through legitimate access (logging in,
												legitimate connections, etc) or just systematic
												probing.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>An attacker makes many anonymous connections
												and records the session IDs assigned.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-Peer2Peer env-CommProtocol
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>An attacker makes authorized connections and
												records the session tokens or credentials
												issued.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-Peer2Peer env-CommProtocol
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>An attacker gains access to (legitimately or
												illegitimately) a nearby system (e.g., in the same
												operations network, DMZ, or local network) and
												makes a connections from it, attempting to gain
												the same privileges as a trusted system.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Peer2Peer env-CommProtocol
												env-ClientServer</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Trust in the system is based on IP address,
												MAC address, network locality, or other general
												network characteristic.</Text>
												</Indicator_Description>
												<Environments>env-CommProtocol env-ClientServer
												env-Peer2Peer</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Web applications use session IDs</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="3" type="Positive">
												<Indicator_Description>
												<Text>Network systems issue session IDs or
												connection IDs</Text>
												</Indicator_Description>
												<Environments>env-CommProtocol env-ClientServer
												env-Peer2Peer</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Systems or applications grant
												trust based on logical or physical network
												locality.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Success">
												<Outcome_Description>Session identifiers
												successfully spoofed</Outcome_Description>
											</Outcome>
											<Outcome ID="3" type="Failure">
												<Outcome_Description>No session IDs can be found or
												exploited</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor logs for
												unusual amounts of invalid
												sessions.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Detective">
												<Security_Control_Description>Monitor logs for
												unusual amounts of invalid connections or invalid
												requests from unauthorized
												hosts.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Impersonate</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>An attacker can use successful experiments to
												impersonate an authorized user or system</Text>
										</Attack_Step_Description>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Analyze logs for users
												or systems that are connecting from unexpected
												sources.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Detective">
												<Security_Control_Description>Analyze logs for users
												or systems successfully requesting or performing
												unexpected actions.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Corrective">
												<Security_Control_Description>If heuristics are
												sufficiently reliable, disconnect hosts or users
												that appear to be unauthorized
												impersonations.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Spoofing</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Bad data can be injected into the system by an
												attacker.</Text>
										</Attack_Step_Description>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Unauthorized data is injected
												into an application.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Apply heuristic
												evaluation to input data. This can include
												validating source addresses, user names, ACLs or
												other data that indicates authorization. This need
												not be done inline at the time the data is
												processed, but can be done after the processing
												has occurred to detect
												attack.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Corrective">
												<Security_Control_Description>Apply
												transaction-based logic to systems whose initial
												authorization cannot be better controlled. Roll
												back transactions that are subsequently determined
												to be fraudulent or
												illegitimate.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Server software must rely on weak session IDs proof and/or verification
						schemes</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Spoofing</Method_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>
						<Text>Thin client applications like web applications are particularly
							vulnerable to session ID attacks. Since the server has very little
							control over the client, but still must track sessions, data, and
							objects on the server side, cookies and other mechanisms have been used
							to pass the key to the session data between the client and server. When
							these session keys are compromised it is trivial for an attacker to
							impersonate a user's session in effect, have the same capabilities as
							the authorized user. There are two main ways for an attacker to exploit
							session IDs.</Text>
						<Text>A brute force attack involves an attacker repeatedly attempting to
							query the system with a spoofed session header in the HTTP request. A
							web server that uses a short session ID can be easily spoofed by trying
							many possible combinations so the parameters session-ID= 1234 has few
							possible combinations, and an attacker can retry several hundred or
							thousand request with little to no issue on their side.</Text>
						<Text>The second method is interception, where a tool such as wireshark is
							used to sniff the wire and pull off any unprotected session identifiers.
							The attacker can then use these variables and access the
							application.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>To achieve a direct connection with the weak or non-existent server
							session access control, and pose as an authorized user</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to deploy software on network. Ability to communicate synchronously or
					asynchronously with server</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: utilize strong federated identity such as SAML to encrypt and sign
						identity tokens in transit.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Use industry standards session key generation mechanisms
						that utilize high amount of entropy to generate the session key. Many
						standard web and application servers will perform this task on your
						behalf.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: If the session identifier is used for authentication, such
						as in the so-called single sign on use cases, then ensure that it is
						protected at the same level of assurance as authentication tokens.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: If the web or application server supports it, then
						encrypting and/or signing the session ID (such as cookie) can protect the ID
						if intercepted.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Use strong session identifiers that are protected in transit and
						at rest.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Utilize a session timeout for all sessions, for example 20
						minutes. If the user does not explicitly logout, the server terminates their
						session after this period of inactivity. If the user logs back in then a new
						session key is generated.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Verify of authenticity of all session IDs at
						runtime.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Malicious input delivered through standard service calls, e.g. FTP or posting
					a message to a message queue.</Text>
			</Injection_Vector>
			<Payload>
				<Text>Varies with instantiation of attack pattern. The main goal is so spoof or
					impersonate a legitimate user.</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network (e.g. Intranet)</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to impersonate another user and access commands and data (and
					log behavior to audit logs) on their behalf.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>290</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>302</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>346</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>539</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>6</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>384</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>664</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>602</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>642</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>225<!--Exploitation of Authentication--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
					<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
					<Architectural_Paradigm>SOA</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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-10</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>
					<Modification>
						<Modifier>Paco Hope</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-20</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="22" Name="Exploiting Trust in Client (aka Make the Client Invisible)"
			Pattern_Completeness="Complete" Pattern_Abstraction="Meta" Status="Draft">
			<Description>
				<Summary>
					<Text>An attack of this type exploits a programs' vulnerabilities in
						client/server communication channel authentication and data integrity. It
						leverages the implicit trust a server places in the client, or more
						importantly, that which the server believes is the client.</Text>
					<Text>An attacker executes this type of attack by placing themselves in the
						communication channel between client and server such that communication
						directly to the server is possible where the server believes it is
						communicating only with a valid client.</Text>
					<Text>There are numerous variations of this type of attack.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Server software must rely on client side formatted and validated values,
						and not re-inforce these checks on the server side.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Spoofing</Method_of_Attack>
				<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Web applications may use Javascript to perform client side validation,
							request encoding/formatting, and other security functions, which
							provides some usability benefits and eliminates some client-server
							roundtripping. However, the web server cannot assume that the requests
							it receives have been subject to those validations, because an attacker
							can use an alternate method for crafting the HTTP Request and submit
							data that contains poisoned values designed to spoof a user and/or get
							the web server to disclose information.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Web 2.0 style applications may be particularly vulnerable because they
							in large part rely on existing infrastructure which provides scalability
							without the ability to govern the clients. Attackers identify
							vulnerabilities that either assume the client side is responsible for
							some security services (without the requisite ability to ensure
							enforcement of these checks) and/or the lack of a hardened, default deny
							server configuration that allows for an attacker probing for weaknesses
							in unexpected ways. Client side validation, request formatting and other
							services may be performed, but these are strictly usability enhancements
							not security enhancements.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Many web applications use client side scripting like Javascript to
							enforce authentication, authorization, session state and other
							variables, but at the end of day they all make requests to the server.
							These client side checks may provide usability and performance gains,
							but they lack integrity in terms of the http request. It is possible for
							an attacker to post variables directly to the server without using any
							of the client script security checks and customize the patterns to
							impersonate other users or probe for more information.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Many message oriented middleware systems like MQ Series are rely on
							information that is passed along with the message request for making
							authorization decisions, for example what group or role the request
							should be passed. However, if the message server does not or cannot
							authenticate the authorization information in the request then the
							server's policy decisions about authorization are trivial to subvert
							because the client process can simply elevate privilege by passing in
							elevated group or role information which the messgae server accepts and
							acts on.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>The attacker must have fairly detailed knowledge of the syntax and
							semantics of client/server communications protocols and grammars</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to communicate synchronously or asynchronously with server</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Ensure that client process and/or message is authenticated so that
						anonymous communications and/or messages are not accepted by the
						system.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Do not rely on client validation or encoding for security
						purposes.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Utilize digital signatures to increase authentication
						assurance.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Utilize two factor authentication to increase authentication
						assurance.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Perform input validation for all remote content.</Text>
				</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>Information Leakage</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>290</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>287</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>200</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>232<!--Exploitation of Privilege/Trust--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
					<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="23" Name="File System Function Injection, Content Based"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attack of this type exploits the host's trust in executing remote
						content including binary files. The files are poisoned with a malicious
						payload (targeting the file systems accessible by the target software) by
						the attacker and may be passed through standard channels such as via email,
						and standard web content like PDF and multimedia files. The attacker
						exploits known vulnerabilities or handling routines in the target processes.
						Vulnerabilities of this type have been found in a wide variety of commercial
						applications from Microsoft Office to Adobe Acrobat and Apple Safari web
						browser. When the attacker knows the standard handling routines and can
						identify vulnerabilities and entry points they can be exploited by otherwise
						seemingly normal content. Once the attack is executed, the attacker's
						program can access relative directories such as C:\Program Files or other
						standard system directories to launch further attacks. In a worst case
						scenario, these programs are combined with other propagation logic and work
						as a virus.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target software must consume files.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The attacker must have access to modify files that the target software
						will consume.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</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>
						<Text>PHP is a very popular web server. When PHP is used with global
							variables, a vulnerability may be opened that affects the file system. A
							standard HTML form that allows for remote users to upload files, may
							also place those files in a public directory where the attacker can
							directly access and execute them through a browser. This vulnerability
							allows remote attackers to execute arbitrary code on the system, and can
							result in the attacker being able to erase intrusion evidence from
							system and application logs.</Text>
						<Text>Reference - http://www.owasp.org/index.php/File_System</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Enforce principle of least privilege</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Validate all input for content including files. Ensure that if
						files and remote content must be accepted that once accepted, they are
						placed in a sandbox type location so that lower assurance clients cannot
						write up to higher assurance processes (like Web server processes for
						example)</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Execute programs with constrained privileges, so parent process
						does not open up further vulnerabilities. Ensure that all directories,
						temporary directories and files, and memory are executing with limited
						privileges to protect against remote execution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Proxy communication to host, so that communications are terminated
						at the proxy, sanitizing the requests before forwarding to server
						host.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Virus scanning on host</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Host integrity monitoring for critical files, directories,
						and processes. The goal of host integrity monitoring is to be aware when a
						security issue has occurred so that incident response and other forensic
						activities can begin.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Payload delivered through standard communication protocols.</Text>
			</Injection_Vector>
			<Payload>
				<Text>Command(s) executed directly on host filesystem</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to execute server side code with any commands that the
					program owner has privileges to.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>77</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>23</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>22</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>713</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>715</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>241<!--Code Injection--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>242<!--Script Injection--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>165<!--File Manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="24" Name="Filter Failure through Buffer Overflow"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>In this attack, the idea is to cause an active filter to fail by causing
						an oversized transaction. An attacker may try to feed overly long input
						strings to the program in an attempt to overwhelm the filter (by causing a
						buffer overflow) and hoping that the filter does not fail securely (i.e.
						lets the user input into the system unfiltered).</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Survey</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker surveys the target application,
												possibly as a valid and authenticated user</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Spidering web sites for inputs that involve
												potential filtering</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Brute force guessing of filtered
												inputs</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Software messages (e.g., "the following
												characters are not allowed...") indicate that
												filtered inputs are present in the software.
												(</Text>
												</Indicator_Description>
												<Environments>env-Web
												env-ClientServer</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Application uses predefined inputs (e.g.,
												drop-down lists, radio buttons, selection lists,
												etc.)</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Local
												env-Embedded</Environments>
											</Indicator>
											<Indicator ID="3" type="Negative">
												<Indicator_Description>
												<Text>Managed code (e.g., .NET, Java) is likely,
												based on URLs.</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="4" type="Negative">
												<Indicator_Description>
												<Text>Managed code (e.g., .NET, Java) is likely,
												based on files found in software.</Text>
												</Indicator_Description>
												<Environments>env-ClientServer env-Local
												env-Embedded env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
											<Indicator ID="5" type="Negative">
												<Indicator_Description>
												<Text>Java code is likely, based on standard
												disclaimers (e.g., "This software contains Java
												from Sun...."). Such declarations are frequent on
												commercial software that is based on Java.</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local
												env-ClientServer</Environments>
											</Indicator>
											<Indicator ID="6" type="Inconclusive">
												<Indicator_Description>
												<Text>Java code is likely, based on one of the
												other indicators, but it could contain Java Native
												Interface (JNI) code. This is indicated by the
												inclusion of DLLs or equivalent binary object code
												with Java code.</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local
												env-ClientServer</Environments>
											</Indicator>
										</Indicators>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Attempt injections</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Try to feed overly long data to the system. This
												can be done manually or a dynamic tool (black box)
												can be used to automate this. An attacker can also
												use a custom script for that purpose.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Brute force attack through black box
												penetration test tool.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer
												env-CommProtocol env-Peer2Peer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Fuzzing of communications protocols</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-CommProtocol env-Peer2Peer
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Manual testing of possible inputs with
												attack data.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Unexpected output from the
												application.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>No unexpected output from the
												application.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor and analyze
												logs for failures that exceed common usage sizes.
												For example, if typical transactions, even normal
												failed transactions, rarely exceed 250 characters,
												monitor logs for all attempts that contain 250 or
												more characters. In the event of successful
												exploitation, there may actually be no useful log.
												But an attacker's experiments will likely show up,
												giving clues to the ultimate
												attack.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Corrective">
												<Security_Control_Description>Disconnect or block
												connections from systems or users that exceed
												acceptable heuristics for normal transaction
												sizes.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Monitor responses</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Watch for any indication of failure occurring.
												Carefully watch to see what happened when filter
												failure occurred. Did the data get in?</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Boron tagging. Choose clear attack inputs
												that are easy to notice in output. In binary this
												is often 0xa5a5a5a5 (alternating 1s and 0s).
												Another obvious tag value is all zeroes, but it is
												not always obvious what goes wrong if the null
												values get into the data.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Check Log files. An attacker with access to
												log files can look at the outcome of bad
												input.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>Prevent access to log
												files that contain error
												output.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Prevent access to
												and/or sanitize all error
												output.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Abuse the system through filter
											failure</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>An attacker writes a script to consistently induce
												the filter failure.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>DoS through filter failure. The attacker
												causes the system to crash or stay down because of
												its failure to filter properly.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Malicious code execution. An attacker
												introduces a malicious payload and executes
												arbitrary code on the target system.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>An attacker can use the filter failure to
												introduce malicious data into the system and
												leverage a subsequent SQL injection, Cross Site
												Scripting, Command Injection or similar weakness
												if it exists.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Failure mode of the software (perhaps as a
												safety mechanism) includes exiting or ceasing to
												respond.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Failures do not involve stopping services,
												rejecting inputs or connections, and do not affect
												other simultaneous users of the software.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker-supplied code is
												executed on the target
												system.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Success">
												<Outcome_Description>The software stops responding
												for at least two orders of magnitude longer than
												the input takes to send. (e.g., 0.1s to send input
												induces at least a 10 second period
												non-responsiveness).</Outcome_Description>
											</Outcome>
											<Outcome ID="3" type="Success">
												<Outcome_Description>Non-response by an attacker's
												input has an impact on the quality of service of
												other simultaneous users of the
												software.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor software
												response time regularly, and react to unexpected
												variations.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Execute filtering
												modules with minimal
												privileges.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Execute filtering
												modules in operating system "sandboxes" or similar
												containers.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Ability to control the length of data passed to an active filter.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text_Title>Attack Example: Filter Failure in Taylor UUCP
							Daemon</Text_Title>
						<Text>Sending in arguments that are too long to cause the filter to fail
							open is one instantiation of the filter failure attack. The Taylor UUCP
							daemon is designed to remove hostile arguments before they can be
							executed. If the arguments are too long, however, the daemon fails to
							remove them. This leaves the door open for attack.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>A filter is used by a web application to filter out characters that
							may allow the input to jump from the data plane to the control plane
							when data is used in a SQL statement (chaining this attack with the SQL
							injection attack). Leveraging a buffer overflow the attacker makes the
							filter fail insecurely and the tainted data is permitted to enter
							unfiltered into the system, subsequently causing a SQL injection.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Audit Truncation and Filters with Buffer Overflow. Sometimes very
							large transactions can be used to destroy a log file or cause partial
							logging failures. In this kind of attack, log processing code might be
							examining a transaction in real-time processing, but the oversized
							transaction causes a logic branch or an exception of some kind that is
							trapped. In other words, the transaction is still executed, but the
							logging or filtering mechanism still fails. This has two consequences,
							the first being that you can run transactions that are not logged in any
							way (or perhaps the log entry is completely corrupted). The second
							consequence is that you might slip through an active filter that
							otherwise would stop your attack.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>An attacker can simply overflow a buffer by inserting a long string
							into an attacker-modifiable injection vector. The result can be a
							DoS.</Text>
						<Text>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.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Try to feed very long data as input to the program and watch for any
						indication that a failure has occurred. Then see if input has been admitted
						into the system.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>Some dynamic analysis tools may be helpful here to determine whether
						failure can be induced by feeding overly long inputs strings into the
						system.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>Many exceptions are thrown by the application's filter modules in a short
						period of time. Check the logs. See if the probes are coming from the same
						IP address.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Obfuscation_Techniques>
				<Obfuscation_Technique>
					<Text>An attacker may temporally space out their probes.</Text>
				</Obfuscation_Technique>
				<Obfuscation_Technique>
					<Text>An attacker may perform probes from different IP addresses.</Text>
				</Obfuscation_Technique>
			</Obfuscation_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Make sure that ANY failure occurring in the filtering or input validation
						routine is properly handled and that offending input is NOT allowed to go
						through. Basically make sure that the vault is closed when failure
						occurs.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Pre-design: Use a language or compiler that performs automatic bounds
						checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Pre-design through Build: 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.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Operational: Use OS-level preventative functionality. Not a complete
						solution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Use an abstraction library to abstract away risky APIs. Not a
						complete solution.</Text>
				</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-Consequences>
			<Injection_Vector>
				<Text>Web form, URL, File, Command line, Network socket, etc.</Text>
			</Injection_Vector>
			<Payload>
				<Text>All of the data that just got into the system unfiltered becomes the
					payload.</Text>
			</Payload>
			<Activation_Zone>
				<Text>Since the input enters the system effectively unfiltered, it may be dangerous
					if used in a SQL statement (i.e. SQL injection), as part of the command executed
					on the target system (i.e. command injection), as part of the reflection API
					(i.e. reflection injection), placed in logs (i.e. log injection), or perhaps to
					overflow another buffer in the system and give the attacker ability to execute
					arbitrary code. A subsequent buffer overflow may not even be required for that
					as the original one may be leveraged if the attacker gets lucky, that is the
					payload is activated in the filter itself, which also becomes the activation
					zone.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Since no input validation is effectively performed in this situation, the
					impact of the attack may be a complete compromise of confidentiality, integrity,
					accountability and availability services.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>119</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>118</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>733</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>CanFollow</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>100<!--Overflow Buffers--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>Input validation and filtering logic should fail securely (vault doors are
						closed)</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Failing Securely</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>All input should be treated as rejected by default, unless explicitly
						allowed by the filter. Thus if the filter fails before "blessing" the data,
						it will be rejected.</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Medium</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
					<Language>C</Language>
					<Language>C++</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Buffer Errors</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>Paco Hope</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-20</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="25" Name="Forced Deadlock" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack attempts to trigger and exploit a deadlock condition in the
						target software to cause a denial of service. A deadlock can occur when two
						or more competing actions are waiting for each other to finish, and thus
						neither ever does. Deadlock condition are not easy to detect.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker initiates an exploratory phase to get
												familiar with the system.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker triggers a first action (such as
												holding a resource) and initiates a second action
												which will wait for the first one to finish.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>If the target program has a deadlock condition,
												the program waits indefinitevely resulting in a
												denial of service.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The target host has a deadlock condition. There are four conditions for a
						deadlock to occur, known as the Coffman conditions (See reference,
						Wikipedia)</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The target host exposes an API to the user.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Low</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>An example of a deadlock which may occur in database products is the
							following. Client applications using the database may require exclusive
							access to a table, and in order to gain exclusive access they ask for a
							lock. If one client application holds a lock on a table and attempts to
							obtain the lock on a second table that is already held by a second
							client application, this may lead to deadlock if the second application
							then attempts to obtain the lock that is held by the first application
							(Source: Wikipedia, http://en.wikipedia.org/wiki/Deadlock)</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>This type of attack may be sophisticated and require knowledge about
							the system's resources and APIs.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>The attacker can probe by trying to hold resources and call APIs which are
						directly using the same resources.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The attacker may try to find actions (threads, processes) competing for
						the same resources.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use known algorithm to avoid deadlock condition (for instance non-blocking
						synchronization algorithms).</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>For competing actions use well known libraries which implement
						synchronization.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text/>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>412</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>567</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>662</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>172<!--Time and State Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Low</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Unrestricted Critical Resource Lock</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>Deadlock, http://en.wikipedia.org/wiki/Deadlock</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eric Dalci</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-01-25</Submission_Date>
						<Submission_Comment/>
					</Submission>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Sean Barnum</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-03-07</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 Likelihood
							and other general areas</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="92" Name="Forced Integer Overflow" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack forces an integer variable to go out of range. The integer
						variable is often used as an offset such as size of memory allocation or
						similarly. The attacker would typically control the value of such variable
						and try to get it out of range. For instance the integer in question is
						incremented past the maximum possible value, it may wrap to become a very
						small, or negative number, therefore providing a very incorrect value which
						can lead to unexpected behavior. At worst the attacker can execute arbitrary
						code.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The first step is exploratory meaning the attacker
												looks for an integer variable that he can
												control.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker finds an integer variable that he can
												write into or manipulate and try to get the value of
												the integer out of the possible range. The integer
												variable is forced to have a value out of range
												which set its final value to an unexpected
												value.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The target host acts on the data and unexpected
												behaviour may happen.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The attacker can manipulate the value of an integer variable utilized by
						the target host.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The target host does not do proper range checkingon the variable before
						utilizing it.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>When the integer variable is incremented or decremented to an out of range
						value, it gets a very different value (e.g. very small or negative
						number)</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Integer overflow in the ProcAuWriteElement function in
							server/dia/audispatch.c in Network Audio System (NAS) before 1.8a SVN
							237 allows remote attackers to cause a denial of service (crash) and
							possibly execute arbitrary code via a large max_samples value.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2007-1544</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The following code illustrates an integer overflow. The declaration of
							total integer as "unsigned short int" assumes that the length of the
							first and second arguments fits in such an integer. From "Secure Coding
							in C and C++" by Robert C. Seacord. Page 152, Figure 5-1</Text>
						<Block>
							<Code>include &lt;stdlib.h&gt;</Code>
							<Code>include &lt;string.h&gt;</Code>
							<Code>include &lt;stdio.h&gt;</Code>
							<Code/>
							<Code>int main (int argc, char *const *argv)</Code>
							<Code>{</Code>
							<Block>
								<Code>if (argc !=3){</Code>
								<Block>
									<Code>printf("Usage: prog_name &lt;string1&gt;
										&lt;string2&gt;\n");</Code>
									<Code>exit(-1);</Code>
								</Block>
								<Code>}</Code>
								<Code>unsigned short int total;</Code>
								<Code>total = strlen(argv[1])+strlen(argv[2])+1;</Code>
								<Code>char * buff = (char *)malloc(total);</Code>
								<Code>strcpy(buff, argv[1]);</Code>
								<Code>strcpy(buff, argv[2]);</Code>
							</Block>
							<Code>}</Code>
							<Code>//Source : SAMATE.NIST.GOV :
								http://samate.nist.gov/SRD/view_testcase.php?login=Guest&amp;tID=1511</Code>
						</Block>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>An attacker can simply overflow an integer by inserting an out of
							range value.</Text>
						<Text>High : Exploiting a buffer overflow by injecting malicious code into
							the stack of a software system or even the heap can require a higher
							skill level.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Vulnerability testing tool can be used to probe for integer overflow (e.g.
						fuzzer).</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text/>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use a language or compiler that performs automatic bounds checking.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>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 integer overflow.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use an abstraction library to abstract away risky APIs. Not a complete
						solution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Always do bound checking before consuming user input data.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text/>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>The user supplied data.</Text>
			</Injection_Vector>
			<Payload>
				<Text>The integer overrun by the attacker.</Text>
			</Payload>
			<Activation_Zone>
				<Text>When the function use the integer as offset, the offset may be out of the
					expected range which may lead to unexpected behavior such as issues of
					availability.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>The most common are issues of availability. In some situation, an integer
					oveflow can turn out to be an exploitable buffer overflow, then the attacker may
					be able to run arbitrary code on the target host.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>190</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>128</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>120</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>122</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>196</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>680</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>697</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>128<!--Integer Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to Trust</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>High</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>J. Viega and G. McGraw. Building Secure Software. Addison-Wesley,
							2002.</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Integer overflow (wrap or wraparound)</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>Integer overflow, Secure Software -
							http://www.owasp.org/index.php/Integer_overflow</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>SAMATE : samate.nist.gov</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Eric Dalci</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-03-25</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="26" Name="Leveraging Race Conditions" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack targets a race condition occurring when multiple processes
						access and manipulate the same resource concurrently and the outcome of the
						execution depends on the particular order in which the access takes place.
						The attacker can leverage a race condition by "running the race", modifying
						the resource and modifying the normal execution flow. For instance a race
						condition can occur while accessing a file, the attacker can trick the
						system by replacing the original file with his version and cause the system
						to read the malicious file.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker explores to gauge what level of
												access he has.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker gains access to a resource on the
												target host. The attacker modifies the targeted
												resource. The resource's value is used to determine
												the next normal execution action.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The resource is modified/checked concurrently by
												multiple processes. By using one of the processes,
												the attacker is able to modify the value just before
												it is consumed by a different process. A race
												condition occurs and is exploited by the Attacker to
												abuse the target host.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>A resource is accessed/modified concurrently by multiple processes such
						that a race condition exists.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The attacker has the ability to modify the resource.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Time and State</Method_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The Net Direct client for Linux before 6.0.5 in Nortel Application
							Switch 2424, VPN 3050 and 3070, and SSL VPN Module 1000 extracts and
							executes files with insecure permissions, which allows local users to
							exploit a race condition to replace a world-writable file in
							/tmp/NetClient and cause another user to execute arbitrary code when
							attempting to execute this client, as demonstrated by replacing
							/tmp/NetClient/client.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2007-1057</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The following code illustrates a file that is accessed multiple times
							by name in a publicly accessible directory. A race condition exists
							between the accesses where an attacker can replace the file referenced
							by the name.</Text>
						<Block>
							<Code>include &lt;sys/types.h&gt;</Code>
							<Code>include &lt;fcntl.h&gt;</Code>
							<Code>include &lt;unistd.h&gt;</Code>
							<Code/>
							<Code>define FILE "/tmp/myfile"</Code>
							<Code>define UID 100</Code>
							<Code/>
							<Code>void test(char *str)</Code>
							<Code>{</Code>
							<Block>
								<Code>int fd;</Code>
								<Code>fd = creat(FILE, 0644);</Code>
								<Code>if(fd == -1)</Code>
								<Block>
									<Code>return;</Code>
								</Block>
								<Code>chown(FILE, UID, -1); /* BAD */</Code>
								<Code>close(fd);</Code>
							</Block>
							<Code>}</Code>
							<Code/>
							<Code>int main(int argc, char **argv)</Code>
							<Code>{</Code>
							<Block>
								<Code>char *userstr;</Code>
								<Code>if(argc &gt; 1) {</Code>
								<Block>
									<Code>userstr = argv[1];</Code>
									<Code>test(userstr);</Code>
								</Block>
								<Code>}</Code>
								<Code>return 0;</Code>
							</Block>
							<Code>}</Code>
							<Code/>
							<Code>//Source : SAMATE.NIST.GOV :
								http://samate.nist.gov/SRD/view_testcase.php?login=Guest&amp;;tID=1598</Code>
						</Block>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Vulnerability testing tool can be used to probe for race condition.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The attacker may also look for temporary file creation. The attacker may
						tries to replace them and take advantage of a race condition.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text/>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use safe libraries to access resources such as files.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Be aware that improper use of access function calls such as chown(),
						tempfile(), chmod(), etc. can cause a race condition.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use synchronization to control the flow of execution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use static analysis tools to find race conditions.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Pay attention to concurrency problems related to the access of
						resources.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text/>
				</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>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>368</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>363</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>366</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>370</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>362</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>662</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>689</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>667</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>665</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>172<!--Time and State Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Low</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Medium</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Race Conditions</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>Wikipedia, http://en.wikipedia.org/wiki/Race_condition</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>David Wheeler - Prevent race conditions -
							http://www-128.ibm.com/developerworks/linux/library/l-sprace.html</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>David Wheeler - Secure programming -
							http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eric Dalci</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-01-25</Submission_Date>
						<Submission_Comment/>
					</Submission>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Sean Barnum</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-03-07</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, Attack Flow and Attack Prerequisites</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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="27" Name="Leveraging Race Conditions via Symbolic Links"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack leverages the use of symbolic links (Symlinks) in order to
						write to sensitive files. An attacker can create a Symlink link to a target
						file not otherwise accessible to her. When the privileged program tries to
						create a temporary file with the same name as the Symlink link, it will
						actually write to the target file pointed to by the attacker's Symlink link.
						If the attacker can insert malicious content in the temporary file she will
						be writing to the sensitive file by using the Symlink. The race occurs
						because the system checks if the temporary file exists, then creates the
						file. The attacker would typically create the Symlink during the interval
						between the check and the creation of the temporary file.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="-1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Verify that target host's platform
											supports symbolic links.</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>This attack pattern is only applicable on
												platforms that support symbolic links.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Research target platform to determine
												whether it supports symbolic links.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Create a symbolic link and ensure that it
												works as expected on the given platform.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Target platform supports
												symbolic links (e.g. Linux, UNIX,
												etc.)</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Target platform does not
												support symbolic links (e.g. MS
												Windows)</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Examine application's file I/O
											behavior</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Analyze the application's file I/O behavior to
												determine where it stores files, as well as the
												operations it performs to read/write files.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use kernel tracing utility such as ktrace to
												monitor application behavior</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Use debugging utility such as File Monitor
												to monitor the application's filesystem I/O
												calls</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Watch temporary directories to see when
												temporary files are created, modified and
												deleted.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Analyze source code for open-source systems
												like Linux, Apache, etc.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Attacker can watch files being created,
												modified and/or deleted by application.</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Indicator>
											<Indicator ID="2" type="Inconclusive">
												<Indicator_Description>
												<Text>Application does not seem to perform any
												filesystem I/O operations.</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Attacker identifies at least
												one reproducable file I/O operation performed by
												the application.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Attacker cannot identify any
												file I/O operations being performed by the
												application.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="-1" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="-1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Verify ability to write to
											filesystem</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker verifies ability to write to the
												target host's file system.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Create a file that does not exist in the
												target directory (e.g. "touch temp.txt" in
												UNIX-like systems)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>On platforms that differentiate between file
												creation and file modification, if the target file
												that the application writes to already exists,
												attempt to modify it.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Verify permissions on target
												directory</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="-1" type="Positive">
												<Indicator_Description>
												<Text>Target directory is a globally writable temp
												directory (e.g. /tmp in many UNIX-like
												systems)</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Indicator>
											<Indicator ID="-1" type="Positive">
												<Indicator_Description>
												<Text>Target directory is writable by the
												attacker's effective user ID.</Text>
												</Indicator_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="0" type="Success">
												<Outcome_Description>Attacker can create and modify
												files in the target
												directory.</Outcome_Description>
											</Outcome>
											<Outcome ID="0" type="Failure">
												<Outcome_Description>Attacker cannot create or
												modify files in the target
												directory.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="0" type="Preventative">
												<Security_Control_Description>Store temporary files
												in a directory with limited permissions where
												malicious users cannot tamper with
												them.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="-1" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="-1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Replace file with a symlink to a
											sensitive system file.</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Between the time that the application checks to
												see if a file exists (or if the user has access to
												it) and the time the application actually opens the
												file, the attacker replaces the file with a symlink
												to a sensitive system file.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Create an infinite loop containing commands
												such as "rm -f tempfile.dat; ln -s /etc/shadow
												tempfile.dat". Wait for an instance where the
												following steps occur in the given order: (1)
												Application ensures that tempfile.dat exists and
												that the user has access to it, (2) "rm -f
												tempfile.dat; ln -s /etc/shadow tempfile.dat", and
												(3) Application opens tempfile.dat for writing,
												and inadvertently opens /etc/shadow for writing
												instead.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="-1">
												<Attack_Step_Technique_Description>
												<Text>Use other techniques with debugging tools to
												replace the file between the time the application
												checks the file and the time the application opens
												it.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Embedded env-Local</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="0" type="Success">
												<Outcome_Description>Sensitive file tampered with
												successfully.</Outcome_Description>
											</Outcome>
											<Outcome ID="0" type="Failure">
												<Outcome_Description>Sensitive file could not be
												tampered with.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="0" type="Preventative">
												<Security_Control_Description>Use file handles to
												check existence of files, to check permissions and
												to open them. Do not use filename except to obtain
												a handle initially.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="0" type="Preventative">
												<Security_Control_Description>Drop application's
												permissions to the current user's permissions
												before performing any file I/O operations (e.g.
												using Process.as_uid() in
												Ruby).</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="0" type="Corrective">
												<Security_Control_Description>Run application with
												minimal permissions. In particular, avoid running
												applications as root on UNIX-like systems and as
												Administrator on Windows
												systems.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The attacker is able to create Symlink links on the target host.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>Tainted data from the attacker is used and copied to temporary
						files.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The target host does insecure temporary file creation.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
				<Method_of_Attack>Time and State</Method_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>In this naive example, the Unix program foo is setuid. Its function is
							to retrieve information for the accounts specified by the user. For
							"efficiency," it sorts the requested accounts into a temporary file
							(/tmp/foo naturally) before making the queries.</Text>
						<Text>The directory /tmp is world-writable. Malicious user Mallory creates a
							symbolic link to the file /.rhosts named /tmp/foo. Then, she invokes foo
							with + + as the requested account. The program creates the (temporary)
							file /tmp/foo (really creating /.rhosts) and puts the requested account
							(+ +) in it. It removes the temporary file (merely removing the symbolic
							link).</Text>
						<Text>Now the /.rhosts contains + +, which is the incantation necessary to
							allow anyone to use rlogin to log into the computer as the
							superuser.</Text>
						<Text>(Source : Wikipedia
							(http://en.wikipedia.org/wiki/Symlink_race)).</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>GNU ed before 0.3 allows local users to overwrite arbitrary files via
							a symlink attack on temporary files, possibly in the open_sbuf
							function.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2006-6939</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>OpenmosixCollector and OpenMosixView in OpenMosixView 1.5 allow local
							users to overwrite or delete arbitrary files via a symlink attack on (1)
							temporary files in the openmosixcollector directory or (2)
							nodes.tmp.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2005-0894</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Setuid product allows file reading by replacing a file being edited
							with a symlink to the targeted file, leaking the result in error
							messages when parsing fails.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2000-0972</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>This attack is sophisticated because the attacker has to overcome a
							few challenges such as creating symlinks on the target host during a
							precise timing, inserting malicious data in the temporary file and have
							knowledge about the temporary files created (file name and function
							which creates them).</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>The attacker will certainly look for file system locations where he can
						write and create Symlink links.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The attacker may also observe the system and locate the temporary files
						created during a call to a certain function.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use safe libraries when creating temporary files. For instance the
						standard library function mkstemp can be used to safely create temporary
						files. For shell scripts, the system utility mktemp does the same
						thing.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Access to the directories should be restricted as to prevent attackers
						from manipulating the files. Denying access to a file can prevent an
						attacker from replacing that file with a link to a sensitive file.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Follow the principle of least privilege when assigning access rights to
						files.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Ensure good compartmentalization in the system to provide protected areas
						that can be trusted.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>The content of the temporary file which is copied to the file pointed to by
					the Symlink.</Text>
			</Injection_Vector>
			<Payload>
				<Text>The content of the file overwriten when writing to the Symlink.</Text>
			</Payload>
			<Activation_Zone>
				<Text>The new content of the targeted file.</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>This attack can cause privilege escalation, modification of resources or
					denial of services.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>367</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>61</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>662</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>689</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>667</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>29<!--Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>26<!--Leveraging Race Conditions--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>Symlink Race, Wikipedia -
							http://en.wikipedia.org/wiki/Symlink_race</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>Safe temporary file creation with mkstemp -
							http://www.opengroup.org/onlinepubs/009695399/functions/mkstemp.html</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eric Dalci</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-02-01</Submission_Date>
						<Submission_Comment/>
					</Submission>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Sean Barnum</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-03-08</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, Likelihood 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>
					<Modification>
						<Modifier>Amit Sethi</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-29</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="87" Name="Forceful Browsing" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attacker employs forceful browsing to access portions of a website that
						are otherwise unreachable through direct URL entry.</Text>
					<Text>Usually, a front controller or similar design pattern is employed to
						protect access to portions of a web application.</Text>
					<Text>Forceful browsing enables an attacker to access information, perform
						privileged operations and otherwise reach sections of the web appplication
						that have been improperly protected.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Spider</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Using an automated tool, an attacker follows all
												public links on a web site. He records all the links
												he finds.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use a spidering tool to follow and record
												all links</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Use a proxy tool to record all links visited
												during a manual traversal of the web
												application.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>A list of links is created by
												the attacker.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor velocity of
												page fetching in web logs. Humans who view a page
												and select a link from it will click far slower
												and far less regularly than tools. Tools make
												requests very quickly and the requests are
												typically spaced apart regularly (e.g. 0.8 seconds
												between them).</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Detective">
												<Security_Control_Description>Create links on some
												pages that are visually hidden from web browsers.
												Using IFRAMES, images, or other HTML techniques,
												the links can be hidden from web browsing humans,
												but visible to spiders and programs. A request for
												the page, then, becomes a good predictor of an
												automated tool probing the
												application.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Actively monitor the
												application and either deny or redirect requests
												from origins that appear to be
												automated.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Attempt well known or guessable resource
											locations</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Using an automated tool, an attacker requests a
												variety of well-known URLs that correspond to
												administrative, debugging, or other useful internal
												actions. He records all the positive responses from
												the server.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Use a spidering tool to follow and record
												attempts on well known URLs</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Use a proxy tool to record all links visited
												during a manual traversal of attempts on well
												known URLs.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Common resource identifiers are used (e.g.,
												/admin/, admin.jsp, admin.aspx, etc.)</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Well known middleware or application
												platforms are used (e.g., Cold Fusion, WebSphere,
												WebLogic, JBoss, etc.)</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The attacker discovers one or
												more unprotected resources.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor errors (e.g.,
												404 not found) from web servers, application
												servers, and other HTTP infrastructure (e.g., load
												balancers). Alert on an unusual number of
												consecutive failures or total failures from a
												single host. Potentially alert on many failures
												from many different hosts, but in a relatively
												short time window.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Detective">
												<Security_Control_Description>Create "honeypot" web
												pages or scripts that do not actually have any use
												in the application, and name them common names
												(e.g., admin.jsp, admin.do, admin.aspx, etc.).
												Alert when one of these resources is
												requested.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Actively monitor the
												application and either deny or redirect requests
												from origins that appear to be generating an
												unusual amount of
												failures.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="4" type="Corrective">
												<Security_Control_Description>Obtain a list of
												sensitive areas that should not be directly
												accessible (e.g., JSPs or other templates that
												should only be accessible via front controllers).
												Apply an external mechanism (rule in the load
												balancer, rule in the reverse proxy, etc.) to
												intercept and redirect requests for those
												resources. Ideally use patterns, not specific page
												names (e.g., /jsp/* instead of a list of
												individual JSPs). Regularly update the list that
												is used in
												operation.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="5" type="Detective">
												<Security_Control_Description>Identify defaults for
												platform-specific sensitive resources. If the
												application does not use those defaults, alert on
												all requests for them (e.g.,
												http://server:8080/admin/)</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Use unauthorized
											resources</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>By visiting the unprotected resource, the attacker
												makes use of unauthorized functionality.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Access unprotected functions and execute
												them.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Malformed log entries
												are a common side-effect of this kind of attack.
												E.g., "User xyz deleted by on 10/16/07." The "by
												on" indicates that no authorized user was
												recorded. (A good entry would say "user xyz
												deleted by admin on 10/16/07"). Monitoring of log
												file entries for correct and consistent output
												format can indicate this kind of attack
												succeeding.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>View unauthorized
											data</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker discovers and views unprotected
												sensitive data.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Direct request of protected pages that
												directly access database back-ends. (e.g.,
												list.jsp, accounts.jsp, status.jsp, etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Dynamic pages (JSP, ASP, PHP, etc.) exist
												that divulge sensitive data without first checking
												authorization.</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
										</Indicators>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The forcibly browsable pages or accessible resources must be discoverable
						and improperly protected.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very High</Likelihood>
				<Explanation>
					<Text>A number of automated crawlers as well as other tools are available that
						generally perform a good job at looking for forcefully browsable
						pages</Text>
				</Explanation>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Brute Force</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>A bulletin board application provides an administrative interface at
							admin.aspx when the user logging in belongs to the administrators
							group.</Text>
						<Text>An attacker can access the admin.aspx interface by making a direct
							request to the page. Not having access to the interface appropriately
							protected allows the attacker to perform admnistrative functions without
							having to authenticate himself in that role.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>Forcibly browsable pages can be discovered by using a number of
							automated tools. Doing the same manually is tedious but by no means
							difficult</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>A directory listing is helpful but not a requirement. No special resources are
					required.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Following all the links recursively reveals resources that are
						available</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>Having a directory listing also points to the available pages and
						resources in the application that may be forcibly browsable.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Authenticate request to every resource. In addition, every page or
						resource must ensure that the request it is handling has been made in an
						authorized context.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Forceful browsing can also be made difficult to a large extent by not
						hard-coding names of application pages or resources. This way, the attacker
						cannot figure out, from the application alone, the resources available from
						the present context.</Text>
				</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>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>425</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>285</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Vulnerabilities>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2007-1156</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>JBrowser allows remote attackers to bypass authentication and access
							certain administrative capabilities via a direct request for
							_admin/.</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
				<Related_Vulnerability>
					<Vulnerability_ID>CVE-2007-1062</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>The Cisco Unified IP Conference Station 7935 3.2(15) and earlier, and
							Station 7936 3.3(12) and earlier does not properly handle administrator
							HTTP sessions, which allows remote attackers to bypass authentication
							controls via a direct URL request to the administrative HTTP interface
							for a limited time</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
			</Related_Vulnerabilities>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>210<!--Abuse of Functionality--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Complete Mediation</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Reluctance To Trust</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Treat the Entire Inherited Process Context as Unvalidated Input</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Use Authentication Mechanisms, Where Appropriate, Correctly</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Chiradeep B. Chhaya</Submitter>
						<Submission_Date>2007-03-13</Submission_Date>
						<Submission_Comment>First Draft</Submission_Comment>
					</Submission>
				</Submissions>
				<Modifications>
					<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>
					<Modification>
						<Modifier>Paco Hope</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-20</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="28" Name="Fuzzing" Pattern_Completeness="Complete"
			Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>Fuzzing is a software testing method that feeds randomly constructed input
						to the system and looks for an indication that a failure in response to that
						input has occured. Fuzzing treats the system as a blackbox and is totally
						free from any preconceptions or assumptions about the system.</Text>
					<Text>An attacker can leverage fuzzing to try to identify weaknesses in the
						system. For instance fuzzing can help an attacker discover certain
						assumptions made in the system about user input. Fuzzing gives an attacker a
						quick way of potentially uncovering some of these assumptions without really
						knowing anything about the internals of the system. These assumptions can
						then be turned against the system by specially crafting user input that may
						allow an attacker to achieve his goals.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Observe communication and
											inputs</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The fuzzing attacker observes the target system
												looking for inputs and communications between
												modules, subsystems, or systems.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Network sniffing. Using a network sniffer
												such as wireshark, the attacker observes
												communications into and out of the target
												system.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Monitor API execution. Using a tool such as
												ktrace, strace, APISpy, or another debugging tool,
												the attacker observes the system calls and API
												calls that are made by the target system, and the
												nature of their parameters.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Observe inputs using web inspection tools
												(OWASP's WebScarab, Paros, TamperData, TamperIE,
												etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The attacker creates a list of
												unique communications packets, messages, inputs,
												API calls or other actions the software
												takes.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Alert on promiscuous
												mode. Some network devices (switches, hubs) or
												monitoring stations (e.g., IDS) can detect and
												alert when a station in the network is passively
												eavesdropping.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Some production
												hardware (for embedded environments) can have
												debugging disabled on the
												hardware.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Techniques exist to
												insert no-ops and other null branches that thwart
												basic attempts to execute software stepwise in a
												debugger.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Generate fuzzed
											inputs</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Given a fuzzing tool, a target input or protocol,
												and limits on time, complexity, and input variety,
												generate a list of inputs to try. Although fuzzing
												is random, it is not exhaustive. Parameters like
												length, composition, and how many variations to try
												are important to get the most cost-effective impact
												from the fuzzer.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Boundary cases. Generate fuzz inputs that
												attack boundary cases of protocol fields, inputs,
												or other communications limits. Examples include
												0xff and 0x00 for single-byte inputs. In binary
												situations, approach each bit of an individual
												field with on and off (e.g., 0x80).</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Attempt arguments to system calls or APIs.
												The variations include payloads that, if they were
												successful, could lead to a compromise on the
												system.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Log unexpected
												parameters to API calls or system
												calls.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Profile the software's
												expected use of system calls. Use a sandboxing
												technique to restrict its API calls to the
												expected patterns.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>SSL or other
												link-layer encryption techniques (VPN, 802.11x,
												etc.) can impair simple observation and require a
												would-be attacker to work much harder to get
												information about the operation of the
												software..</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Observe the outcome</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Observe the outputs to the inputs fed into the
												system by fuzzers and see if anything interesting
												happens. If failure occurs, determine why that
												happened. Figure out the underlying assumption that
												was invalidated by the input.</Text>
										</Attack_Step_Description>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>The software produces an indicator that the
												attacker can see (error message, altered error
												state in a protocol, etc.).</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>The previous step led to plausible,
												practical fuzz inputs.</Text>
												</Indicator_Description>
												<Environments>env-All</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>If the software's indicators
												(error messages, etc.) vary clearly based on the
												attacker's input, then the attacker has a
												sufficient starting point for customizing his
												attack.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>The attacker is unable to
												induce unexpected failures or output based fuzzed
												inputs.</Outcome_Description>
											</Outcome>
										</Outcomes>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="3" Name="Exploit">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Craft exploit
											payloads</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Put specially crafted input into the system that
												leverages the weakness identified through fuzzing
												and allows to achieve the goals of the attacker.
												Fuzzers often reveal ways to slip through the input
												validation filters and introduce unwanted data into
												the system.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Identify and embed shellcode for the target
												system.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Embed higher level attack commands in the
												payload. (e.g., SQL, PHP, server-side includes,
												etc.)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web env-CommProtocol env-Peer2Peer
												env-ClientServer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Induce denial of service by exploiting
												resource leaks or bad error handling.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Monitor system logs
												and alert on unusual activity. Most shellcode and
												unusual activity appears in
												logs.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Typical_Severity>Medium</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
				<Method_of_Attack>Injection</Method_of_Attack>
				<Method_of_Attack>Brute Force</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>A fuzz test reveals that when data length for a particular field
							exceeds certain length, the input validation filter fails and lets the
							user data in unfiltered. This provides an attacker with an injection
							vector to deliver the malicious payload into the system.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>There is a wide variety of fuzzing tools available.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Fuzzing tools.</Text>
			</Resources_Required>
			<Indicators-Warnings_of_Attack>
				<Indicator-Warning_of_Attack>
					<Text>A lot of invalid data is fed to the system. Data that cannot have been
						generated through a legitimate transaction/request. Data is coming into the
						system within a short period of time and potentially from the same
						IP.</Text>
				</Indicator-Warning_of_Attack>
			</Indicators-Warnings_of_Attack>
			<Obfuscation_Techniques>
				<Obfuscation_Technique>
					<Text>Take pauses between fuzzing attempts (may not be very practical). Spoof IP
						addresses so that it does not look like all data is coming from the same
						source.</Text>
				</Obfuscation_Technique>
			</Obfuscation_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Test to ensure that the software behaves as per specification and that
						there are no unintended side effects. Ensure that no assumptions about the
						validity of data are made.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use fuzz testing during the software QA process to uncover any surprises,
						uncover any assumptions or unexpected behavior.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<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-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>74</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>388</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>728</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>223<!--Probabilistic Techniques--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Reconnaissance</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Medium</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eugene Lebanidze</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-02-26</Submission_Date>
					</Submission>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="29"
			Name="Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack targets a race condition occurring between the time of check
						(state) for a resource and the time of use of a resource. The typical
						example is the file access. The attacker can leverage a file access race
						condition by "running the race", meaning that he would modify the resource
						between the first time the target program accesses the file and the time the
						target program uses the file. During that period of time, the attacker could
						do something such as replace the file and cause an escalation of
						privilege.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker explores to gauge what level of
												access he has.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker confirms access to a resource on the
												target host. The attacker confirms ability to modify
												the targeted resource.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>The attacker decides to leverage the race
												condition by "running the race", meaning that he
												would modify the resource between the first time the
												target program accesses the file and the time the
												target program uses the file. During that period of
												time, the attacker can replace the resource and
												cause an escalation of privilege.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>A resource is access/modified concurrently by multiple processes.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>The attacker is able to modify resource.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>A race condition exists while accessing a resource.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Time and State</Method_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The Net Direct client for Linux before 6.0.5 in Nortel Application
							Switch 2424, VPN 3050 and 3070, and SSL VPN Module 1000 extracts and
							executes files with insecure permissions, which allows local users to
							exploit a race condition to replace a world-writable file in
							/tmp/NetClient and cause another user to execute arbitrary code when
							attempting to execute this client, as demonstrated by replacing
							/tmp/NetClient/client.</Text>
					</Example-Instance_Description>
					<Example-Instance_Related_Vulnerabilities>
						<Example-Instance_Related_Vulnerability>
							<Text>CVE-2007-1057</Text>
						</Example-Instance_Related_Vulnerability>
					</Example-Instance_Related_Vulnerabilities>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>The following code illustrates a file that is accessed multiple times
							by name in a publicly accessible directory. A race condition exists
							between the accesses where an attacker can replace the file referenced
							by the name.</Text>
						<Block>
							<Code>include &lt;sys/types.h&gt;</Code>
							<Code>include &lt;fcntl.h&gt;</Code>
							<Code>include &lt;unistd.h&gt;</Code>
							<Code/>
							<Code>define FILE "/tmp/myfile"</Code>
							<Code>define UID 100</Code>
							<Code/>
							<Code>void test(char *str)</Code>
							<Code>{</Code>
							<Block>
								<Code>int fd;</Code>
								<Code>fd = creat(FILE, 0644);</Code>
								<Code>if(fd == -1)</Code>
								<Block>
									<Code>return;</Code>
								</Block>
								<Code>chown(FILE, UID, -1); /* BAD */</Code>
								<Code>close(fd);</Code>
							</Block>
							<Code>}</Code>
							<Code/>
							<Code>int main(int argc, char **argv)</Code>
							<Code>{</Code>
							<Block>
								<Code>char *userstr;</Code>
								<Code>if(argc &gt; 1) {</Code>
								<Block>
									<Code>userstr = argv[1];</Code>
									<Code>test(userstr);</Code>
								</Block>
								<Code>}</Code>
								<Code>return 0;</Code>
							</Block>
							<Code>}</Code>
							<Code/>
							<Code>//Source : SAMATE.NIST.GOV :
								http://samate.nist.gov/SRD/view_testcase.php?login=Guest&amp;;tID=1598</Code>
						</Block>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>This attack can get sophisticated since the attack has to occur within
							a short interval of time.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required/>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Vulnerability testing tool can be used to probe for race condition.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The attacker may also look for temporary file creation. The attacker may
						try to replace them and take advantage of a race condition.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Use safe libraries to access resources such as files.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Be aware that improper use of access function calls such as chown(),
						tempfile(), chmod(), etc. can cause a race condition.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use synchronization to control the flow of execution.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Use static analysis tools to find race conditions.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Pay attention to concurrency problems related to the access of
						resources.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>367</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>368</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>366</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>370</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>362</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>662</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>691</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>663</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>665</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>26<!--Leveraging Race Conditions--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>172<!--Time and State Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Description>
						<Text>J. Viega and G. McGraw. Building Secure Software. Addison-Wesley,
							2002.</Text>
					</Reference_Description>
				</Reference>
				<Reference>
					<Reference_Description>
						<Text>CWE - Input Validation</Text>
					</Reference_Description>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<Submission>
						<Submitter>Eric Dalci</Submitter>
						<Submitter_Organization>Cigital, Inc</Submitter_Organization>
						<Submission_Date>2007-01-25</Submission_Date>
						<Submission_Comment/>
					</Submission>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Sean Barnum</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-03-07</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
							Flow, 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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="30" Name="Hijacking a Privileged Thread of Execution"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>Attackers can sometimes hijack a privileged thread from the underlying
						system through synchronous (calling a privileged function that returns
						incorrectly) or asynchronous (callbacks, signal handlers, and similar)
						means.</Text>
					<Text>Having done so, the Attacker may not only likely access functionality the
						system's designer didn't intend for them, but they may also go undetected or
						deny other users essential service in a catastrophic (or insidiously subtle)
						way.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Attacker determines the underlying system thread
												that is subject to user-control</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Attacker then provides input, perhaps by way of
												environment variables for the process in question,
												that affect the executing thread</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Upon successful hijacking, the attacker enjoys
												elevated privileges, and can possibly have the
												hijacked thread do his bidding</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The application in question employs a threaded model of execution with the
						threads operating at, or having the ability to switch to, a higher privilege
						level than normal users</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>In order to feasibly execute this class of attacks, the attacker must have
						the ability to hijack a privileged thread.</Text>
					<Text>This ability includes, but is not limited to, modifying environment
						variables that affect the process the thread belongs to, or providing
						malformed user-controllable input that causes the executing thread to fault
						and return to a higher privilege level or such.</Text>
					<Text>This does not preclude network-based attacks, but makes them conceptually
						more difficult to identify and execute.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Low</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Attacker targets an application written using Java's AWT, with the
							1.2.2 era event model. In this circumstance, any AWTEvent originating in
							the underlying OS (such as a mouse click) would return a privileged
							thread. The Attacker could choose to not return the AWT-generated thread
							upon consuming the event, but instead leveraging its privilege to
							conduct privileged operations.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>High</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>Hijacking a thread involves knowledge of how processes and threads
							function on the target platform, the design of the target application as
							well as the ability to identify the primitives to be used or manipulated
							to hijack the thread.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>The attacker needs to be able to latch onto a privileged thread. No special
					hardware or software tool-based resources are required.</Text>
				<Text>The Attacker does, however, need to be able to program, compile, and link to
					the victim binaries being executed so that it will turn control of a privileged
					thread over to the Attacker's malacious code. This is the case even if the
					attacker conducts the attack remotely.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>The attacker may attach a debugger to the executing process and observe
						the spawning and clean up of threads, as well as the switches in privilege
						levels</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>The attacker can also observe the environment variables, if any, that
						affect executing threads and modify them in order to observe their effect on
						the execution.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Application Architects must be careful to design callback, signal, and
						similar asynchronous constructs such that they shed excess privilege prior
						to handing control to user-written (thus untrusted) code.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Application Architects must be careful to design privileged code blocks
						such that upon return (successful, failed, or unpredicted) that privilege is
						shed prior to leaving the block/scope.</Text>
				</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-Consequences>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>270</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>232<!--Exploitation of Privilege/Trust--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>Only those constructs within the application that cannot execute without
						elevated privileges must be granted additional privileges. Often times, the
						entire function or the entire process is granted privileges that are usually
						not necessary.</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>The callee must ensure that additional privileges are shed before
						returning to the caller. This avoids pinning the responsibility on an
						inadvertant caller who may not have a clue about the innards of the
						callee.</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Least Privilege</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Complete Mediation</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Minimize privileged code blocks</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Shed any privileges not required to execute at the earliest</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Treat the Entire Inherited Process Context as Unvalidated Input</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<Modification>
						<Modifier>Chiradeep B. Chhaya</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-02-28</Modification_Date>
						<Modification_Comment>Fleshed out pattern with extra
							content</Modification_Comment>
					</Modification>
					<Modification>
						<Modifier>Sean Barnum</Modifier>
						<Modifier_Organization>Cigital, Inc</Modifier_Organization>
						<Modification_Date>2007-03-07</Modification_Date>
						<Modification_Comment>Review and revise</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="31" Name="Accessing/Intercepting/Modifying HTTP Cookies"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack relies on the use of HTTP Cookies to store credentials, state
						information and other critical data on client systems.</Text>
					<Text>The first form of this attack involves accessing HTTP Cookies to mine for
						potentially sensitive data contained therein.</Text>
					<Text>The second form of this attack involves intercepting this data as it is
						transmitted from client to server. This intercepted information is then used
						by the attacker to impersonate the remote user/session.</Text>
					<Text>The third form is when the cookie's content is modified by the attacker
						before it is sent back to the server. Here the attacker seeks to convince
						the target server to operate on this falsified information.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Obtain copy of cookie</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker first needs to obtain a copy of the
												cookie. The attacker may be a legitimate end user
												wanting to escalate privilege, or could be somebody
												sniffing on a network to get a copy of HTTP
												cookies.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Obtain cookie from local filesystem (e.g.
												C:\Documents and Settings\*\Cookies and
												C:\Documents and Settings\*\Application
												Data\Mozilla\Firefox\Profiles\*\cookies.txt in
												Windows)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Sniff cookie using a network sniffer such as
												Wireshark</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Obtain cookie from local memory or
												filesystem using a utility such as the Firefox
												Cookie Manager or AnEC Cookie Editor.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Steal cookie via a cross-site scripting
												attack.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="5">
												<Attack_Step_Technique_Description>
												<Text>Guess cookie contents if it contains
												predictable information.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Cookies used in web application.</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Cookies not used in web application.</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Cookie captured by
												attacker.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Cookie cannot be captured by
												attacker.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>To prevent network
												sniffing, cookies should be transmitted over HTTPS
												and not plain HTTP. To enforce this on the client
												side, the "secure" flag should be set on cookies
												(javax.servlet.http.Cookie.setSecure() in Java,
												secure flag in setcookie() function in php,
												etc.).</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="-1" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Obtain sensitive information from
											cookie</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker may be able to get sensitive
												information from the cookie. The web application
												developers may have assumed that cookies are not
												accessible by end users, and thus, may have put
												potentially sensitive information in them.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>If cookie shows any signs of being encoded
												using a standard scheme such as base64, decode
												it.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Analyze the cookie's contents to determine
												whether it contains any sensitive
												information.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Negative">
												<Indicator_Description>
												<Text>Cookie only contains a random session ID
												(e.g. ASPSESSIONID, JSESSIONID, etc.)</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="2" type="Positive">
												<Indicator_Description>
												<Text>Cookie contains sensitive information (e.g.
												"ACCTNO=0234234", or "DBIP=0xaf112a22" -- database
												server's IP address).</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
											<Indicator ID="3" type="Inconclusive">
												<Indicator_Description>
												<Text>Cookie's contents cannot be
												deciphered.</Text>
												</Indicator_Description>
												<Environments>env-Web</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Cookie contains sensitive
												information that developer did not intent the end
												user to see.</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Cookie does not contain any
												sensitive information.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="3" type="Preventative">
												<Security_Control_Description>Do not store sensitive
												information in cookies unless they are encrypted
												such that only the server can decrypt
												them.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Title>Modify cookie to subvert security
											controls.</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker may be able to modify or replace
												cookies to bypass security controls in the
												application.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Modify logical parts of cookie and send it
												back to server to observe the effects.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Modify numeric parts of cookie
												arithmetically and send it back to server to
												observe the effects.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Modify cookie bitwise and send it back to
												server to observe the effects.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Replace cookie with an older legitimate
												cookie and send it back to server to observe the
												effects. This technique would be helpful in cases
												where the cookie contains a "points balance" for a
												given user where the points have some value. The
												user may spend his points and then replace his
												cookie with an older one to restore his
												balance.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Web</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>Subversion of security controls
												on server</Outcome_Description>
											</Outcome>
											<Outcome ID="2" type="Failure">
												<Outcome_Description>Cookie reset by
												server</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Detective">
												<Security_Control_Description>Web server logs
												contain many messages indicating that invalid
												cookies were received from
												client.</Security_Control_Description>
											</Security_Control>
											<Security_Control ID="2" type="Preventative">
												<Security_Control_Description>Cookies should not
												contain any information that the user is not
												allowed to modify, unless that information is
												never expected to change. In the latter case, the
												integrity of the cookie should be protected using
												a digital signature or a message authentication
												code.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>Target server software must be a HTTP daemon that relies on
						cookies.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Modification of Resources</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
				<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
				<Method_of_Attack>Time and State</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>There are two main attack vectors for exploiting poorly protected
							session variables like cookies. One is the local machine itself which
							can be exploited directly at the physical level or indirectly through
							XSS and phising. In addition, the man in the middle attack relies on a
							network sniffer, proxy, or other intermediary to intercept the subject's
							credentials and use them to impersonate the digital subject on the host.
							The issue is that once the credentials are intercepted, impersonation is
							trivial for the attacker to accomplish if no other protection mechanisms
							are in place.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>To overwrite session cookie data, and submit targeted attacks via
							HTTP</Text>
						<Text>High: Exploiting a remote buffer overflow generated by attack</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to send HTTP request containing cookie to server</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Use input validation for cookies</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Generate and validate MAC for cookies</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Use SSL/TLS to protect cookie in transit </Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Ensure the web server implements all relevant security
						patches, many exploitable buffer overflows are fixed in patches issued for
						the software. </Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<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>
				<Text>HTTP cookie</Text>
			</Injection_Vector>
			<Payload>
				<Text> Malicious input delivered through cookie in HTTP Request.</Text>
			</Payload>
			<Activation_Zone>
				<Text> Client software, such as a browser and its component libraries, or an
					intermediary</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Block Block_Nature="List">
					<Text>1. Enables attacker to leverage state stored in cookie</Text>
					<Text>2. Enables attacker a vector to attack web server and platform</Text>
				</Block>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>565</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>302</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>113</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>539</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>20</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>315</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>384</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>472</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>724</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>602</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>642</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>39<!--Manipulating Opaque Client-based Data Tokens--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>21<!--Exploitation of Session Variables, Resource IDs and other Trusted Credentials--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>255<!--Data Structure Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>117<!--Data Interception Attacks--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>262<!--Resource Manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
					<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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 and
							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>
					<Modification>
						<Modifier>Amit Sethi</Modifier>
						<Modifier_Organization>Cigital, Inc.</Modifier_Organization>
						<Modification_Date>2007-10-29</Modification_Date>
						<Modification_Comment>Added extended Attack Execution
							Flow</Modification_Comment>
					</Modification>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="35" Name="Leverage Executable Code in Nonexecutable Files"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attack of this type exploits a system's trust in configuration and
						resource files, when the executable loads the resource (such as an image
						file or configuration file) the attacker has modified the file to either
						execute malicious code directly or manipulate the target process (e.g.
						application server) to execute based on the malicious configuration
						parameters. Since systems are increasingly interrelated mashing up resources
						from local and remote sources the possibility of this attack occurring is
						high.</Text>
					<Text>The attack can be directed at a client system, such as causing buffer
						overrun through loading seemingly benign image files, as in Microsoft
						Security Bulletin MS04-028 where specially crafted JPEG files could cause a
						buffer overrun once loaded into the browser. Another example targets clients
						reading pdf files. In this case the attacker simply appends javascript to
						the end of a legitimate url for a pdf
						(http://www.gnucitizen.org/blog/danger-danger-danger/)</Text>
					<Text>http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here</Text>
					<Text>The client assumes that they are reading a pdf, but the attacker has
						modified the resource and loaded executable javascript into the client's
						browser process.</Text>
					<Text>The attack can also target server processes. The attacker edits the
						resource or configuration file, for example a web.xml file used to configure
						security permissions for a J2EE app server, adding role name "public" grants
						all users with the public role the ability to use the administration
						functionality.</Text>
					<Block>
						<Code>&lt; security-constraint&gt;</Code>
						<Block>
							<Code>&lt;description&gt;Security processing rules for admin
								screens&lt;/description&gt;</Code>
							<Code>&lt;url-pattern&gt;/admin/*&lt;/url-pattern&gt;</Code>
							<Code>&lt;http-method&gt;POST&lt;/http-method&gt;</Code>
							<Code>&lt;http-method&gt;GET&lt;/http-method&gt;</Code>
							<Block>
								<Code>&lt;auth-constraint&gt;</Code>
								<Block>
									<Code>&lt;role-name&gt;administrator&lt;/role-name&gt;</Code>
									<Code>&lt;role-name&gt;public&lt;/role-name&gt;</Code>
								</Block>
								<Code>&lt;/auth-constraint&gt;</Code>
							</Block>
						</Block>
						<Code>&lt;/security-constraint&gt;</Code>
					</Block>
					<Text>The server trusts its configuration file to be correct, but when they are
						manipulated, the attacker gains full control.</Text>
				</Summary>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The attacker must have the ability to modify nonexecutable files consumed
						by the target software.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Injection</Method_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>
						<Text>Virtually any system that relies on configuration files for runtime
							behavior is open to this attack vector. The configuration files are
							frequently stored in predictable locations, so an attacker that can
							fingerpint a server process such as a web server or database server can
							quickly identify the likely locale where the configuration is stored.
							And this is of course not limited to server processes. Unix shells rely
							on profile files to store environment variables, search paths for
							programs and so on. If the aliases are changed, then a standard Unix
							"cp" command can be rerouted to "rm" or other standard command so the
							user's intention is subverted.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>To identify and execute against an overprivileged system
							interface</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>Ability to communicate synchronously or asynchronously with server that
					publishes an overprivileged directory, program, or itnerface. Optionally,
					ability to capture output directly through synchronous communication or other
					method such as FTP.</Text>
			</Resources_Required>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Design: Enforce principle of least privilege</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Design: Run server interfaces with a non-root account and/or utilize
						chroot jails or other configuration techniques to constrain privileges even
						if attacker gains some limited access to commands.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Perform testing such as pentesting and vulnerability
						scanning to identify directories, programs, and interfaces that grant direct
						access to executables.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Implement host integrity monitoring to detect any unwanted
						altering of configuration files.</Text>
				</Solution_or_Mitigation>
				<Solution_or_Mitigation>
					<Text>Implementation: Ensure that files that are not required to execute, such
						as configuration files, are not over-privileged, i.e. not allowed to
						execute.</Text>
				</Solution_or_Mitigation>
			</Solutions_and_Mitigations>
			<Attack_Motivation-Consequences>
				<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
				<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			</Attack_Motivation-Consequences>
			<Injection_Vector>
				<Text>Nonexecutable files</Text>
			</Injection_Vector>
			<Payload>
				<Text>Executable code</Text>
			</Payload>
			<Activation_Zone>
				<Text>Client machine and client network</Text>
			</Activation_Zone>
			<Payload_Activation_Impact>
				<Text>Enables attacker to execute server side code with any commands that the
					program owner has privileges to.</Text>
			</Payload_Activation_Impact>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>94</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>96</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>95</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>97</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>272</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>59</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>282</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>275</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>264</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>270</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>714</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Vulnerabilities>
				<Related_Vulnerability>
					<Vulnerability_ID>Microsoft Security Bulletin MS04-028</Vulnerability_ID>
					<Vulnerability_Description>
						<Text>Buffer Overrun in JPEG Processing (GDI+) Could Allow Code
							Execution</Text>
					</Vulnerability_Description>
				</Related_Vulnerability>
			</Related_Vulnerabilities>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>PeerOf</Relationship_Nature>
					<Relationship_Target_ID>23<!--File System Function Injection, Content Based--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID>1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>PeerOf</Relationship_Nature>
					<Relationship_Target_ID>75<!--Manipulating Writeable Configuration Files--></Relationship_Target_ID>
				</Related_Attack_Pattern>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>165<!--File Manipulation--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Purposes>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>Medium</Confidentiality_Impact>
				<Integrity_Impact>High</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<References>
				<Reference>
					<Reference_Author>G. Hoglund</Reference_Author>
					<Reference_Author>G. McGraw</Reference_Author>
					<Reference_Title>Exploiting Software: How to Break Code</Reference_Title>
					<Reference_Publisher>Addison-Wesley</Reference_Publisher>
					<Reference_PubDate>February 2004</Reference_PubDate>
				</Reference>
			</References>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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 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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="36" Name="Using Unpublished Web Service APIs"
			Pattern_Completeness="Complete" Pattern_Abstraction="Detailed" Status="Draft">
			<Description>
				<Summary>
					<Text>An attacker searches for and invokes Web Services APIs that the target
						system designers did not intend to be publicly available. If these APIs fail
						to authenticate requests the attacker may be able to invoke services and/or
						gain privileges they are not authorized for.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Discover a web service of interest, by exploring
												web service registry listings or by connecting on
												known port or some similar means</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="2">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Authenticate to the web service, if required, in
												order to explore it.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
								<Attack_Step ID="3">
									<Custom_Attack_Step>
										<Attack_Step_Description>
											<Text>Determine the exposed interfaces by querying the
												registry as well as probably sniffing to expose
												interfaces that are not explicitly listed.</Text>
										</Attack_Step_Description>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>The architecture under attack must publish or otherwise make available
						services, of some kind, that clients can attach to, either in an
						unauthenticated fashion, or having obtained an authentication token
						elsewhere.</Text>
					<Text>The service need not be 'discoverable' but in the event it isn't, must
						have some way of being discovered by an attacker.</Text>
					<Text>This might include listening on a well-known port. Ultimately, the
						likelihood of exploit depends on discoverability of the vulnerable
						service.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Medium</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
				<Method_of_Attack>API Abuse</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>To an extent, Google services (such as Google Maps) are all well-known
							examples. Calling these services, or extending them for one's own
							(perhaps very different) purposes is as easy as knowing they exist.
							Their unencumbered public use, however, is a purposeful aspect of
							Google's business model. Most organizations, however, do not have the
							same business model. Organizations publishing services usually fall back
							on thoughts that Attackers "will not know services exist" and that "even
							if they did, they wouldn't be able to access them because they're not on
							the local LAN." Simple threat modeling exercises usually uncovers simple
							attack vectors that can invalidate these assumptions.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Low</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>A number of web service digging tools are available for free that help
							discover exposed web services and their interfaces. In the event that a
							web service is not listed, the attacker does not need to know much more
							in addition to the format of web service messages that he can
							sniff/monitor for.</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>No special resources are required in order to conduct these attacks. Web
					service digging tools may be helpful.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Probing techniques should often follow normal means of identifying
						services. Attackers will simply have to execute code that sends the
						appropriate interrogating SOAP messages to suspected UDDI services (in
						web-services scenarios). Attackers will likely want to detect and query the
						organization's SOA Registry.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>Probing techniques become more difficult when the service isn't
						advertised, or doesn't leverage discovery frameworks such as UDDI or the
						WS-I standard. In these cases, sniffing network traffic may suffice,
						depending on whether or not discovery occurs over a protected
						channel.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Solutions_and_Mitigations>
				<Solution_or_Mitigation>
					<Text>Authenticating both services and their discovery, and protecting that
						authentication mechanism simply fixes the bulk of this problem. Protecting
						the authentication involves the standard means, including: 1) protecting the
						channel over which authentication occurs, 2) preventing the theft, forgery,
						or prediction of authentication credentials or the resultant tokens, or 3)
						subversion of password reset and the like.</Text>
				</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>
			<Injection_Vector/>
			<Payload/>
			<Activation_Zone/>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>306</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>693</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>695</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>113<!--API Abuse/Misuse--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>Authenticate every request or message to a service</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>Do not rely on lack of discoverability to protect privileged functions
						within the service</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Never Assuming that Your Secrets Are Safe</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Complete Mediation</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Use Authorization Mechanisms Correctly</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Use Authentication Mechanisms, Where Appropriate, Correctly</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Penetration</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>SOA</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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 Name and
							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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="37" Name="Lifting Data Embedded in Client Distributions"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>An attacker can resort to stealing data embedded in client distributions
						or client code in order to gain certain information. This information can
						reveal confidential contents, such as account numbers, or can be used as an
						intermediate step in a larger attack (such as by stealing
						keys/credentials).</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Identify Target</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>Attacker identifies client components to extract
												information from. These may be binary executables,
												class files, shared libraries (e.g., DLLs), or other
												machine code.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Binary file extraction. The attacker
												extracts binary files from zips, jars, wars, PDFs
												or other composite formats.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Package listing. The attacker uses a package
												manifest provided with the software installer, or
												the filesystem itself, to identify component files
												suitable for attack.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Proprietary or sensitive data is stored in a
												location ultimately distributed to end
												users.</Text>
												</Indicator_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Indicator>
											<Indicator ID="2" type="Negative">
												<Indicator_Description>
												<Text>Access to binary code is not realistic. For
												example, in a client-server environment, binary
												code on the server is presumed to be inscrutable
												to an attacker unless another vulnerability
												exposes it.</Text>
												</Indicator_Description>
												<Environments>env-Web env-ClientServer env-Peer2Peer
												env-CommProtocol</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The attacker identifies one or
												more files or data in the software to
												attack.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Preventative">
												<Security_Control_Description>Obfuscation can make
												the observation and reverse engineering more
												difficult. It is only capable of delaying an
												attacker, however, not preventing a sufficiently
												motivated and resourced
												one.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
						<Attack_Phase ID="2" Name="Experiment">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Apply mining
											techniques</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The attacker then uses a variety of techniques,
												such as sniffing, reverse-engineering, and
												cryptanalysis to extract the information of
												interest.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>API Profiling. The attacker monitors the
												software's use of registry keys or other operating
												system-provided storage locations that can contain
												sensitive information.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Execution in simulator. The attacker
												physically removes mass storage from the system
												and explores it using a simulator, external
												system, or other debugging harness.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="3">
												<Attack_Step_Technique_Description>
												<Text>Cryptanalysis. The attacker performs
												cryptanalysis to identify data in the client
												component which may be cryptographically
												significant. (Key material frequently stands out
												as very high entropy data when compared to other
												mundane data). Given cryptographically significant
												data, other analyses are performed (e.g., length,
												internal structure, etc.) to determine potential
												algorithms (RSA, ECC, AES, etc.). This process
												proceeds until the attacker reaches a conclusion
												about the significance and use of the data.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="4">
												<Attack_Step_Technique_Description>
												<Text>Common decoding methods. The attacker
												applies methods to decode such encodings and
												compressions as Base64, unzip, unrar, RLE
												decoding, gzip decompression and so on.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="5">
												<Attack_Step_Technique_Description>
												<Text>Common data typing. The attacker looks for
												common file signatures for well known file types
												(JPEG, TIFF, ASN.1, LDIF, etc.). If the signatures
												match, he attempts decoding in that format.</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
										</Attack_Step_Techniques>
										<Indicators>
											<Indicator ID="1" type="Positive">
												<Indicator_Description>
												<Text>Well known data types are used and embedded
												inside the client-accessible code.</Text>
												</Indicator_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Indicator>
											<Indicator ID="2" type="Inconclusive">
												<Indicator_Description>
												<Text>Proprietary data encodings are used.
												Although this incrementally increases the
												difficulty for an attacker to decode the data, it
												provides no better protection than well-known data
												types. Since few software developers are trained
												in obfuscation and cryptography, most proprietary
												encodings add little security value.</Text>
												</Indicator_Description>
												<Environments>env-Local env-Embedded
												env-ClientServer env-Peer2Peer</Environments>
											</Indicator>
										</Indicators>
										<Outcomes>
											<Outcome ID="1" type="Success">
												<Outcome_Description>The attacker extracts useful
												information.</Outcome_Description>
											</Outcome>
										</Outcomes>
										<Security_Controls>
											<Security_Control ID="1" type="Corrective">
												<Security_Control_Description>The software can
												contain an update mechanism, key management
												mechanism, or other means of updating proprietary
												data. Although this can react to a single breach,
												it is not an effective continuing solution. Many
												software manufacturers are lured into a repeated
												update cycle (c.f., satellite TV providers,
												iPhone) as hackers break proprietary data
												protection schemes. Planning to issue corrections
												is a poor long-term strategy, but it can be an
												effective stopgap measure until a design-level
												correction can be
												made.</Security_Control_Description>
											</Security_Control>
										</Security_Controls>
									</Custom_Attack_Step>
								</Attack_Step>
							</Attack_Steps>
						</Attack_Phase>
					</Attack_Phases>
				</Attack_Execution_Flow>
			</Description>
			<Attack_Prerequisites>
				<Attack_Prerequisite>
					<Text>In order to feasibly execute this class of attacks, some valuable data
						must be present in client software.</Text>
				</Attack_Prerequisite>
				<Attack_Prerequisite>
					<Text>Additionally, this information must be unprotected, or protected in a
						flawed fashion, or through a mechanism that fails to resist reverse
						engineering, statistical, cryptanalytic, or other attack.</Text>
				</Attack_Prerequisite>
			</Attack_Prerequisites>
			<Typical_Severity>Very High</Typical_Severity>
			<Typical_Likelihood_of_Exploit>
				<Likelihood>Very High</Likelihood>
				<Explanation/>
			</Typical_Likelihood_of_Exploit>
			<Methods_of_Attack>
				<Method_of_Attack>Analysis</Method_of_Attack>
			</Methods_of_Attack>
			<Examples-Instances>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Using a tool such as 'strings' or similar to pull out text data,
							perhaps part of a database table, that extends beyond what a particular
							user's purview should be.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>An attacker can also use a decompiler to decompile a downloaded Java
							applet in order to look for information such as hardcoded IP addresses,
							file paths, passwords or other such contents.</Text>
					</Example-Instance_Description>
				</Example-Instance>
				<Example-Instance>
					<Example-Instance_Description>
						<Text>Attacker uses a tool such as a browser plug-in to pull cookie or other
							token information that, from a previous user at the same machine
							(perhaps a kiosk), allows the attacker to log in as the previous
							user.</Text>
					</Example-Instance_Description>
				</Example-Instance>
			</Examples-Instances>
			<Attacker_Skills_or_Knowledge_Required>
				<Attacker_Skill_or_Knowledge_Required>
					<Skill_or_Knowledge_Level>Medium</Skill_or_Knowledge_Level>
					<Skill_or_Knowledge_Type>
						<Text>The attacker must possess knowledge of client code structure as well
							as ability to reverse-engineer or decompile it or probe it in other
							ways. This knowledge is specific to the technology and language used for
							the client distribution</Text>
					</Skill_or_Knowledge_Type>
				</Attacker_Skill_or_Knowledge_Required>
			</Attacker_Skills_or_Knowledge_Required>
			<Resources_Required>
				<Text>The attacker must possess access to the client machine or code being
					exploited. Such access, for this set of attacks, will likely be physical. The
					attacker will make use of reverse engineering technologies, perhaps for data or
					to extract functionality from the binary. Such tool use may be as simple as
					"Strings" or a hex editor. Removing functionality may require the use of only a
					hex editor, or may require aspects of the toolchain used to construct the
					application: for instance the Adobe Flash development environment. Attacks of
					this nature do not require network access or undue CPU, memory, or other
					hardware-based resources.</Text>
			</Resources_Required>
			<Probing_Techniques>
				<Probing_Technique>
					<Text>Attackers may confine (and succeeed with) probing as simple as deleting a
						cache or data file, or less drastically twiddling its bits and then testing
						the mutation's effect on an executing client.</Text>
				</Probing_Technique>
				<Probing_Technique>
					<Text>At the other extreme, attackers capable of reverse engineering client code
						will have the ability to remove functionality or identify the whereabouts of
						sensitive data through whitebox analysis, such as review of
						reverse-engineered code.</Text>
				</Probing_Technique>
			</Probing_Techniques>
			<Attack_Motivation-Consequences>
				<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>
				<Text>This pattern of attacks possesses no injection vector, in its normal
					instances, as it affects clients fundamentally vulnerable to client-side trust
					issues. One exception to this rule exists: attacks making use of second-order
					injection attacks (SQL, XSS, or similar command injection) may 'deliver' an
					attack, through an intermediate server or data store, to a peer-client, or
					another user's use of the same client. In the case of the second instance
					(another user's use) this vector seems onerous but would be necessary in
					circumstances in which the hosting system protects the application well but
					implicitly trusts (potentially malicious) data received from the server (such as
					may be the case in kiosks well-protected through physical means).</Text>
			</Injection_Vector>
			<Payload/>
			<Activation_Zone>
				<Text>Client-side software, whether it be a monolithic application, client/server,
					or n-tier (web-based).</Text>
			</Activation_Zone>
			<Payload_Activation_Impact/>
			<Related_Weaknesses>
				<Related_Weakness>
					<CWE_ID>525</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>312</CWE_ID>
					<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>314</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>315</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
				<Related_Weakness>
					<CWE_ID>318</CWE_ID>
					<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
				</Related_Weakness>
			</Related_Weaknesses>
			<Related_Attack_Patterns>
				<Related_Attack_Pattern>
					<Relationship_Views>
						<Relationship_View_ID Ordinal="Primary">1000</Relationship_View_ID>
					</Relationship_Views>
					<Relationship_Target_Form>Attack Pattern</Relationship_Target_Form>
					<Relationship_Nature>ChildOf</Relationship_Nature>
					<Relationship_Target_ID>167<!--Lifting Sensitive Data from the Client--></Relationship_Target_ID>
				</Related_Attack_Pattern>
			</Related_Attack_Patterns>
			<Relevant_Security_Requirements>
				<Relevant_Security_Requirement>
					<Text>No sensitive or confidential information must be stored in client
						distributions. This includes content such as passwords or encryption keys.
						In cases where this is necessary, avoid storing any such information in
						plaintext</Text>
				</Relevant_Security_Requirement>
				<Relevant_Security_Requirement>
					<Text>All information arriving from a client must be validated before
						use.</Text>
				</Relevant_Security_Requirement>
			</Relevant_Security_Requirements>
			<Related_Security_Principles>
				<Related_Security_Principle>
					<Text>Reluctance to Trust</Text>
				</Related_Security_Principle>
				<Related_Security_Principle>
					<Text>Never Assuming that Your Secrets Are Safe</Text>
				</Related_Security_Principle>
			</Related_Security_Principles>
			<Related_Guidelines>
				<Related_Guideline>
					<Text>Never Use Unvalidated Input as Part of a Directive to any Internal
						Component</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Treat the Entire Inherited Process Context as Unvalidated Input</Text>
				</Related_Guideline>
				<Related_Guideline>
					<Text>Use Well-Known Cryptography Appropriately and Correctly</Text>
				</Related_Guideline>
			</Related_Guidelines>
			<Purposes>
				<Purpose>Reconnaissance</Purpose>
				<Purpose>Exploitation</Purpose>
			</Purposes>
			<CIA_Impact>
				<Confidentiality_Impact>High</Confidentiality_Impact>
				<Integrity_Impact>Medium</Integrity_Impact>
				<Availability_Impact>Low</Availability_Impact>
			</CIA_Impact>
			<Technical_Context>
				<Architectural_Paradigms>
					<Architectural_Paradigm>All</Architectural_Paradigm>
				</Architectural_Paradigms>
				<Frameworks>
					<Framework>All</Framework>
				</Frameworks>
				<Platforms>
					<Platform>All</Platform>
				</Platforms>
				<Languages>
					<Language>All</Language>
				</Languages>
			</Technical_Context>
			<Content_History>
				<Submissions>
					<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>
				</Submissions>
				<Modifications>
					<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>
				</Modifications>
			</Content_History>
		</Attack_Pattern>
		<Attack_Pattern ID="93" Name="Log Injection-Tampering-Forging"
			Pattern_Completeness="Complete" Pattern_Abstraction="Standard" Status="Draft">
			<Description>
				<Summary>
					<Text>This attack targets the log files of the target host. The attacker
						injects, manipulates or forges malicious log entries in the log file,
						allowing him to mislead a log audit, cover traces of attack, or perform
						other malicious actions. The target host is not properly controlling log
						access. As a result tainted data is resulting in the log files leading to a
						failure in accoutability, non-repudiation and incident forensics
						capability.</Text>
				</Summary>
				<Attack_Execution_Flow>
					<Attack_Phases>
						<Attack_Phase ID="1" Name="Explore">
							<Attack_Steps>
								<Attack_Step ID="1">
									<Custom_Attack_Step>
										<Attack_Step_Title>Determine Application's Log File
											Format</Attack_Step_Title>
										<Attack_Step_Description>
											<Text>The first step is exploratory meaning the attacker
												observes the system. The attacker looks for action
												and data that are likely to be logged. The attacker
												may be familiar with the log format of the
												system.</Text>
										</Attack_Step_Description>
										<Attack_Step_Techniques>
											<Attack_Step_Technique ID="1">
												<Attack_Step_Technique_Description>
												<Text>Determine logging utility being used by
												application (e.g. log4j)</Text>
												</Attack_Step_Technique_Description>
												<Environments>env-All</Environments>
											</Attack_Step_Technique>
											<Attack_Step_Technique ID="2">
												<Attack_Step_Technique_Description>
												<Text>Gain access to application's source code to
												determine log file formats.</Text>
												</Attack_Step_Technique_Description>
										