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

        <Common_Attack_Pattern_Enumeration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://capec.mitre.org/data/xsd/ap_schema_v1.7.xsd">
                <Attack_Pattern CAPEC_ID="1" Name="Accessing Functionality Not Properly Constrained by ACLs" Pattern_Abstraction="Standard">
		<Description>
			<Summary>In applications, particularly web applications, access to functionality is mitigated by the authorization framework, whose job it is to map ACLs to elements of the application's functionality; particularly URL's for web apps. In the case that the application deployer failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application or can run queries for data that he is otherwise not supposed to.</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="Explore">
					<Attack_Step>
						<Attack_Step_Title>Survey</Attack_Step_Title>
						<Attack_Step_Description>The attacker surveys the target application, possibly as a valid and authenticated user</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Spidering web sites for all available links</Attack_Step_Technique_Description>
							<Environments>env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Brute force guessing of resource names</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Brute force guessing of user names / credentials</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Brute force guessing of function names / actions</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c1s1i1" type="Positive">
							<Indicator_Description>ACLs or other access control mechanisms are present in the software</Indicator_Description>
							<Environments>env-Web env-ClientServer</Environments>
						</Indicator>
						<Indicator ID="c1s1i2" type="Positive">
							<Indicator_Description>User IDs or other credentials are present in the software</Indicator_Description>
							<Environments>env-Web env-ClientServer</Environments>
						</Indicator>
						<Indicator ID="c1s1i3" type="Positive">
							<Indicator_Description>Operating modes with different privileges are present in the software</Indicator_Description>
							<Environments>env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Title>Identify Functionality</Attack_Step_Title>
						<Attack_Step_Description>At each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actions</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Use the web inventory of all forms and inputs and apply attack data to those inputs.</Attack_Step_Technique_Description>
							<Environments>env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Use a packet sniffer to capture and record network traffic</Attack_Step_Technique_Description>
							<Environments>env-CommProtocol</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>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.</Attack_Step_Technique_Description>
							<Environments>env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Outcome ID="c1s2o1" type="Success">The attacker produces a list of functionality or data that can be accessed through the system.</Outcome>
					</Attack_Step>
				</Attack_Phase>
				<Attack_Phase Name="Experiment">
					<Attack_Step>
						<Attack_Step_Title>Iterate over access capabilities</Attack_Step_Title>
						<Attack_Step_Description>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.</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Fuzzing of API parameters (URL parameters, OS API parameters, protocol parameters)</Attack_Step_Technique_Description>
							<Environments>env-Web env-Local env-Embedded env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c1s3i1" type="Negative">
							<Indicator_Description>Attempts to create a catalog of access mechanisms and data have failed.</Indicator_Description>
							<Environments>env-All</Environments>
						</Indicator>
						<Outcome ID="c1s3o1" type="Success">Functionality is accessible to unauthorized users.</Outcome>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>The application must be navigable in a manner that associates elements (subsections) of the application with ACLs.</Attack_Prerequisite>
			<Attack_Prerequisite>The various resources, or individual URLs, must be somehow discoverable by the attacker</Attack_Prerequisite>
			<Attack_Prerequisite>The deployer must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Analysis</Method_of_Attack>
			<Method_of_Attack>Brute Force</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
Implementing the Model-View-Controller (MVC) within Java EE's Servlet paradigm using a "Single front controller" pattern that demands that brokered HTTP requests be authenticated before hand-offs to other Action Servlets. 
If no security-constraint is placed on those Action Servlets, such that positively no one can access them, the front controller can be subverted.</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: In order to discover unrestricted resources, the attacker does not need special tools or skills. He only has to observe the resources or access mechanisms invoked as each action is performed and then try and access those access mechanisms directly.</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>No special resources are required for the exploit of this pattern.</Resources_Required>
		<Probing_Techniques>
			<Probing_Technique>In the case of web applications, use of a spider or other crawling software can allow an attacker to search for accessible pages not beholden to a security constraint.</Probing_Technique>
			<Probing_Technique>More generally, noting the target resource accessed upon performing specific actions drives an understanding of the resources accessible from the current context.</Probing_Technique>
		</Probing_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>In a J2EE setting, deployers can associate a role that is impossible for the authenticator to grant users, such as "NoAccess", with all Servlets to which access is guarded by a limited number of servlets visible to, and accessible by, the user.. 
Having done so, any direct access to those protected Servlets will be prohibited by the web container. 
In a more general setting, the deployer must mark every resource besides the ones supposed to be exposed to the user as accessible by a role impossible for the user to assume. The default security setting must be to deny access and then grant access only to those resources intended by business logic.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>The context of this pattern's applicability is most likely a web-based application, subject to an authorization framework. </Context_Description>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>285</CWE_ID>
				<Weakness_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_Weaknesses>
		<Relevant_Security_Requirements>
			<Relevant_Security_Requirement>All resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logic</Relevant_Security_Requirement>
			<Relevant_Security_Requirement>In addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL.</Relevant_Security_Requirement>
		</Relevant_Security_Requirements>
		<Related_Security_Principles>
			<Related_Security_Principle>Failing Securely</Related_Security_Principle>
			<Related_Security_Principle>Least Privilege</Related_Security_Principle>
			<Related_Security_Principle>Reluctance To Trust</Related_Security_Principle>
			<Related_Security_Principle>Complete Mediation</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Use Authorization Mechanisms Correctly</Related_Guideline>
			<Related_Guideline>Design Configuration Subsystems Correctly and Distribute Safe Default Configurations</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>John Steven</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-10</Submission_Date>
				<Submission_Comment>Initial core pattern content</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Chiradeep B. Chhaya</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-23</Modification_Date>
				<Modification_Comment>Fleshed out pattern with extra content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Attack Execution Flow, Attack Prerequisites, Examples and Solutions</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
			<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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="2" Name="Inducing Account Lockout" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
			An attacker leverages the security functionality of the system aimed at thwarting potential attacks to launch a denial of service attack against a legitimate system user.  Many systems, for instance, implement a password throttling mechanism that locks an account after a certain number of incorrect log in attempts.  An attacker can leverage this throttling mechanism to lock a legitimate user out of their own account.  The weakness that is being leveraged by an attacker is the very security feature that has been put  in place  to counteract attacks.
	</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="Experiment">
					<Attack_Step>
						<Attack_Step_Title>Investigate account lockout behavior of system</Attack_Step_Title>
						<Attack_Step_Description>
              Investigate the security features present in the system that may trigger an account lockout 
            </Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Analyze system documentation to find list of events that could potentially cause account lockout</Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                Obtain user account in system and attempt to lock it out by sending malformed or incorrect data repeatedly
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                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.
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c2s1i1" type="Positive">
							<Indicator_Description>
                System provides error message stating that account being attacked is locked out.
              </Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Indicator ID="c2s1i2" type="Positive">
							<Indicator_Description>
                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.
              </Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Indicator ID="c2s1i3" type="Negative">
							<Indicator_Description>
                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.
              </Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Outcome ID="c2s1o1" type="Success">Attacker determines at least one way to lock out accounts.</Outcome>
						<Outcome ID="c2s1o2" type="Failure">System provides no indication that account lockouts are possible</Outcome>
						<Security_Control ID="c2s1sc1" type="Detective">Repeated failed login attempts in application/system logs.</Security_Control>
						<Security_Control ID="c2s1sc2" type="Preventative">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>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Title>Obtain list of user accounts to lock out</Attack_Step_Title>
						<Attack_Step_Description>
              Generate a list of valid user accounts to lock out
            </Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                Obtain list of authorized users using another attack pattern, such as SQL Injection.
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                Attempt to create accounts if possible; system should indicate if a user ID is already taken.
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                Attempt to brute force user IDs if system reveals whether a given user ID is valid or not upon failed login attempts.
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c2s2i1" type="Positive">
							<Indicator_Description>System indicates which user IDs are valid and which are not to unauthenticated users.</Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Outcome ID="c2s2o1" type="Success">Attacker gathers list of user IDs</Outcome>
						<Outcome ID="c2s2o2" type="Inconclusive">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>
						<Security_Control ID="c2s2sc1" type="Preventative">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>
					</Attack_Step>
				</Attack_Phase>
				<Attack_Phase Name="Exploit">
					<Attack_Step>
						<Attack_Step_Title>Lock Out Accounts</Attack_Step_Title>
						<Attack_Step_Description>
              Perform lockout procedure for all accounts that the attacker wants to lock out.
            </Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>
                For each user ID to be locked out, perform the lockout procedure discovered in the first step.
              </Attack_Step_Technique_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c2s3i1" type="Positive">
							<Indicator_Description>Success outcome in first step</Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Indicator ID="c2s3i2" type="Negative">
							<Indicator_Description>Failure outcome in first step</Indicator_Description>
							<Environments>env-Web env-ClientServer env-Local env-Embedded</Environments>
						</Indicator>
						<Outcome ID="c2s3o1" type="Success">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>
						<Outcome ID="c2s3o2" type="Failure">The large amount of work required by an attacker to lock out a large number of accounts makes this an unattractive attack.</Outcome>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				The system has a lockout mechanism.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
			An attacker must be able to reproduce behavior that would result in an account being locked. 
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Medium</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
			<Method_of_Attack>Flooding</Method_of_Attack>
			<Method_of_Attack>Brute Force</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					A famous example of this type an attack is the eBay attack.  eBay always displays the user id of the highest bidder.  In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time.  An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out.   Thus an attacker could win the auction.
				</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability/>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>Computer with access to the login portion of the target system</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
			Implement intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.   
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
			When implementing security features, consider how they can be misused and made to turn on themselves.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Related_Weaknesses>
			<!-- New CWE needed: "Overly Restrictive Account Lockout Mechanism" -->
			<Related_Weakness>
				<CWE_ID>400</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Source>
			<Submission>
				<Submitter>Eugene Lebanidze</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-26</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-01</Modification_Date>
				<Modification_Comment>Review and revision of content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Description and Solutions</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
			<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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="6" Name="Argument Injection" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
		An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be directly or indirectly applied as arguments, for example as shell commands. This may allow an attacker access to files, network resources, media, and in short anything accessible through the shell.

		The argument injection attack uses the exposed service or method as a launch pad to invoke other programs. If the service does not validate or filter the input data then the client program is granted access to execute commands using the server's privileges. The OS commands can be appended to standard input for shell programs, HTTP Requests, and XML messages. The ability to invoke commands is not necessarily sufficient for the attacker to collect the output of the attack. This may or may not be an issue depending on the attacker goal.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Target software fails to strip all user-supplied input of any content that could cause the shell to perform unexpected actions.</Attack_Prerequisite>
			<Attack_Prerequisite>
				Software must allow for unvalidated or unfiltered input to be executed on operating system shell, and, optionally, the system configuration must allow for output to be sent back to client.
				</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>A recent example instance of argument injection occurred against Java Web Start technology, which eases the client side deployment for Java programs. The JNLP files that are used to describe the properties for the program. The client side Java runtime used the arguments in the property setting to define execution parameters, but if the attacker appends commands to an otherwise legitimate property file, then these commands are sent to the client command shell.
					Source http://www.securityfocus.com/archive/1/393696</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Medium → The attacker has to identify injection vector, identify the operating system-specific commands, and optionally collect the output. 
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Do not program input values directly on command shell, instead treat user input as guilty until proven innocent. Build a function that takes user input and converts it to applications specific types and values, stripping or filtering out all unauthorized commands and characters in the process.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Design: Limit program privileges, so if metacharcters or other methods circumvent program input validation routines and shell access is attained then it is not running under a privileged account. chroot jails create a sandbox for the application to execute in, making it more difficult for an attacker to elevate privilege even in the case that a compromise has occurred.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Implement an audit log that is written to a separate host, in the event of a compromise the audit log may be able to provide evidence and details of the compromise.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Data Modification</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Argument Injection
		"User input is directly pasted into the argument of a shell command. A number of third-party programs allow passthrough to a shell with little or no filtering."
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard input, the attacker inserts additional arguments on the application's standard interface 
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. Malicious payload either pass commands through valid paramters or supply metacharacters that cause unexpected termination that redirects to shell
		</Payload>
		<Activation_Zone>
			Client machine and client network (e..g Intranet)
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to execute server side code with any commands that the program owner has privileges to, this is particularly problematic when the sprogram is run as a system or privileged account.
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>77</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>146</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_Weaknesses>
		<Related_Guidelines>
			<Related_Guideline>Never Use Input as Part of a Directive to any Internal Component</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Low</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Attack Prerequisites and Related Guidelines</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="96" Name="Block Access to Libraries" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
				An application typically makes calls to functions that are a part of libraries external to the application.  These libraries may be part of the operating system or they may be third party libraries.  It is possible that the application does not handle situations properly where access to these libraries has been blocked.  Depending on the error handling within the application, blocked access to libraries may leave the system in an insecure state that could be leveraged by an attacker.  
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="">
					<Attack_Step>
						<Attack_Step_Description>
					Determine what external libraries the application accesses.
					</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>
					Block access to the external libraries accessed by the application.
					</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>
						Monitor the behavior of the system to see if it goes into an insecure/inconsistent state.
					</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>
						If the system does go into an insecure/inconsistent state, leverage that to obtain information about the system functionality or data, elevate access control, etc.  The rest of this attack will depend on the context and the desired goal.
					</Attack_Step_Description>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				An application requires access to external libraries.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
			   An attacker has the priviliges to block application access to external libraries.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Medium</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				A web-based system uses a third party cryptographic random number generation library that derives entropy from machine's hardware.  This library is used in generation of user session ids used by the applicatoin.  If the library is inaccessible, the application instead uses a software based weak pseudo random number generation library.  An attacker of the system blocks access of the application to the third party cryptographic random number generation library (by renaming it).  The application in turn uses the weak pseudo random number generation library to generate session ids that are predictable.  An attacker then leverages this weakness to guess a session id of  another user to perform a horizontal elevation of privilege escalation and gain access to another user's account.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low
		</Attacker_Skill_or_Knowledge_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
			Ensure that application handles situations where access to APIs in external libraries is not available securely. If the application cannot continue its execution safely it should fail in a consistent and secure fashion.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>589</CWE_ID>
				<Weakness_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_Security_Principles>
			<Related_Security_Principle>Failing Securely</Related_Security_Principle>
		</Related_Security_Principles>
		<Purpose>Exploitation</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Low</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>Sean Barnum</Submitter>
				<Submitter_Organization>Cigital, Inc.</Submitter_Organization>
				<Submission_Date>2007-03-25</Submission_Date>
				<Submission_Comment>Identified priority for pattern creation</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Evgeny Lebanidze</Modifier>
				<Modifier_Organization>Cigital, Inc.,</Modifier_Organization>
				<Modification_Date>2007-03-21</Modification_Date>
				<Modification_Comment>Fleshed out content for pattern</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-16</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="11" Name="Cause Web Server Misclassification" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
			An attack of this type exploits a Web server's decision to take action based on filename or file extension. Because different file types are handled by different server processes, misclassification may force the Web server to take unexpected action, or expected actions in an unexpected sequence. This may cause the server to exhaust resources, supply debug or system data to the attacker, or bind an attacker to a remote process.
			This type of vulnerability has been found in many widely used servers including IIS, Lotus Domino, and Orion. The attacker's job in this case is straightforward, standard communication protocols and methods are used and are generally appended with malicious information at the tail end of an otherwise legitimate request. The attack paylod varies, but it could be special characters like a period or simply appending a tag that has a special meanning for operations on the server side like .jsp for a java application server. The essence of this attack is that the attacker deceives the server into executing functionality based on the name of the request, i.e. login.jsp, not the contents.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Web server software must rely on file name or file extension for processing.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Medium</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				J2EE application servers are supposed to execute Java Server Pages (JSP). There have been disclosure issues relating to Orion Application Server, where an attacker that appends either a period (.) or space characters to the end of a legitimate Http request, then the server displays the full source code in the attacker's web browser. 
				
				http://victim.site/login.jsp.
				
				Since remote data and directory access may be accessed directly from the JSP, this is a potentially very serious issue.
				Reference http://www.securityfocus.com/bid/17204/info
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → To modify file name or file extension
			Medium →  To use misclassification to force the Web server to disclose configuration information, source, or binary data
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to execute HTTP request to Web server
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Implementation: Server routines should be determined by content not determined by filename or file extension.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
		“Attack Pattern: Cause Web Server Misclassification
		A very famous set of classification problems occurs when a Web server examines the last few characters of a filename to determine what kind of file it is. There are many ways to take advantage of these kinds of problems-appending certain strings to filenames, adding dots, and so forth."
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard Web application calls, e.g. HTTP Request.
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. Malicious payload may alter or append filename or extension to communicate with processes in unexpected order.
		</Payload>
		<Activation_Zone>
			Client machine and client network 
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to force web server to disclose configuration, source, and data
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<!-- New CWE needed to describe the general weakness targeted by this attack -->
			<Related_Weakness>
				<CWE_ID>69</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>77</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Purpose>Reconnaissance</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="12" Name="Choosing a Message/Channel Identifier on a Public/Multicast Channel" Pattern_Abstraction="Standard">
		<Description>
			<Summary>Attackers aware that more data is being fed into a multicast or public information distribution means can 'select' information bound only for another client, even if the distribution means itself forces users to authenticate in order to connect initally. 
			Doing so allows the attacker to gain access to possibly privileged information, possibly perpetrate other attacks through the distribution means by impersonation.
			If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could change its identifier from a less privileged to more so privileged channel or command.
		</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="">
					<Attack_Step>
						<Attack_Step_Description>Determine the nature of messages being transported as well as the identifiers to be used as part of the attack</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>If required, authenticate to the distribution channel</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>If any particular client's information is available through the transport means simply by selecting a particular identifier, an attacker can simply provide that particular identifier.</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>Attackers with client access connecting to output channels could change their channel identifier and see someone else's (perhaps more privileged) data.</Attack_Step_Description>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>Information and client-sensitive (and client-specific) data must be present through a distribution channel available to all users.
			</Attack_Prerequisite>
			<Attack_Prerequisite>Distribution means must code (through channel, message identifiers, or convention) message destination in a manner visible within the distribution means itself (such as a control channel) or in the messages themselves.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
			A certain B2B interface on a large application codes for messages passed over a MQSeries queue, on a single "Partners" channel. Messages on that channel code for their client destination based on a partner_ID field, held by each message. That field is a simple integer. Attackers having access to that channel, perhaps a particularly nosey partner, can simply choose to store messages of another parnter's ID and read them as they desire. Note that authentication does not prevent a partner from leveraging this attack on other partners. It simply disallows Attackers without partner status from conducting this attack.</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: All the attacker needs to discover is the format of the messages on the channel/distribution means and the particular identifier used within the messages.</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>The Attacker needs the ability to control source code or application configuration responsible for selecting which message/channel id is absorbed from the public distribution means.
		</Resources_Required>
		<Probing_Techniques>
			<Probing_Technique>Assisted protocol analysis: because the protocol under attack is a public channel, or one in which the attacker likely has authorized access to, they need simply to decode the aspect of channel or message interpretation that codes for message identifiers. 
			Probing is as simple as changing this value and watching its effect.
			</Probing_Technique>
		</Probing_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Associate some ACL (in the form of a token) with an authenticated user which they provide middleware. The middleware uses this token as part of its channel/message selection for that client, or part of a discerning authorization decision for privileged channels/messages. 
			The purpose is to architect the system in a way that associates proper authentication/authorization with each channel/message.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>Rearchitect system input/output channels as appropriate to distribute self-protecting data. That is, encrypt (or otherwise protect) channels/messages so that only authorized readers can see them.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>This pattern applies in circumstances in which publically accessible distribution means code (through channel, message identifiers, or convention) for client-specific subscription information about messages being distributed. Commonly, this will happen over message-oriented middleware buses, multicast channels, or feeds.
		</Context_Description>
		<Related_Weaknesses>
			<!-- New CWE needed titled "Access Control Bypass Through User-Controlled Key" as parent to "Access Control Bypass Through User-Controlled SQL Primary Key" -->
			<Related_Weakness>
				<CWE_ID>201</CWE_ID>
				<Weakness_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>
				<Related_Attack_Pattern_ID>21</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Similar</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Complete Mediation</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Use Authentication Mechanisms, Where Appropriate, Correctly</Related_Guideline>
			<Related_Guideline>Use Authorization Mechanisms Correctly: this refers to Ambiguity of authentication. Many authorization systems use ambiguous symbols (i.e., principal names) to identify principals allowing circumvention of authorization by using a different, though equivalent, principal name. For example, there are many implementations for restricting remote host access to local services that may allow many proper—but apparently different—names for unique hosts (e.g., fully qualified domain names, shortened names, CNAMEs, IPv4 addresses, IPv6 addresses). </Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>Low</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>Client-Server</Architectural_Paradigm>
			<Architectural_Paradigm>n-Tier</Architectural_Paradigm>
			<Architectural_Paradigm>SOA</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<Source>
			<Submission>
				<Submitter>John Steven</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-10</Submission_Date>
				<Submission_Comment>Initial core pattern content</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Chiradeep B. Chhaya</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-23</Modification_Date>
				<Modification_Comment>Fleshed out pattern with extra content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Description and Related Attack Patterns</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="13" Name="Subverting Environment Variable Values" Pattern_Abstraction="Standard">
		<Description>
			<Summary>The attacker directly or indirectly modifies environment variables used by or controlling the target software.  The attacker’s goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker.</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="">
					<Attack_Step>
						<Attack_Step_Description>1- The attacker probes the application for information. Which version of the application is running? Are there known environment variables? etc.</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>2- The attacker gains control of an environment variable and ties to find out what process(es) the environment variable controls.</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>3- The attacker modifies the environment variable to abuse the normal flow of processes or to gain access to privileged ressources.</Attack_Step_Description>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>An environment variable is accessible to the user.</Attack_Prerequisite>
			<Attack_Prerequisite>An environment variable used by the application can be tainted with user supplied data.</Attack_Prerequisite>
			<Attack_Prerequisite>Input data used in an environment variable is not validated properly.</Attack_Prerequisite>
			<Attack_Prerequisite>The variables encapsulation is not done properly. For instance setting a variable as public in a class makes it visible and an attacker may attemp to manipulate that variable.</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>Modification of Resources</Method_of_Attack>
			<Method_of_Attack>Protocol Manipulation</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>Environment variables 

Changing the LD_LIBRARY_PATH environment variable in TELNET will cause TELNET to use an alternate (possibly Trojan) version of a function library. The Trojan library must be accessible using the target file system and should include Trojan code that will allow the user to log in with a bad password. This requires that the attacker upload the Trojan library to a specific location on the target.

As an alternative to uploading a Trojan file, some file systems support file paths that include remote addresses, such as \\172.16.2.100\shared_files\trojan_dll.dll.
</Example-Instance_Description>
				<Example-Instance_Related_Vulnerability>Path Manipulation (CVE-1999-0073)</Example-Instance_Related_Vulnerability>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>Low: In a web based scenario, the client controls the data that it submitted to the server. So anybody can try to send malicious data and try to bypass the authentication mechanism. 

Medium/High: Some more advanced attacks may require knowledge about protocols and probing technique which help controling a variable. The malicious user may try to understand the authentication mechanism in order to defeat it.</Attacker_Skill_or_Knowledge_Required>
		<Probing_Techniques>
			<Probing_Technique>An attacker can intentionally modify the client side parameter and monitor how the server behaves in response to that modification. For instance an attacker will look at the cookie data, the URL parameters, the hidden variables in forms, variables used in system calls, etc. </Probing_Technique>
			<Probing_Technique>If the client uses a program in binary format to connect to the server, disassembler can be used to identify parameter within the binary code, and then the attacker would try to simulate the client application and change some of the parameters sent to the server. For instance the attacker may find that a secret key or a path is hard coded in the binary client application.</Probing_Technique>
			<Probing_Technique>Environment variables are frequently stored in cleartext configuration files. If the attacker can modify those configuration files, he can control the environment variables. Even a read access can potentially be dangerous since this may give sensitive information to perform this type of attack. Indeed knowing which environment variables the application uses is a prerequisite to this type of attack.</Probing_Technique>
		</Probing_Techniques>
		<Obfuscation_Techniques>
			<Obfuscation_Technique>The attacker may try to obfuscate its attempts to subvert the target process (such as authentication) by using valid values for the variable she controls. By using valid values the user tries to understand the authentication mechanism. This would be in preparation to a more serious attack.</Obfuscation_Technique>
		</Obfuscation_Techniques>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>Protect environment variables against unauthorized read and write access.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Protect the configuration files which contain environment variables against illegitimate read and write access.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Assume all input is malicious.  Create a white list that defines all valid input to the software system based on the requirements specifications.  Input that does not match against the white list should not be permitted to enter into the system.</Solution_or_Mitigation>
			<Solution_or_Mitigation>Apply the least privilege principles. If a process has no legitimate reason to read an environment variable do not give that privilege.</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Run Arbitrary Code</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Privilege Escalation</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Denial of Service</Attack_Motivation-Consequence>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description/>
		<Injection_Vector>The client controlled parameter</Injection_Vector>
		<Payload>The new value of the client controlled parameter.</Payload>
		<Activation_Zone>The activation zone is the server side function where the client controlled parameter is consumed.</Activation_Zone>
		<Payload_Activation_Impact>Consuming an attacker contolled parameter can defeat the normal process of the application.</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>353</CWE_ID>
				<Weakness_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>SQL-Ledger 2.4.4 through 2.6.17 authenticates users by verifying that the value of the sql-ledger-[username] cookie matches the value of the sessionid parameter, which allows remote attackers to gain access as any logged-in user by setting the cookie and the parameter to the same value.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-2734</Vulnerability_ID>
				<Vulnerability_Description>enter.asp in Mini-Nuke 2.3 and earlier makes it easier for remote attackers to conduct password guessing attacks by setting the guvenlik parameter to the same value as the hidden gguvenlik parameter, which bypasses a verification step because the guvenlik parameter is assumed to be immutable by the attacker.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-2527</Vulnerability_ID>
				<Vulnerability_Description>Admin/admin.php in phpBazar 2.1.0 and earlier allows remote attackers to bypass the authentication process and gain unauthorized access to the administrative section by setting the action parameter to edit_member and the value parameter to 1.</Vulnerability_Description>
			</Related_Vulnerability>
			<Related_Vulnerability>
				<Vulnerability_ID>CVE-2006-1505</Vulnerability_ID>
				<Vulnerability_Description>base_maintenance.php in Basic Analysis and Security Engine (BASE) before 1.2.4 (melissa), when running in standalone mode, allows remote attackers to bypass authentication, possibly by setting the standalone parameter to "yes".</Vulnerability_Description>
			</Related_Vulnerability>
		</Related_Vulnerabilities>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>77</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>76</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Abstract</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>14</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Occasionally Precedes</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>10</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Similar</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Related_Security_Principles>
			<Related_Security_Principle>Reluctance to trust</Related_Security_Principle>
		</Related_Security_Principles>
		<Related_Guidelines>
			<Related_Guideline>Always perform wise data validation. Do not accept tainted data without validation. Do not simply base authentication on the client controlled parameter.</Related_Guideline>
			<Related_Guideline>Avoid relying on client side validation only.</Related_Guideline>
		</Related_Guidelines>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Reference>
			<Reference>CWE – Input Validation</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-03-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Eric Dalci</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-13</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-05</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, Description and Related Attack Patterns</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="15" Name="Command Delimiters" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
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.</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="Explore">
					<Attack_Step>
						<Attack_Step_Title>Assess Target Runtime Environment</Attack_Step_Title>
						<Attack_Step_Description>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.</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Port mapping using network connection-based software (e.g., nmap, nessus, etc.)</Attack_Step_Technique_Description>
							<Environments>env-ClientServer env-Embedded env-CommProtocol env-Peer2Peer env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Port mapping by exploring the operating system (netstat, sockstat, etc.)</Attack_Step_Technique_Description>
							<Environments>env-Local</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>TCP/IP Fingerprinting</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Induce errors to find informative error messages</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c15s1i1" type="Positive">
							<Indicator_Description>The target software accepts connections via the network.</Indicator_Description>
							<Environments>env-Web env-CommProtocol env-Peer2Peer env-Embedded</Environments>
						</Indicator>
						<Outcome ID="c15s1o1" type="Success">Operating environment (operating system, language, and/or middleware) is correctly identified.</Outcome>
						<Outcome ID="c15s1o2" type="Inconclusive">Multiple candidate operating environments are suggested.</Outcome>
						<Security_Control ID="c15s1s1" type="Preventative">Provide misleading information on TCIP/IP fingerprints (some operating systems can be configured to send signatures that match other operating systems).</Security_Control>
						<Security_Control ID="c15s1s2" type="Preventative">Provide misleading information at the server level (e.g., Apache, IIS, WebLogic, etc.) to announce a different server software.</Security_Control>
						<Security_Control ID="c15s1s3" type="Detective">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>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Title>Survey the Application</Attack_Step_Title>
						<Attack_Step_Description>The attacker surveys the target application, possibly as a valid and authenticated user</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Spidering web sites for all available links</Attack_Step_Technique_Description>
							<Environments>env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Inventory all application inputs</Attack_Step_Technique_Description>
							<Environments>env-All</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c15s2i1" type="Positive">
							<Indicator_Description>Attacker develops a list of valid inputs</Indicator_Description>
							<Environments>env-Web env-ClientServer</Environments>
						</Indicator>
						<Outcome ID="c15s2o1" type="Success">The attacker develops a list of likely command delimiters.</Outcome>
						<Security_Control ID="c151s2s1" type="Detective">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>
						<Security_Control ID="c151s2s2" type="Detective">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>
						<Security_Control ID="c151s2s3" type="Preventative">Actively monitor the application and either deny or redirect requests from origins that appear to be automated.</Security_Control>
						<Security_Control ID="c151s2s4" type="Detective">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>
					</Attack_Step>
				</Attack_Phase>
				<Attack_Phase Name="Experiment">
					<Attack_Step>
						<Attack_Step_Title>Attempt delimiters in inputs</Attack_Step_Title>
						<Attack_Step_Description>The attacker systematically attempts variations of delimiters on known inputs, observing the application's response each time.</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Inject command delimiters using network packet injection tools (netcat, nemesis, etc.)</Attack_Step_Technique_Description>
							<Environments>env-CommProtocol env-Web env-Peer2Peer env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Inject command delimiters using web test frameworks (proxies, TamperData, custom programs, etc.)</Attack_Step_Technique_Description>
							<Environments>env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Enter command delimiters directly in input fields.</Attack_Step_Technique_Description>
							<Environments>env-Embedded env-Local env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c15s3i1" type="Positive">
							<Indicator_Description>Attack step 2  is successful.</Indicator_Description>
							<Environments>env-All</Environments>
						</Indicator>
						<Outcome ID="c15s3o1" type="Success">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>
					</Attack_Step>
				</Attack_Phase>
				<Attack_Phase Name="Exploit">
					<Attack_Step>
						<Attack_Step_Title>Use malicious command delimiters</Attack_Step_Title>
						<Attack_Step_Description>The attacker uses combinations of payload and carefully placed command delimiters to attack the software.</Attack_Step_Description>
						<Outcome ID="c15s4o1" type="Success">The software performs as expected by the attacker.</Outcome>
						<Security_Control ID="c15s4s1" type="Detective"/>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
Software's input validation or filtering must not detect and block presence of additional malicious command.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
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.
				
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. 
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
Medium → The attacker has to identify injection vector, identify the specific commands, and optionally collect the output, i.e. from an interactive session. 
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
Design: Perform whitelist validation against a positive specification for command length, type, and parameters. 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
Design: Limit program privileges, so if commands circumvent program input validation or filter routines then commands do not running under a privileged account
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
Implementation: Perform input validation for all remote content.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
Implementation: Use type conversions such as JDBC prepared statements.
			</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>
		<Context_Description>
		“Attack Pattern: Command Delimiters
		"Using the semicolon or other off-nominal characters, multiple commands can be strung together. Unsuspecting target programs will execute all the commands."		
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
Malicious input delivered through appending delimiters to standard input 
		</Injection_Vector>
		<Payload>
Command(s) appended to valid parameters to enable attacker to execute commands on host
		</Payload>
		<Activation_Zone>
Client machine and client network
		</Activation_Zone>
		<Payload_Activation_Impact>
Enables attacker to execute server side code with any commands that the program owner has privileges to.
		</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_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>6</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>High</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="97" Name="Cryptanalysis" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
			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:   
			
			1.  Total Break - Finding the secret key
			2.  Gobal Deduction - Finding a functionally equivalent algorithm for encryption and decryption that does not require knowledge of the secret key.
		    3.  Information Deduction - Gaining some information about plaintexts or ciphertexts that was not previously known
		    4.  Distinguishing Algorithm - The attacker has the ability to distinguish the output of the encryption (ciphertext) from a random permutation of bits
		    
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.
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="">
					<Attack_Step>
						<Attack_Step_Description>
						An attacker discovers a weakness in the cryptographic algorithm or a weakness in how it was applied to a particular chunk of plaintext.
					</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>
					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.
					</Attack_Step_Description>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				The target software utilizes some sort fo cryptographic algorithm.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
				An underlying weaknesses exists either in the cryptographic algorithm used or in the way that it was applied to a particular chunk of plaintext.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
				The encryption algorithm is known to the attacker.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
				An attacker has access to the ciphertext.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Very Low</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Analysis</Method_of_Attack>
			<Method_of_Attack>Brute Force</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
				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.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>High - Cryptanalysis generally requires a very significant level of understanding of mathematics and computation.
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			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.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Use proven cryptographic algorithms with recommended key sizes.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				 Ensure that the algorithms are used properly.  That means:
				 
				 1.  Not rolling out your own crypto;  Use proven algorithms and implementations.
				 2.  Choosing initialization vectors with sufficiently random numbers
				 3.  Generating key material using good sources of randomness and avoiding known weak keys
				 4.  Using proven protocols and their implementations.
				 5.  Picking the most appropriate cryptographic algorithm for your usage context and data
				 
			</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>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>327</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>20</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Related_Attack_Pattern_Relationship_Type>Occasionally Follows</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Purpose>Reconnaissance</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>Wikipedia (Cryptanalysis):  www.wikipedia.org</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>Sean Barnum</Submitter>
				<Submitter_Organization>Cigital, Inc.</Submitter_Organization>
				<Submission_Date>2007-03-25</Submission_Date>
				<Submission_Comment>Identified priority for pattern creation</Submission_Comment>
			</Submission>
			<Modification>
				<Modifier>Evgeny Lebanidze</Modifier>
				<Modifier_Organization>Cigital, Inc.,</Modifier_Organization>
				<Modification_Date>2007-03-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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="17" Name="Accessing, Modifying or Executing Executable Files" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
		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.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				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.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</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>
					Consider a directory on a web server with the following permissions

					drwxrwxrwx     5 admin  public     170 Nov 17 01:08 webroot

					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.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → to identify and execute against an overprivileged system interface
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			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.
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Enforce principle of least privilege
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				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.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.
			</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>
		<Context_Description>
		“Attack Pattern: Direct Access to Executable Files
		A privileged program is directly accessible. The program performs operations on behalf of the attacker that allow privilege escalation or shell access. For Web servers, this is often a fatal issue. If a server runs external executables provided by a user (or even simply named by a user), the user can cause the system to behave in  unanticipated ways.  This may be accomplished by passing in command-line options or by spinning an interactive session. A problem like this is almost always as bad as giving complete shell access to an attacker.

		The most common targets for this kind of attack are Web servers. The attack is so easy that attackers have been known to use Internet search engines to find potential targets. The Altavista search engine is a great resource for attackers looking for such targets. Google works too."		
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Payload delivered through standard communication protocols.
		</Injection_Vector>
		<Payload>
			Command(s) executed directly on host
		</Payload>
		<Activation_Zone>
			Client machine and client network
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to execute server side code with any commands that the program owner has privileges to.
		</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_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>1</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>High</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in Name, 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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="18" Name="Embedding Scripts in Nonscript Elements" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
		This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (&lt;img&gt;), comments in XML documents (&lt; !-CDATA-&gt;), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an attacker to tunnel through the application's elements and launch a XSS attack through other elements.

		As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				Target client software must be a client that allows script execution based on scripts generated by remote hosts.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Very High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					In this example, the attacker adds script to HTML tags other than &lt;script&gt; tags, when the victim's standard content is appended with a malicious script. For example a link to http://myfavoritewebsite/getMyHomePage/content?malciousscript.js
					The victim clicks on the link, which directs them to their home page (so that the victim does not notice anything is amiss) and simultaneously executes a script on their machine.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → To achieve a redirection and use of less trusted source, an attacker can simply edit content such as XML payload  or HTML files that are sent to client machine.
			High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to include malicious script in document, e.g. HTML file, or XML document. Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Use browser technologies that do not allow client side scripting. 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform input validation for all remote content.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform output validation for all remote content.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Disable scripting languages such as Javascript in browser
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Session tokens for specific host
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Service provider should not use the XMLHttpRequest method to create a local proxy for content from other sites, because the client will not be able to discern what content comes from which host.
			</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>
		<Context_Description>
		“Attack Pattern: Embedding Script in Nonscript Elements
		Script does not need to be inserted between &lt;script&gt; tags. Instead, script can appear as part of another HTML tag, such as the image tag. The injection vector is 
	
		&lt;img src = javascript:alert(document.domain)&gt;
		[Hoglund and McGraw 04]</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard document formats, e.g. XML document or HTML file to the client.
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. In the case of HTML files they may not be visible to the end user via a browser.
		</Payload>
		<Activation_Zone>
			Client software and its component libraries
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to execute scripts to launch attacks on remote client machine and environment
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<!-- Need new CWE catgory for Script Injection with CWEs describing failure to filter script out of non-script elements. Basic XSS CWE also needs modified. -->
			<Related_Weakness>
				<CWE_ID>80</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>83</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>84</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>82</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>348</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>20</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>116</CWE_ID>
				<Weakness_Relationship_Type>Targeted</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>86</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>350</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>Medium</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in 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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="19" Name="Embedding Scripts within Scripts" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
		An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts. The attacker leverages this capability to execute scripts to execute his/her own script by embedding it within other scripts that the target software is likely to execute. The attacker must have the ability to inject script into script that is likely to be executed. If this is done, then the attacker can potentially launch a variety of probes and attacks against the web server's local environment, in many cases the so-called DMZ, back end resources the web server can communicate with, and other hosts. 
		
		With the proliferation of intermediaries, such as Web App Firewalls, network devices, and even printers having JVMs and Web servers, there are many locales where an attacker can inject malicious scripts. Since this attack pattern defines scripts within scripts, there are likely privileges to execute said attack on the host.

		Of course, these attacks are not solely limited to the server side, client side scripts like Ajax and client side Javascript can contain malicious scripts as well. In general all that is required is for there to be sufficient privileges to execute a script, but not protected against writing.
		</Summary>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				Target software must be able to execute scripts, and also allow attacker to write/upload script
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>High</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>High</Likelihood>
		</Typical_Likelihood_of_Exploit>
		<Methods_of_Attack>
			<Method_of_Attack>Injection</Method_of_Attack>
			<Method_of_Attack>API Abuse</Method_of_Attack>
		</Methods_of_Attack>
		<Examples-Instances>
			<Example-Instance>
				<Example-Instance_Description>
					Ajax applications enable rich functionality for browser based web applications. Applications like Google Maps deliver unprecedented ability to zoom in and out, scroll graphics, and change grapic presentation through Ajax. The security issues that an attacker may exploit in this instance are the relative lack of security features in Javascript and the various browser's implementation of Javascript, these security gaps are what XSS and a host of other client side vulnerabilities are based on. While Ajax may not open up new security holes, per se, due to the conversational aspects between client and server of Ajax communication, attacks can be optimized. A single zoom in or zoom out on a graphic in an Ajax application may round trip to the server dozens of times. One of the first steps many attackers take is frequently footprinting an environment, this can include scanning local addresses like 192.*.*.* IP addresses, checking local directories, files, and settings for known vulnerabilities, and so on. 
					
					&lt;IMG SRC=javascript:alert('XSS')&gt;
					
					The XSS script that is embeded in a given IMG tag can be manipulated to probe a different address on every click of the mouse or other motions that the Ajax application is aware of.
					
					In addition the enumerations allow for the attacker to nest sequential logic in the attacks. While Ajax applications do not open up brand new attack vectors, the existing attack vectors are more than adequate to execute attacks, and now these attacks can be optimized to sequentially execute and enumerate host environments.</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low → To load malicious script into open, e.g. world writable directory
			Medium → Executing remote scripts on host and collecting output
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			Ability to deploy a custom script on host
		</Resources_Required>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				Design: Use browser technologies that do not allow client side scripting. 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Design: Utilize strict type, character, and encoding enforcement 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from. 
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform input validation for all remote content.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Perform output validation for all remote content.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Disable scripting languages such as Javascript in browser
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Session tokens for specific host
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
			Implementation: Privileges are constrained, if a script is loaded, ensure system runs in chroot jail or other limited authority mode
			</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-Consequences>
		<Context_Description>
		“Attack Pattern: Embedding Scripts within Scripts
		The technology that runs the Internet is diverse and complex. There are hundreds of development languages, compilers, and interpreters that can build and execute code. Every developer has a sense for only part of the overall technology. Investments in time and money are made into each particular technology. As these systems evolve, the need to maintain backward compatibility becomes paramount. In management speak, this is the need to capitalize on an existing software investment. This is one reason that some newer scripting languages have backward support for older scripting languages.

		As a result of this rapid and barely controlled evolution, much of the technology found in the wild can embed or otherwise access other languages and technologies in some form. This adds multiple layers of complexity and makes keeping track of all the disparate (yet available) functionality difficult at best. Filtering rules and security assumptions get swamped by the flow of new stuff. Looking for unanticipated functionality forgotten in the nooks and crannies of a system is an excellent technique."
		[Hoglund and McGraw 04]
		</Context_Description>
		<Injection_Vector>
			Malicious input delivered through standard script page, e.g. ASP web page
		</Injection_Vector>
		<Payload>
			Varies with instantiation of attack pattern. MAy contain network probe or attacks that run against or on host using host account permissions
		</Payload>
		<Activation_Zone>
			Web server scripting host
		</Activation_Zone>
		<Payload_Activation_Impact>
			Enables attacker to execute scripts on remote host
		</Payload_Activation_Impact>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>79</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>279</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
			<Related_Weakness>
				<CWE_ID>284</CWE_ID>
				<Weakness_Relationship_Type>Secondary</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>18</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>Similar</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Purpose>Penetration</Purpose>
		<CIA_Impact>
			<Confidentiality_Impact>Medium</Confidentiality_Impact>
			<Integrity_Impact>High</Integrity_Impact>
			<Availability_Impact>Low</Availability_Impact>
		</CIA_Impact>
		<Technical_Context>
			<Architectural_Paradigm>All</Architectural_Paradigm>
			<Framework>All</Framework>
			<Platform>All</Platform>
			<Language>All</Language>
		</Technical_Context>
		<References>
			<Reference>
			G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
			</Reference>
		</References>
		<Source>
			<Submission>
				<Submitter>G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-01-01</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Gunnar Peterson</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-02-28</Modification_Date>
				<Modification_Comment>Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-09</Modification_Date>
				<Modification_Comment>Review and revise</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in ADescription and Related Attack Patterns</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-04-13</Modification_Date>
				<Modification_Comment>Modified pattern content according to review and feedback</Modification_Comment>
			</Modification>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="20" Name="Encryption Brute Forcing" Pattern_Abstraction="Standard">
		<Description>
			<Summary>
				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.
			</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="">
					<Attack_Step>
						<Attack_Step_Description>
						Determine the ciphertext and the encryption algorithm.
					</Attack_Step_Description>
					</Attack_Step>
					<Attack_Step>
						<Attack_Step_Description>
					Perform an exhaustive brute force search of the keyspace, producing candidate plaintexts and observing if they make sense.
					</Attack_Step_Description>
					</Attack_Step>
				</Attack_Phase>
			</Attack_Execution_Flow>
		</Description>
		<Attack_Prerequisites>
			<Attack_Prerequisite>
				Ciphertext is known.
			</Attack_Prerequisite>
			<Attack_Prerequisite>
				Encryption algorithm and key size are known.
			</Attack_Prerequisite>
		</Attack_Prerequisites>
		<Typical_Severity>Low</Typical_Severity>
		<Typical_Likelihood_of_Exploit>
			<Likelihood>Low</Likelihood>
		</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>
						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.
				</Example-Instance_Description>
			</Example-Instance>
		</Examples-Instances>
		<Attacker_Skill_or_Knowledge_Required>
			Low:  Brute forcing encryption does not require much skill. 
		</Attacker_Skill_or_Knowledge_Required>
		<Resources_Required>
			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).
		
			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.
				Obviously as N gets large the brute force approach becomes infeasible.
		</Resources_Required>
		<Indicators-Warnings_of_Attack>
			<Indicator-Warning_of_Attack>
				None.  This attack happens offline.
			</Indicator-Warning_of_Attack>
		</Indicators-Warnings_of_Attack>
		<Solutions_and_Mitigations>
			<Solution_or_Mitigation>
				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.
			</Solution_or_Mitigation>
			<Solution_or_Mitigation>
				 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.
			</Solution_or_Mitigation>
		</Solutions_and_Mitigations>
		<Attack_Motivation-Consequences>
			<Attack_Motivation-Consequence>Information Leakage</Attack_Motivation-Consequence>
		</Attack_Motivation-Consequences>
		<Context_Description>
			Typically cryptography, if done right, will rarely be the weakest link in the system.  Problems begin when people either decide to play cryptographers themselves and roll out custom crypto, use key sizes that are too small, develop their own cryptographic protocols (or misuse existing cryptographic protocols).  There are some other things that can be done wrong, such as not using good sources of randomness when generating encryption keys and initialization vector values.
		</Context_Description>
		<Related_Weaknesses>
			<Related_Weakness>
				<CWE_ID>326</CWE_ID>
				<Weakness_Relationship_Type>Targeted</Weakness_Relationship_Type>
			</Related_Weakness>
		</Related_Weaknesses>
		<Related_Attack_Patterns>
			<Related_Attack_Pattern>
				<Related_Attack_Pattern_ID>49</Related_Attack_Pattern_ID>
				<Related_Attack_Pattern_Relationship_Type>More Detailed</Related_Attack_Pattern_Relationship_Type>
				<Relationship_Description/>
			</Related_Attack_Pattern>
		</Related_Attack_Patterns>
		<Source>
			<Submission>
				<Submitter>Eugene Lebanidze</Submitter>
				<Submitter_Organization>Cigital, Inc</Submitter_Organization>
				<Submission_Date>2007-02-26</Submission_Date>
			</Submission>
			<Modification>
				<Modifier>Sean Barnum</Modifier>
				<Modifier_Organization>Cigital, Inc</Modifier_Organization>
				<Modification_Date>2007-03-01</Modification_Date>
				<Modification_Comment>Review and revision of content</Modification_Comment>
			</Modification>
			<Modification>
				<Modifier>Richard Struse</Modifier>
				<Modifier_Organization>VOXEM, Inc</Modifier_Organization>
				<Modification_Date>2007-03-26</Modification_Date>
				<Modification_Comment>Review and feedback leading to changes in 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>
		</Source>
	</Attack_Pattern>
                <Attack_Pattern CAPEC_ID="21" Name="Exploitation of Session Variables, Resource IDs and other Trusted Credentials" Pattern_Abstraction="Standard">
		<Description>
			<Summary>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.

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.

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.

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.</Summary>
			<Attack_Execution_Flow>
				<Attack_Phase Name="Explore">
					<Attack_Step>
						<Attack_Step_Title>Survey the application for Indicators of Susceptibility</Attack_Step_Title>
						<Attack_Step_Description>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.</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Spider all available pages</Attack_Step_Technique_Description>
							<Environments>env-Web</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>Attack known bad interfaces</Attack_Step_Technique_Description>
							<Environments>env-Web env-CommProtocol env-ClientServer env-Local</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c21s1i1" type="Positive">
							<Indicator_Description>Session IDs are used</Indicator_Description>
							<Environments>env-Web env-Peer2Peer env-ClientServer env-CommProtocol</Environments>
						</Indicator>
						<Indicator ID="c21s1i2" type="Positive">
							<Indicator_Description>Open access points exist that use no user IDs or passwords, but determine authorization based on message content</Indicator_Description>
							<Environments>env-Web env-Peer2Peer env-CommProtocol env-ClientServer env-Local</Environments>
						</Indicator>
						<Outcome ID="c21s1o1" type="Success">Session IDs are identifiable</Outcome>
						<Outcome ID="c21s1o2" type="Success">Open channels are available</Outcome>
						<Security_Control ID="c211s2s1" type="Detective">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>
						<Security_Control ID="c211s2s2" type="Detective">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>
						<Security_Control ID="c211s2s3" type="Preventative">Actively monitor the application and either deny or redirect requests from origins that appear to be automated.</Security_Control>
						<Security_Control ID="c211s2s4" type="Detective">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>
					</Attack_Step>
				</Attack_Phase>
				<Attack_Phase Name="Experiment">
					<Attack_Step>
						<Attack_Step_Title>Fetch samples</Attack_Step_Title>
						<Attack_Step_Description>An attacker fetches many samples of a session ID. This may be through legitimate access (logging in, legitimate connections, etc) or just systematic probing.</Attack_Step_Description>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>An attacker makes many anonymous connections and records the session IDs assigned.</Attack_Step_Technique_Description>
							<Environments>env-Web env-Peer2Peer env-CommProtocol env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>An attacker makes authorized connections and records the session tokens or credentials issued.</Attack_Step_Technique_Description>
							<Environments>env-Web env-Peer2Peer env-CommProtocol env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Attack_Step_Technique>
							<Attack_Step_Technique_Description>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.</Attack_Step_Technique_Description>
							<Environments>env-Peer2Peer env-CommProtocol env-ClientServer</Environments>
						</Attack_Step_Technique>
						<Indicator ID="c21s3i1" type="Positive">
							<Indicator_Description>Trust in the system is based on IP address, MAC address, network locality, or other general network characteristic.</Indicator_Description>
							<Environments>env-CommProtocol env-ClientServer env-Peer2Peer</Environments>
						</Indicator>
						<Indicator ID="c21s