The Common Attack Pattern Enumeration and Classification, or CAPEC, is a framework for a better understanding of adversaries (attackers) and attack methods (which can also be seen as threats). CAPEC threat modeling can help us to better understand potential threats to applications and IT systems.
CAPEC has Attack Patterns, these are common attack methods used to attack applications and IT systems, used by attackers in the wild. This is useful because most attacks follow a certain pattern, and if you understand these patterns, you will be able to develop mitigations for these attack patterns as well.
Put another way: CAPEC consists of a big list of common attack patterns. Each attack pattern describes how attackers can breach applications, including the common steps involved to use the attack pattern. Understanding attack patterns can help defenders to build the right defenses and countermeasures.
New to threat modeling? Read up about what is threat modeling.
CAPEC History
CAPEC was first developed and released in 2007, by the US Department of Homeland Security, as part of the Software Assurance (SwA) strategic initiative of the Office of Cybersecurity and Communications (CS&C).
It is still being actively developed in the form of new attack patterns, and the refinement of existing attack patterns.
CAPEC Attack Patterns
CAPEC threat modeling relates to Attack Patterns, so what is an Attack Pattern and what are the key ingredients?
Attack Pattern: An Attack Pattern is a common method of attacking an application or IT system.
Attack Pattern description: Each Attack Pattern contains a description. This is the explanation of what the Attack Pattern is about.
Weakness: Each Attack Pattern has an associated weakness. A weakness is exploited by an attack (which follows the Attack Pattern characteristics).
Execution Flow: An Execution Flow describes the steps involved in executing or performing an Attack Pattern. This is a step-by-step explanation of the common steps which make up an Attack Pattern. Note that the specifics of an actual attack may not 100% match up with the steps described in the Execution Flow (attackers can get creative and make tweaks or changes as they see fit). Execution flows have three phases: Explore, Experiment, and Exploit. The details of these phases consist of:
- Explore: How to find a system to attack (how to find a weakness associated with the Attack Pattern).
- Experiment: Experimentation to determine how to exploit a system that has a weakness as part of an attack pattern.
- Exploit: Conducting the actual attack (exploitation of the weakness).
Consequences: The Consequences describe the impact or results of a successful attack (using the Attack Pattern).
Views:
- The “Mechanisms of Attack” view indicates the realm of attack. Examples are ‘Abuse existing functionality’, and ‘Inject unexpected items’.
- The “Domains of Attack” view indicates the domain or area. Examples are ‘Software’ and ‘Hardware’.
A Walkthrough of a CAPEC Attack Pattern
In this walkthrough, I’ll look at CAPEC Attack Pattern 66: SQL Injection, which is one of the Attack Patterns of CAPEC threat modeling.
The details of CAPEC Attack Pattern 66 are shown below in the table. You can see all the aspects of the Attack Pattern, such as a description, extended description, relationships to other CAPEC Attack Patterns, Execution Flow (how to execute this pattern), Mitigations, and more.
So what can you see here? What can we learn from this?
In this case, we can learn about the common attack ‘SQL Injection’, which is indeed a common and well-known attack that affects web applications. The main learnings of the Attack Pattern are the descriptions of how to approach an attack and the related weaknesses. This allows us to learn from these and thus look for these attack approaches and weaknesses in our own applications. The mitigations explain how we can fix this in our own applications.
| Attack Pattern Parameter | Attack Pattern Description |
|---|---|
| Description | This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended. SQL Injection results from failure of the application to appropriately validate input. |
| Extended Description | When specially crafted user-controlled input consisting of SQL syntax is used without proper validation as part of SQL queries, it is possible to glean information from the database in ways not envisaged during application design. Depending upon the database and the design of the application, it may also be possible to leverage injection to have the database execute system-related commands of the attackers’ choice. SQL Injection enables an attacker to interact directly to the database, thus bypassing the application completely. Successful injection can cause information disclosure as well as ability to add or modify data in the database. |
| Likelihood | High |
| Typical Severity | High |
| Relationships | Command Injection (parent) Blind SQL Injection (child) Command Line Execution through SQL Injection (child) Object Relational Mapping Injection (child) SQL Injection through SOAP parameter tampering (child) Expanding control over the Operating System from the database (child) Domains of attack: Software Mechanisms of attack: Inject unexpected items |
| Execution Flow | Explore Survey application: The attacker first takes an inventory of the functionality exposed by the application. Techniques: Spider web sites for all available links Sniff network communications with application using a utility such as WireShark. Experiment 1. Determine user-controllable input susceptible to injection: Determine the user-controllable input susceptible to injection. For each user-controllable input that the attacker suspects is vulnerable to SQL injection, attempt to inject characters that have special meaning in SQL (such as a single quote character, a double quote character, two hyphens, a parenthesis, etc.). The goal is to create a SQL query with an invalid syntax. 2. Experiment with SQL Injection vulnerabilities: After determining that a given input is vulnerable to SQL Injection, hypothesize what the underlying query looks like. Iteratively try to add logic to the query to extract information from the database, or to modify or delete information in the database. Exploit Exploit SQL Injection vulnerability: After refining and adding various logic to SQL queries, craft and execute the underlying SQL query that will be used to attack the target system. The goal is to reveal, modify, and/or delete database data, using the knowledge obtained in the previous step. This could entail crafting and executing multiple SQL queries if a denial of service attack is the intent. |
| Prerequisites | SQL queries used by the application to store, retrieve or modify data. User-controllable input that is not properly validated by the application as part of SQL queries. |
| Skills Required | Level: Low It is fairly simple for someone with basic SQL knowledge to perform SQL injection, in general. In certain instances, however, specific knowledge of the database employed may be required. |
| Resources Required | None: No specialized resources are required to execute this type of attack. |
| Indicators | Too many false or invalid queries to the database, especially those caused by malformed input. |
| Consequences | Integrity: Modify Data Confidentiality: Read Data Confidentiality + Integrity + Availability: Execute Unauthorized Commands Confidentiality + Access Control + Authorization: Gain Privileges |
| Mitigations | Strong input validation – All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(‘) or SQL-comments (–) based on the context in which they appear. Use of parameterized queries or stored procedures – Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails. Note that SQL Injection is possible even in the presence of stored procedures if the eventual query is constructed dynamically. Use of custom error pages – Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application. |
| Example Instances | With PHP-Nuke versions 7.9 and earlier, an attacker can successfully access and modify data, including sensitive contents such as usernames and password hashes, and compromise the application through SQL Injection. The protection mechanism against SQL Injection employs a denylist approach to input validation. However, because of an improper denylist, it is possible to inject content such as “foo’/**/UNION” or “foo UNION/**/” to bypass validation and glean sensitive information from the database. See also: CVE-2006-5525. |
| Related Weaknesses | CWE-ID 89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’). CWE-ID 1286: Improper Validation of Syntactic Correctness of Input |
CAPEC Threat Modeling Conclusion
CAPEC threat modeling can help us to understand common attacks on applications and IT systems. By understanding these common attacks, you will be able to look out for these attacks in your own applications, or applications that you’re threat modeling.
CAPEC threat modeling can work together with other threat modeling methods. For example, CAPEC can work with STRIDE or PASTA when thinking about which threats may potentially apply.
