Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

71

High

Filtering is performed on data that has not be properly canonicalized.

Medium

• Modification of Resources
• API Abuse
• Injection

Medium: An attacker needs to understand unicode encodings and have an idea (or be able to find out) what system components may not be unicode aware.

Unicode encoded data is passed to APIs where it is not expected

Ensure that the system is Unicode aware and can properly process Unicode data. Do not make an assumption that data will be in ASCII.

Ensure that filtering or input validation is applied to canonical data.

Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.

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

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

Character Conversion

Cases where one part of the software converts data before the data are passed on to the next part also make good targets. In these “data chains,” characters often get converted many times. For example, if a user supplies the + character to a standard-issue Web server, it will be converted into a
space before it’s used on the file system.

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

Canonicalize data prior to performing any validation or filtering on it. Be aware of alternate encodings.

Penetration

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

CWE – Input Validation