CAPEC 1

Summary

Attack Execution Flow

1. Survey:

   The attacker surveys the target application, possibly as a valid and authenticated user

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Spidering web sites for all available links	env-Web
   2	Brute force guessing of resource names	env-All
   3	Brute force guessing of user names / credentials	env-All
   4	Brute force guessing of function names / actions	env-All

   Indicators

   ID	type	Indicator Description	Environments
   1	Positive	ACLs or other access control mechanisms are present in the software	env-Web env-ClientServer
   2	Positive	User IDs or other credentials are present in the software	env-Web env-ClientServer
   3	Positive	Operating modes with different privileges are present in the software	env-ClientServer env-Local env-Embedded

2. Identify Functionality:

   At each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actions

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Use the web inventory of all forms and inputs and apply attack data to those inputs.	env-Web
   2	Use a packet sniffer to capture and record network traffic	env-CommProtocol
   3	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.	env-Local env-Embedded

   Outcomes

   ID	type	Outcome Description
   1	Success	The attacker produces a list of functionality or data that can be accessed through the system.

1. Iterate over access capabilities:

   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 Techniques

   ID	Attack Step Technique Description	Environments
   1	Fuzzing of API parameters (URL parameters, OS API parameters, protocol parameters)	env-Web env-Local env-Embedded env-ClientServer

   Indicators

   ID	type	Indicator Description	Environments
   1	Negative	Attempts to create a catalog of access mechanisms and data have failed.	env-All

   Outcomes

   ID	type	Outcome Description
   1	Success	Functionality is accessible to unauthorized users.

Likelihood: Very High

Description

Skill or Knowledge Level: 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.

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.

More generally, noting the target resource accessed upon performing specific actions drives an understanding of the resources accessible from the current context.

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.

All resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logic

In addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL.