CAPEC - Common Attack Pattern Enumeration and Classification (A Community of Knowledge Resource for Building Secure Software)
Home > CAPEC List > CAPEC Dictionary Release 1.4  

CAPEC Meta Abstraction Attack Pattern Slice Release 1.4
CAPEC Meta Abstraction Attack Pattern Slice Release 1.4

This view (slice) covers meta abstraction attack patterns.

Exploiting Trust in Client (aka Make the Client Invisible)
Attack Pattern ID
Pattern Abstraction: Meta

22

Typical Severity

High

Description

Summary

An attack of this type exploits a programs' vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client.

An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client.

There are numerous variations of this type of attack.

Attack Prerequisites

Server software must rely on client side formatted and validated values, and not re-inforce these checks on the server side.

Typical Likelihood of Exploit

High

Methods of Attack
  • Spoofing
  • Protocol Manipulation
Examples-Instances

Description

Web applications may use Javascript to perform client side validation, request encoding/formatting, and other security functions, which provides some usability benefits and eliminates some client-server roundtripping. However, the web server cannot assume that the requests it receives have been subject to those validations, because an attacker can use an alternate method for crafting the HTTP Request and submit data that contains poisoned values designed to spoof a user and/or get the web server to disclose information.

Description

Web 2.0 style applications may be particularly vulnerable because they in large part rely on existing infrastructure which provides scalability without the ability to govern the clients. Attackers identify vulnerabilities that either assume the client side is responsible for some security services (without the requisite ability to ensure enforcement of these checks) and/or the lack of a hardened, default deny server configuration that allows for an attacker probing for weaknesses in unexpected ways. Client side validation, request formatting and other services may be performed, but these are strictly usability enhancements not security enhancements.

Description

Many web applications use client side scripting like Javascript to enforce authentication, authorization, session state and other variables, but at the end of day they all make requests to the server. These client side checks may provide usability and performance gains, but they lack integrity in terms of the http request. It is possible for an attacker to post variables directly to the server without using any of the client script security checks and customize the patterns to impersonate other users or probe for more information.

Description

Many message oriented middleware systems like MQ Series are rely on information that is passed along with the message request for making authorization decisions, for example what group or role the request should be passed. However, if the message server does not or cannot authenticate the authorization information in the request then the server's policy decisions about authorization are trivial to subvert because the client process can simply elevate privilege by passing in elevated group or role information which the messgae server accepts and acts on.

Attacker Skill or Knowledge Required

Medium: The attacker must have fairly detailed knowledge of the syntax and semantics of client/server communications protocols and grammars

Resources Required

Ability to communicate synchronously or asynchronously with server

Solutions and Mitigations

Design: Ensure that client process and/or message is authenticated so that anonymous communications and/or messages are not accepted by the system.

Design: Do not rely on client validation or encoding for security purposes.

Design: Utilize digital signatures to increase authentication assurance.

Design: Utilize two factor authentication to increase authentication assurance.

Implementation: Perform input validation for all remote content.

Attack Motivation-Consequences
  • Run Arbitrary Code
  • Privilege Escalation
  • Information Leakage
Context Description

"Attack Pattern: Make the Client Invisible

"Remove the client from the communications loop by talking directly with the server. Explore to determine what the server will and will not accept as input. Masquerade as the client.

[Hoglund and McGraw 04]

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
290Authentication Bypass by SpoofingTargeted
287Improper AuthenticationTargeted
20Improper Input ValidationSecondary
200Information Leak (Information Disclosure)Secondary
693Protection Mechanism FailureSecondary
Purpose

Penetration

CIA Impact
Confidentiality ImpactIntegrity ImpactAvailability Impact
HighHighLow
Technical Context
Architectural ParadigmFrameworkPlatformLanguage
Client-ServerAllAllAll
References

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.

Source
Submission(s)
SubmitterOrganizationDateComment
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.Cigital, Inc2007-01-01
Modification(s)
ModifierOrganizationDateComment
Gunnar PetersonCigital, Inc2007-02-28Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"
Sean BarnumCigital, Inc2007-03-09Review and revise
Software Integrity Attacks
Attack Pattern ID
Pattern Abstraction: Meta

184

Typical Severity

Low

Description

Summary

An attacker initiates a series of events designed to cause a user, program, server, or device
to perform actions which undermine the integrity of software code, device data structures, or device
firmware, achieving the modification of the target's integrity to achieve an insecure state.

Attacker Skill or Knowledge Required

Manual or user-assisted attacks require deceptive mechanisms to trick the user into clicking a link or downloading and installing software. Automated update attacks require the attacker to host a payload and then trigger the installation of the payload code.

Resources Required

Software Integrity Attacks are usually a late stage focus of attack activity which depends upon the success of a chain of prior events. The resources required to perform the attack vary with
respect to the overall attack strategy, existing countermeasures which must be bypassed, and the
success of early phase attack vectors.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
494Download of Code Without Integrity CheckTargeted
Malicious Software Download
Attack Pattern ID
Pattern Abstraction: Meta

185

Typical Severity

Very High

Description

Summary

An attacker uses deceptive methods to cause a user or an automated process to download and install dangerous code that originates from an attacker controlled source. There are several variations to this strategy of attack.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
494Download of Code Without Integrity CheckTargeted
Related Attack Patterns
IDNameRelationship TypeRelationship Description
184Software Integrity AttacksMore Detailed
Reverse Engineering
Attack Pattern ID
Pattern Abstraction: Meta

188

Typical Severity

Low

Description

Summary

An attacker discovers the structure, function, and composition of an object, resource, or system
by using a variety of analysis techniques to effectively determine how the analyzed entity was constructed
or operates. The goal of reverse engineering is often to duplicate the function, or a part of the function,
of an object in order to duplicate or "back engineer" some aspect of its functioning. Reverse engineering
techniques can be applied to mechanical objects, electronic devices or components, or to software, although
the methodology and techniques involved in each type of analysis differ widely.

Resources Required

Access to or control of an object, resource, or system, to be analyzed. The technical resources required to engage in reverse engineering differ in accordance with the
type of object, resource, or system being analyzed.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
259Hard-Coded PasswordSecondary
References

http://en.wikipedia.org/wiki/Reverse_engineering

Software Reverse Engineering
Attack Pattern ID
Pattern Abstraction: Meta

189

Typical Severity

Low

Description

Summary

An attacker discovers the structure, function, and composition of a type of computer software
by using a variety of analysis techniques to effectively determine how the software functions and
operates, or if vulnerabilities or security weakness are present within the implementation. Reverse
engineering methods, as applied to software, can utilize a wide number approaches and techniques.
Methodologies for software reverse engineering fall into two broad categories, 'white box' and 'black
box.' White box techniques involve methods which can be applied to a piece of software when an executable
or some other compiled object can be directly subjected to analysis, revealing at least a portion of
its machine instructions that can be observed upon execution. 'Black Box' methods involve interacting
with the software indirectly, in the absence of the ability to measure, instrument, or analyze an
executable object directly. Such analysis typically involves interacting with the software at the
boundaries of where the software interfaces with a larger execution environment, such as
input-output vectors, libraries, or APIs.

Resources Required

Reverse engineering of software requires varying tools and methods depending upon whether an executable or other compiled object is present directly for analysis by tools capable of decompiling or monitoring its execution within an operating environment, as in the case of white box methods. Black box methods require at minimum the ability to interact with the functional boundaries where the software communicates with a larger processing environment, such as inter-process communication on a host operating system, or via networking protocols.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
259Hard-Coded PasswordSecondary
Related Attack Patterns
IDNameRelationship TypeRelationship Description
188Reverse EngineeringMore Detailed
Page Last Updated: September 09, 2009