Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

17

Very High

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.

High

• Modification of Resources
• API Abuse

Low → to identify and execute against an overprivileged system interface

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.

Design: Enforce principle of least privilege

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.

Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.

• Run Arbitrary Code
• Data Modification
• Information Leakage
• Privilege Escalation

“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]

Payload delivered through standard communication protocols.

Command(s) executed directly on host

Client machine and client network

Enables attacker to execute server side code with any commands that the program owner has privileges to.

Penetration

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

31

High

Target server software must be a HTTP daemon that relies on cookies.

High

• Modification of Resources
• API Abuse
• Protocol Manipulation
• Time and State

Low → To overwrite session cookie data, and submit targeted attacks via HTTP High → Exploiting a remote buffer overflow generated by attack

Ability to send HTTP request containing cookie to server

Design: Use input validation for cookies

Design: Generate and validate MAC for cookies

Implementation: Use SSL/TLS to protect cookie in transit

Implementation: Ensure the web server implements all relevant security patches, many exploitable buffer overflows are fixed in patches issued for the software.

• Information Leakage
• Data Modification
• Privilege Escalation

      One of the biggest challenges in distributed systems is communicating state between the client and server. A variety of schemes have been used, the de facto standard in web application is HTTP cookies. Because these cookies tie together a client and a server through a session, they are useful to system designers and attackers. Because cookies contain remote generated content they can also contain attack payloads.
      
      Cookies may contain a variety of data that servers use to enforce security policy, including session ID, cookie issuer, cookie issuance timestamp, session timeout, subject IP address, and MAC, however the HTTP server should not assume that the session cookie variables are invulnerable. They may be overwritten by the client and/or intermediaries. Cookies, like "hidden" HTML form fields, are generally assumed by developers to be invisible from a client standpoint, but in fact they are a target.
      
      From a privacy standpoint, cookies leave a digital audit trail that can violate a digital subject's privacy, cookies may persist personal information on hard drives, in browser cache, log files, proxy servers, and other intermediaries.
      
      
      “Because HTTP is a stateless protocol, cookies (small files that are stored in a client browser) were invented, mostly to preserve state. Poor design of cookie handling systems leaves both clients and HTTP daemons susceptible to buffer overflow attack." [Hoglund and McGraw 04]
    

HTTP cookie

Malicious input delivered through cookie in HTTP Request.

Client software, such as a browser and its component libraries, or an intermediary

1. Enables attacker to leverage state stored in cookie 2. Enables attacker a vector to attack web server and platform

Exploitation

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

1

High

The application must be navigable in a manner that associates elements (subsections) of the application with ACLs.

The various resources, or individual URLs, must be somehow discoverable by the attacker

The deployer must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.

Very High

• Analysis
• Brute Force

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.

No special resources are required for the exploit of this pattern.

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.

• Privilege Escalation

The context of this pattern's applicability is most likely a web-based application, subject to an authorization framework.

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.

• Failing Securely
• Least Privilege
• Reluctance To Trust
• Complete Mediation

• Use Authorization Mechanisms Correctly
• Design Configuration Subsystems Correctly and Distribute Safe Default Configurations

Penetration

5

Very High

System must use weak authentication mechanisms for administrative functions.

Medium

• Injection
• Protocol Manipulation

Low: Given a vulnerable phone system, the attacker's technical vector relies on attacks that are well documented in cracker 'zines and have been around for decades.

CCITT-5 or other vulnerable lines, with the ability to send tones such as combined 2,400 Hz and 2,600 Hz tones to the switch

Implementation: Upgrade phone lines. Note this may be prohibitively expensive

Use strong access control such as two factor access control for adminsitrative access to the switch

• Denial of Service
• Privilege Escalation

“Attack Pattern: Analog In-band Switching Signals (aka "Blue Boxing")
Many people have heard of 2600, the frequency used in the United States to control telephone switches during the 1960s and 1970s. (Come to think of it, probably more people have heard of the hacker 'zine 2600 and its associated club than have heard of the reason for the name of the club,) Most systems are no longer vulnerable to ancient phreaking attacks. However older systems are still found internationally. Overseas trunk lines that use trans-Atlantic cabling are prone to the in-band signal problem, and they are too expensive a resource to abandon. Thus, many overseas (home-country direct) 800/888 numbers are known to have in-band signal problems even today.

Consider the CCITT-5(C5) signaling system that is used internationally. This system does not use the commonly known 2,600 Hz, but instead uses 2,400Hz as a control signal. If you have ever heard the "pleeps" and chirps on the Pink Floyd album "The Wall," then you have heard C5 signals. There are millions of phone lines still in operation today that are routed through switches with in-band signaling.

This attack pattern involves playing specific control commands across a normal voice link, thus seizing control of the line, rerouting calls, and so on."

[Hoglund and McGraw 04]

Payload delivered through standard communication protocols.

Command(s) executed directly on host

Client machine and client network

Enables calls to be rerouted.

Penetration

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

6

High

Target software fails to strip all user-supplied input of any content that could cause the shell to perform unexpected actions.

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.

High

• Injection

Medium → The attacker has to identify injection vector, identify the operating system-specific commands, and optionally collect the output.

Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.

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.

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.

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.

• Privilege Escalation
• Data Modification
• Information Leakage

“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]

Malicious input delivered through standard input, the attacker inserts additional arguments on the application's standard interface

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

Client machine and client network (e..g Intranet)

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.

• Never Use Input as Part of a Directive to any Internal Component

Penetration

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

7

High

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.

High

• Injection
• Analysis

Medium - Determining the database type and version, as well as the right number and type of parameters to the query being injected in the absence of error messages requires greater skill than reverse-engineering database error messages.

None

In order to determine the right syntax for the query to inject, the attacker tries to determine the right number of parameters to the query and their types. This is achieved by formulating conditions that result in a true/false answer from the database. If the logical condition is true, the database will execute the rest of the query. If not, a custom error page or a default page is returned. Another approach is to ask such true/false questions of the database and note the response times to a query with a logically true condition and one with a false condition.

The only indicators of successful Blind SQL Injection are the application or database logs that show similar queries with slightly differing logical conditions that increase in complexity over time. However, this requires extensive logging as well as knowledge of the queries that can be used to perform such injection and return meaningful information from the database.

Security by Obscurity is not a solution to preventing SQL Injection. Rather than suppress error messages and exceptions, the application must handle them gracefully, returning either a custom error page or redirecting the user to a default page, without revealing any information about the database or the application internals.

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.

• Data Modification
• Information Leakage
• Run Arbitrary Code

An attacker attempts Blind SQL Injection when traditional SQL Injection is not possible due to suppression of error messages.
      
      Blind SQL Injection is performed by appending logical conditions to the query being injected such that they evaluate to true or false in the context of the data stored in the database. The first step is to get the syntax for the injected query right. For example, consider a database that has a table named "users". Consider the following query:
      SELECT fname, lname, dob, ssn, address FROM users WHERE userid="user1" AND password="user1pwd";
      
      To determine whether the "userid" field is injectable or not, the attacker tries an input such as
      user1" AND 3>1+1;--
      
      This causes the following query
      SELECT fname, lname, dob, ssn, address FROM users WHERE userid="user1" AND 3>1+1;--
      
      to be passed to the database. If the parameter is injectable, the database evaluates 3>1+1 to be true and executes the query. If, on the other hand, a condition such as 3<2 were passed, the database would return an error. Since the application suppresses such errors, the attacker never sees it. However, the application may simply hang or it may redirect to a custom error page or a default page, which is definitely an indication that the injected condition was evaluated to be false. The query can also fail if the original condition was within parentheses, such as
      
      WHERE (userid="johns" AND password="abracadabra")
      
      In such a case, the attacker will have to try injection such that the parentheses match up.
      
      Once the attacker gets the syntax right, the next step is to identify the database. This can be achieved by using operators that are unique to each database engine. For example, a condition such as "abc" = "a"+"bc" evaluates to true on MS SQL Server whereas it evaluates to false on Oracle since the concatentation operator is ||. Another approach is using system-specific functions such as those for date and time.
      
      The next step is to determine the number and type of parameters. This can again be achieved by exploiting the SELECT...WHERE conditions or using UNION SELECT statements with dummy numeric or character-based parameters.
      
      Once the type of database as well as the structure of the query has been mapped out by asking a number of questions to the database, the attacker is in a position to inject the database and extract information from it.
      
      Blind SQL Injection is a classic example of solution by reduction where the domain to be attacked is successively narrowed down by the attacker through true or false queries to the database.
    

User-controllable input to the application

SQL statements intended to bypass checks or retrieve information about the database

Back-end database

The injected SQL statements are such that they result in a true/false query to the database. If the database evaluates a statement to be logically true, it responds with the requested data. If the condition is evaluated to be logically false, an error is returned. The attacker modifies the boolean condition each time to gain information from the database.

Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.

Special characters in user-controllable input must be escaped before use by the application.

Employ application-level safeguards to filter data and handle exceptions gracefully.

• Reluctance to Trust
• Failing Securely
• Defense in Depth

• Never Use Input as Part of a Directive to any Internal Component
• Handle All Errors Safely

Penetration

CWE - Input Validation

CWE - Improper Error Handling

96

Medium

An application requires access to external libraries.

An attacker has the priviliges to block application access to external libraries.

Medium

• API Abuse
• Modification of Resources

Low

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.

• Denial of Service
• Information Leakage
• Privilege Escalation

• Failing Securely

Exploitation

8

High

The target host exposes an API to the user.

One or more API functions exposed by the target host has a buffer overflow vulnerability.

High

• API Abuse
• Injection

Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS. High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.

Use a language or compiler that performs automatic bounds checking.

Use secure functions not vulnerable to buffer overflow.

If you have to use dangerous functions, make sure that you do boundary checking.

Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.

Use OS-level preventative functionality. Not a complete solution.

• Denial of Service
• Run Arbitrary Code
• Information Leakage
• Data Modification

The user supplied data.

The buffer overrun by the attacker.

When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.

The most common is remote code execution.

Bound checking should be performed when copying data to a buffer.

• Reluctance to trust
• Defense in Depth

Penetration

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

CWE – Buffer Errors

9

High

The target host exposes a command-line utility to the user.

The command-line utility exposed by the target host has a buffer overflow vulnerability that can be exploited.

High

• Injection
• API Abuse

Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS. High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.

The attacker can probe for services available on the target host. Many services may expose a command utility. For instance Telnet is a service which can be invoked through a command shell.

Carefully review the service's implementation before making it available to user. For instance you can use manual or automated code review to uncover vulnerabilities such as buffer overflow.

Use a language or compiler that performs automatic bounds checking.

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.

Operational: Use OS-level preventative functionality. Not a complete solution.

Apply the latest patches to your user exposed services. This may not be a complete solution, specially against zero day attack.

Do not unnecessarily expose services.

• Privilege Escalation
• Run Arbitrary Code
• Data Modification
• Denial of Service
• Information Leakage

The user supplied data.

The buffer overrun by the attacker.

When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.

The most common is remote code execution.