Attack patterns

Attack Patterns

Attack patterns (APs) are much like standard development patterns in that they define a series of repeatable steps that can be applied to a simulated attack against a system. From the development life cycle end of the spectrum there are two categories of attack patterns, Architectural an Physical.

Architectural attack patterns are used to attack flaws in the architectural design of the system. These are things like weaknesses in protocols, authentication strategies, and system modularization. These are more logical level attacks than actual bit manipulation attacks.

Physical attack patterns are targeted at the code itself. These are things such as SQL Injection attacks, Buffer Overflows, race conditions, and the more common forms of attacks that have become popular in the news and with script kiddies.

There is a third category of attack patterns that are independent such as Trojan Horse attacks, viri, and worms. These are not something that you can design out of your product. They operate outside and independent of any particular product. However vulnerabilities in a product can lead to these other attacks being successful on a system hosting the vulnerable product. For example the vulnerable edition of SQL Server which allowed the Slammer worm to propagate itself. The worm itself can’t be designed out, but the vulnerability in the product can be.

Attack Patterns are most useful for testing purposes, but are also very important for ensuring property architecture design, and coding techniques are used to prevent potential vulnerabilities. The APs themselves can be used to highlight areas that need to be considered for securing in a software application. They also provide either physically or in reference, the common solution pattern for preventing the vulnerability. This itself can lead to another category of patterns, Defensive Coding Patterns.

There are many commonly accepted patterns in software design and development. These are very familiar to software professionals. So to be useful, and to reduce any learning curve by introducing Attack Patterns, keeping the pattern structure as close to existing patterns is preferable. However, due to their nature some deviance from standardised pattern languages such as those used by Martin Fowler may be necessary.

Pattern Structure

Existing Pattern Structures

An example of a standardised way for describing patterns is the way they are presented in Design Patterns (Gamma, Helm, Johnson, Vlissides) [1] . They proposed that a pattern has four essential elements. The Pattern Name, The Problem, the Solution, and The Consequences (p. 3). This basic makeup is then further expanded for representation. The common representation they used is listed here(p.6):

Pattern name and Classification 

Intent 

Also Known As 

Motivation 

Applicability 

Structure 

Participants 

Collaborations 

Consequences 

Implementation 

Sample Code 

Known Uses 

Related patterns 

Martin Fowler in his representations is a bit more generalised as far as the structure goes. His pattern representation consists of

Pattern Name 

Description 

Also Known As 

‘How It Works’ 

‘When To Use It’ 

Example

A sample of this layout can be found at: [2]

When considering a Attack Patterns, the first example above is closer to what we would think of when considering how to represent an attack. Many of the items such as Intent, Motivation, Applicability, and Consequences are very relevant to security related patterns. Therefore, we will base our pattern structure on the one presented in Design Patterns (as referenced above) with necessary modifications to suite the purpose.

1 Proposed Attack Pattern Structure

In order to accurately and succinctly describe an Attack Pattern, we must have a consistent and easily consumable way of representing the patter to the user. Therefore we want to try and stay close to existing pattern representations that exist in the industry and add the necessary information to ensure we convey the pattern properly.

The proposed structure for recording Attack Patterns is as follows:

Pattern Name Type & Subtypes Also Known As Description Attacker Intent Motivation Exploitable Vulnerability Participants Process Diagram Dependencies and Conditions Sample Attack Code Existing Exploits Folow-On Attacks Mitigation Types Recommended Mitigation Related Patterns Related Alerts, Listings and Publications

These sections are described in detail below.

1.1 Pattern Name

The Pattern Name is essentially the label given to the pattern which is commonly used to refer to the pattern in question. The Name portion is fairly self-explanatory.

1.2 Types & Subtypes, Automatable

The pattern type and its associated subtypes aid in classification of the pattern. This allows users to rapidly locate and identify pattern groups that they will have to deal with in their security efforts.

Each pattern will have a type, and zero or more subtypes that identify the category of the attack pattern. Typical types include Injection Attack, Denial of Service Attack, Cryptanalysis Attack, etc. Examples of typical subtypes for Denial Of Service for example would be: DOS – Resource Starvation, DOS-System Crash, DOS-Policy Abuse.

Another important use of this field is to ensure that true patterns are not repeated unnecessarily. Often it is easy to confuse a new exploit with a new attack. New exploits are created all the time for the same attack patterns. The Buffer Overflow Attack Pattern is a good example. There are many known exploits, and viruses that take advantage of a Buffer Overflow vulnerability. But they all follow the same pattern. Therefore the Type and Subtype classification mechanism provides a way to classify a pattern. If the pattern you are creating doesn’t have a unique Type and Subtype, chances are it’s a new exploit for an existing pattern.

This section is also used to indicate if it is possible to automate the attack. If it is possible to automate the attack, it is recommended to provide a sample in the Sample Attack Code section which is described below.

1.3 Also Known As

Certain attacks may be known by several different names. This field is used to list those other names.

1.4 Description

This is a description of the attack itself, and where it may have originated from. It is essentially a free-form field that can be used to record information that doesn’t easily fit into the other fields.

1.5 Attacker Intent and Results

This field identifies the intended result of the attacker. This indicates the attacker’s main target and goal for the attack itself. For example, The Attacker Intent of a DOS – Bandwidth Starvation attack is to make the target web site unreachable to legitimate traffic.

1.6 Motivation

This field records the attacker’s reason for attempting this attack. It may be to crash a system in order to cause financial harm to the organisation, or it may be to execute the theft of critical data in order to create financial gain for the attacker.

This field is slightly different than the Attacker Intent field in that it describes why the attacker may want to achieve the Intent listed in the Attacker Intent field, rather than the physical result of the attack.

1.7 Exploitable Vulnerability

This field indicates the specific or type of vulnerability that creates the attack opportunity in the first place. An example of this in an Integer Overflow attack would be that the integer based input field is not checking size of the value of the incoming data to ensure that the target variable is capable of managing the incoming value. This is the vulnerability that the associated exploit will take advantage of in order to carry out the attack.

1.8 Participants

The Participants are one or more entities that are required for this attack to succeed. This includes the victim systems as well as the attacker and the attacker’s tools or system components. The name of the entity should be accompanied by a brief description of their role in the attack and how they interact with each other.

1.9 Process Diagram

This is one or more diagrams of the attack to visually explain how the attack is executed. This diagram can take whatever form is appropriate but it is recommended that the diagram be similar to a system or class diagram showing data flows and the components involved.

1.10 Dependencies and Conditions

Every attack must have some context to operate in and the conditions that make the attack possible. This section describes what conditions are required and what other systems or situations need to be in place in order for the attack to succeed. For example, for the attacker to be able to execute an Integer Overflow attack, they must have access to the vulnerable application. That will be common amongst most of the attacks. However if the vulnerability only exposes itself when the target is running on a remote RPC server, that would also be a condition that would be noted here.

1.11 Sample Attack Code

If it is possible to demonstrate the exploit code, this section provides a location to store the demonstration code. In some cases, such as a Denial of Service attack, specific code may not be possible. However in Overflow, and Cross Site Scripting type attacks, sample code would be very useful.

1.12 Existing Exploits

Exploits can be automated or manual. Automated exploits are often found as viruses, worms and hacking tools. If there are any existing exploits known for the attack this section should be used to list a reference to those exploits. These references can be internal such as corporate knowledge bases, or external such as the various CERT, and Virus databases.

Exploits are not to be confused with vulnerabilities. An Exploit is an automated or manual attack that utilises the vulnerability. It is not a listing of a vulnerability found in a particular product for example.

1.13 Follow-On Attacks

Follow-on attacks are any other attacks that may be enabled by this particular attack pattern. For example, a Buffer Overflow attack pattern, is usually followed by Escalation of Privilege attacks, Subversion attacks or setting up for Trojan Horse / Backdoor attacks. This field can be particularly useful when researching an attack and identifying what other potential attacks may have been carried out or set up.

1.14 Mitigation Types

The mitigation types are the basic types of mitigation strategies that would be used to prevent the attack pattern. This would commonly refer to Security Patterns and Defensive Coding Patterns. Mitigation Types can also be used as a means of classifying various attack patterns. By classifying Attack Patterns in this manner, libraries can be developed to implement particular mitigation types which can then be used to mitigate entire classes of Attack Patterns. This libraries can then be used and reused throughout various applications to ensure consistent and reliable coverage against particular types of attacks.

1.15 Recommended Mitigation

Since this is an attack pattern, the recommended mitigation for the attack can be listed here in brief. Ideally this will point the user to a more thorough mitigation pattern for this class of attack.

1.16 Related Patterns

This section will have a few subsections such as Related Patterns, Mitigation Patterns, Security Patterns, and Architectural Patterns. These are references to patterns that can support, relate to or mitigate the attack and the listing for the related pattern should note that.

An example of related patterns for an Integer Overflow Attack Pattern is:

Mitigation Patterns – Filtered Input Pattern, Self Defending Properties pattern

Related Patterns – Buffer Overflow Pattern

1.17 Related Alerts, Listings, and Publications

This section lists all the references to related alerts listings and publications such as listings in the Common Vulnerabilities and Exposures list, CERT, SANS, and any related vendor alerts. These listings should be hyperlinked to the online alerts and listings in order to ensure it references the most up to date information possible.

CVE: [3]

CWE: [4]

CERT: [5]

Various Vendor Notification Sites.

Researchers

There are two notable researchers into this area at the moment.

Rocky Heckman [6]

Contributions at: [7], [8], and [9]

and

Cigital Corp [10]

Contributions at: [11]

Reference material on Software Security and Patterns:

Alexander, Christopher; Ishikawa, Sara; & Silverstein, Murray. A Pattern Language. New York, NY: Oxford University Press, 1977

Gamma, E.; Helm, R.; Johnson, R.; & Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software ISBN 0201633612, Addison-Wesley, 1995

Thompson, Herbert; Chase, Scott, The Software Vulnerability Guide ISBN 1584503580, Charles River Media, 2005

Gegick, Michael & Williams, Laurie. “Matching Attack Patterns to Security Vulnerabilities in Software-Intensive System Designs.” ACM SIGSOFT Software Engineering Notes, Proceedings of the 2005 workshop on Software engineering for secure systems—building trustworthy applications SESS '05, Volume 30, Issue 4, ACM Press, 2005

Howard, M.; & LeBlanc, D. Writing Secure Code ISBN 0735617228, Microsoft Press, 2002.

Moore, A. P.; Ellison, R. J.; & Linger, R. C. Attack Modeling for Information Security and Survivability, Software Engineering Institute, Carnegie Mellon University, 2001

Hoglund, Greg & McGraw, Gary. Exploiting Software: How to Break Code ISBN 0201786958, Addison-Wesley, 2004

McGraw, Gary. Software Security: Building Security In ISBN 0321356705, Addison-Wesley, 2006

Viega, John & McGraw, Gary. Building Secure Software: How to Avoid Security Problems the Right Way ISBN 020172152X, Addison-Wesley, 2001

Schumacher, Markus; Fernandez-Buglioni, Eduardo; Hybertson, Duane; Buschmann, Frank; Sommerlad, Peter Security Patterns ISBN 0470858842, John Wiley & Sons, 2006

Koizol, Jack; Litchfield, D.; Aitel, D.; Anley, C.; Eren, S.; Mehta, N.; & Riley. H. The Shellcoder's Handbook: Discovering and Exploiting Security Holes ISBN 0764544683, Wiley, 2004

Schneier, Bruce. Attack Trees: Modeling Security Threats Dr. Dobb’s Journal, December, 1999

RockyH 19:01, 19 January 2007 (UTC)