Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

53

High

Null terminators are not properly handled by the filter.

High

• Injection

Medium: An attacker needs to understand alternate encodings, what the filter looks for and the data format acceptable to the target API

Test the program with various inputs and observe the behavior of the filter. Overtime it should be possible to understand what the filter is expecting.

Null characters are observed by the filter. The filter needs to be able to understand various encodings of the Null character, or only canonical data should be passed to it.

Properly handle Null characters. Make sure canonicalization is properly applied. Do not pass Null characters to the underlying APIs.

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.

• Data Modification
• Information Leakage
• Privilege Escalation

The file system of a public server is a busy place. All kinds of data get left around, much like what happens after a busy downtown parade, after which trash is strewn all over the streets. The problem with many servers is that they cannot seem to keep the mess confined. Some simple things can help. Temporary files should be stored in a secure area away from prying eyes. Backup files should not be left sitting out in the open for anyone to snatch up. It’s all really a matter of cleanliness. But let’s face it, software can be very sloppy (perhaps a reflection on the slobs we really are).

A typical server is usually a breeding ground for garbage data. Copies get made and things get left around. Backups and temporary files are left out in the open. Permissions on directories aren’t locked down. As a result, image pirates can just bypass the login to a porn site and directly access competitors’ content. Any location that is left writable ends up as a stash point for illegal software (is your site a warez server?). Have you ever logged in to your UNIX box and discovered 1,400 concurrent downloads of quake3.iso running? Most system administrators have had something like this happen to them at least once.

In general, server software uses the file system extensively. A Web server in particular is always reading or executing files on a system. The more complicated the server, the harder it is to guarantee the security of the file system. There are many Web servers out on the Internet that allow attackers
to read or execute any file on the hard drive! The code between the potential determined attacker and the file system is simply a challenging lock begging to be picked. Once an attacker gains access to your storage, you can bet he will make good use of it.

Let’s explore all the layers between an attacker and the file system. Several basic attack patterns are commonly used, such as simply asking for files and getting them. At the very least, the attacker may need to know something about the structure of the file system, but this is easy because most systems are cookie-cutter images of one another. More advanced tricks can be used to get directory listings and build a map of an unknown file system.

There are two main categories of input-driven attacks: Buffer over-flows are the largest and best hyped attack; inserting data into trusted API calls comes in a close second. This attack pattern involves user-supplied data that trickle through software and get passed as an argument to a file system call. Two basic forms of this attack involve filenames and directory browsing.

Filenames

If the user-supplied data is a filename, an attacker can simply alter the filename. Consider a log file that is based on the name of a server. Assume a popular chat program tries to connect to an Internet address (192.168.0.100, for example). The chat program wants to make a log file for the session. It first connects to a DNS server and does a lookup on the IP address. The DNS server returns the name server.exploited.com. After obtaining the name, the chat program makes a log file called server.exploited.com.LOG. Can you guess how an attacker would exploit this?

Consider what happens if the attacker has penetrated the DNS server on the network. Or, consider that the attacker has the means to poison the DNS cache on the client computer. The attacker now indirectly controls the name of the log file via the DNS name. The attacker could supply a DNS response such as server.exploited/../../../../NIDS/Events.LOG, possibly destroying a valuable log file.

Directory Browsing

Assume a Web application allows a user to access a set of reports. The path to the reports directory may be something like web/username/reports. If the username is supplied via a hidden field, an attacker could insert a bogus username such as ../../../../../WINDOWS. If the attacker needs to
remove the trailing string /reports, then he can simply insert enough characters so the string is truncated. Alternatively the attacker might apply the postfix NULL character (%00) to determine whether this terminates the string.

Once again, some popular forms this takes include

PATH%00%5C
PATH[0x00][0x5C]
PATH[alternate encoding of the NULL][additional characters required to pass filter]

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

• Reluctance to Trust

Penetration

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