Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

3

Medium

The targetted API must ignore the leading ghost characters that are used to get past the filters for the semantics to be the same.

Medium

• Injection
• API Abuse

Medium

Perform white list rather than black list input validation.

Canonicalize all data prior to validation.

Take an iterative approach to input validation (defense in depth).

• Privilege Escalation
• Data Modification

Building “Equivalent” Requests

A large number of commands are subject to parsing or filtering. In many cases a filter only considers one particular way to format a command. The fact is that the same command can usually be encoded in thousands of different ways. In many cases, an alternative encoding for the command will produce exactly the same results as the original command. Thus, two commands that look different from the logical perspective of a filter end up producing the same semantic result. In many cases, an alternatively encoded command can be used to attack a software system, because the alternative command allows an attacker to perform an operation that would otherwise be blocked.

Mapping the API Layer

A good approach to help identify and map possible alternate encodings involves writing a small program that loops through all possible inputs to a given API call. This program can, for example, attempt to encode filenames in a variety of ways. For each iteration of the loop, the “mungified” filename can be passed to the API call and the result noted.

The following code snippet loops through many possible values that can be used as a prefix to the string \test.txt. Results of running a program like this can help us to determine which characters can be used to perform a ../../ (dots and slashes) relative traversal attack.

int main(int argc, char* argv[])
{
   for(unsigned long c=0x01010101;c != -1;c++)
   {
        char _filepath[255];
        sprintf(_filepath, "%c%c%c%c\\test.txt", c >> 24, c >> 16, c >> 8, c&0x000000FF );

        try
       {
       FILE *in_file = fopen(_filepath, "r");

       if(in_file)
      {
             printf("checking path %s\n", _filepath);
             puts("file opened!");
             getchar();
             fclose(in_file);
      }
      }
      catch(...)
     {

     }
  }
  return 0;
}

Slight (but still automatic) modifications can be made to the string in creative ways. Ultimately, the modified string boils down to an attempt to use different tricks to obtain the same file. For example, one resulting attempt might try a command like this:

sprintf(_filepath, "..%c\\..%c\\..%c\\..%c\\scans2.txt", c, c, c, c);

A good way to think about this problem is to think of layers. The API call layer is what the examples shown here are mapping. If an engineer has placed any filters in front of the API call, then these filters can be considered additional layers, wrapping the original set of possibilities. By pondering all the possible inputs that can be provided at the API layer, we can begin uncovering and exercising any filters that the software has in place. If we know that the software definitely uses file API calls, we can try all kinds of filename encoding tricks that we know about. If we get lucky, eventually one set of encoding tricks will work, and we can get our data successfully through the filters and into the API call.

Drawing on the techniques described in Chapter 5 of "Exploiting Software: How to Break Code" (See reference - G. Hoglund and G. McGraw) , we can list a number of possible escape codes that can be injected into API calls (many of which help with the filter avoidance problem). If the data are eventually being piped into a shell, for example, we might be able to get control codes to take effect. A particular call may write data to a file or a stream that are eventually meant to be viewed on a terminal or in a client program. As a simple example, the following string contains two backspace characters that
are very likely to show up in the terminal’s execution:

write("echo hey!\x08\x08");

When the terminal interprets the data we have passed in, the output will be missing the last two characters of the original string. This kind of trick has been used for ages to corrupt data in log files. Log files capture all kinds of data about a transaction. It may be possible to insert NULL characters (for
example, %00 or '\0') or to add so many extra characters to the string that the request is truncated in the log. Imagine a request that has more than a thousand extra characters tacked on at the end. Ultimately, the string may be trimmed in the log file, and the important telltale data that expose an attack will be lost.

Ghost Characters

Ghost characters are extra characters that can be added to a request. The extra characters are designed not to affect the validity of the request. One easy example involves adding extra slashes to a filename. In many cases, the strings

/some/directory/test.txt

and

/////////////////some/////////////directory//////////////test.txt

are equivalent requests.

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

Web Form, URL, Network Socket, File

The payload is the parameter that an attacker is supplying to the targetted API that will allow the attacker to elevate privilege and subvert the authorization service.

The targetted API is the activation zone. These attacks often target the file system or the shell to execute commands.

Failure in authorization service may lead to compromises in data confidentiality and integrity.

• Defense in Depth
• Reluctance to Trust
• Least Privilege

• Perform input validation and filtering on data in its canonical form.
• Understand the APIs to which user input will be passed and know how permissive they are. Perform appropriate input validation given that information.

Exploitation

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

4

High

The target software must fail to anticipate all of the possible valid encodings of an IP/web address.

Medium

• Injection
• Protocol Manipulation
• API Abuse

Low → The attacker has only to try IP address combinations.

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

Design: Default deny access control policies

Design: Input validation routines should check and enforce both input data types and content against a positive specification. In regards to IP addresses, this should include the authorized manner for the application to represent IP addresses and not accept user specified IP addresses and IP address formats (such as ranges)

Implementation: Perform input validation for all remote content.

• Privilege Escalation

“Attack Pattern: Alternative IP Addresses
"IP address ranges can be represented using alternative methods. Here are some examples:
192.168.0.0/24
192.168.0.0/255.255.255.0
192.168.0.*

Classic encoding techniques can be directed against IP numbers as well."

[Hoglund and McGraw 04]

Malicious input delivered through standard input

Varies with instantiation of attack pattern. Malicious payload may be passed directly from appliation client, such as the web browser.

Client machine and client network

Enables attacker to view and access unexpected network services.

Penetration

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

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.

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

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.

• Reluctance to trust
• Defense in Depth
• Least Privilege

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

Penetration

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

CWE – Buffer Errors

10

High

The application uses environment variables.

An environment variable exposed to the user is vulnerable to a buffer overflow.

The vulnerable environment variable uses untrusted data.

Tainted data used in the environment variables is not properly validated. For instance boundary checking is not done before copying the input data to a buffer.

High

• 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.

While interacting with a system an attacker would typically investigate for environment variables that can be overwritten. The more a user knows about a system the more likely she will find a vulnerable environment variable.

On a web environment, the attacker can read the client side code and search for environment variables that can be overwritten.

There are tools such as Sharefuzz (http://sharefuzz.sourceforge.net/) which is an environment variable fuzzer for Unix that support loading a shared library. Attackers can use such tools to uncover a buffer overflow in an environment variable.

If the application does bound checking, it should fail when the data source is larger than the size of the destination buffer. If the application's code is well written, that failure should triger an alert.

Do not expose environment variable to the user.

Do not use untrusted data in your environment variables.

Use a language or compiler that performs automatic bounds checking

There are tools such as Sharefuzz (http://sharefuzz.sourceforge.net/) which is an environment variable fuzzer for Unixes that support loading a shared library. You can use Sharefuzz to determine if you are exposing an environment variable vulnerable to buffer overflow.

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

The user modifiable environment variable.

User supplied data potentially containing malicious code.

When the subroutine which uses the environment variable 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.

• Reluctance to trust

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

Penetration

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

CWE – Buffer Errors

14

High

The targeted client software communicates with an external server.

The targeted client software has a buffer oveflow vulnerability.

Medium

• API Abuse
• Injection

Low : To achieve a denial of service, an attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap requires a more in-depth knowledge and higher skill level.

The server may look like a valid server, but in reality it may be a hostile server aimed at fooling the client software. For instance the server can use honey pots and get the client to download malicious code.

Once engaged with the client, the hostile server may attempt to scan the client's host for open ports and potential vulnerabilities in the client software.

The hostile server may also attempt to install and run malicious code on the client software. That malicious code can be used to scan the client software for buffer overflow.

An example of indicator is when the client software crashes after executing code downloaded from a hostile server.

The client software should not install untrusted code from a non authenticated server.

The client software should have the latest patches and should be audited for vulnerabilities before being used to communicate with potentially hostile servers.

Perform input validation for length of buffer inputs.

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.

Ensure all buffer uses are consistently bounds-checked.

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

• Denial of Service
• Run Arbitrary Code

“Backwash Attacks: Leveraging Client-side Buffer Overflows

Nothing is more forward than directly attacking those who are attacking you. In many cases this philosophy is instantiated as a series of denial-of-service attacks launched in either direction. In standard scenarios, you can learn what IP address is being used to attack you, and then you can follow up with an attack of your own. (Be forewarned, however, that the legal ramifications of counterattack are drastic.) If the attacker is dumb enough to have open services, you may in some cases be able to own their system.

This has led some security types to consider a rather insidious tactic—creating hostile network services that look like valid targets. The basic idea builds on the idea of honey pots, but goes one important step further. Because most client software contains buffer overflows and other vulnerabilities, including a capacity to exploit these weaknesses directly when probed is within the realm of possibility.

Not surprisingly, of all the code that gets tested and probed in a security situation, client code is usually ignored. This is one of the reasons that client code ends up with more serious problems than server code. If a vulnerable client attaches to a hostile service, the hostile service can attempt to identify the type and version of the client that is connecting. This is a variety of fingerprinting.

Once the client is properly identified, the hostile server can issue a response that exploits a buffer overflow (or some other security defect) in the client. Typically this kind of attack is not designed simply just to crash the client. Attackers using this technique can inject a virus or backdoor into the original attacker’s computer using their own connection against them.

Obviously, this kind of “backwash attack” is a serious threat to an attacker. Anyone planning to attack arbitrary systems should assume that a backwash attack can and will happen. Any and all client software should be carefully audited before use.”

Attacker-supplied data potentially containing malicious code.

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 malicious code.

The most common are remote code execution or denial of service.

• 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

16

High