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

The system uses one factor password based authentication.

The system does not have a sound password policy that is being enforced.

The system does not implement an effective password throttling mechanism.

Medium

• Brute Force

Low:  A variety of password cracking tools and dictionaries are available to launch this type of an attack.

A machine with sufficient resources for the job (e.g. CPU, RAM, HD).  Applicable dictionaries are required.  Also a password cracking tool or a custom script that leverages the dictionary database to launch the attack.

Many invalid login attempts are coming from the same machine (same IP address) or for the same log in name.  The login attempts use passwords that are dictionary words.

Employ IP spoofing to make it seem like login attempts are coming from different machines.

Create a strong password policy and ensure that your system enforces this policy.

Implement an intelligent password throttling mechanism. Care must be taken to assure that these mechanisms do not excessively enable account lockout attacks such as CAPEC-02.

• Privilege Escalation

Penetration

24

High

Ability to control the length of data passed to an active filter.

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.

Try to feed very long data as input to the program and watch for any indication that a failure has occurred.   Then see if input has been admitted into the system.

Some dynamic analysis tools may be helpful here to determine whether failure can be induced by feeding overly long inputs strings into the system.

Many exceptions are thrown by the application's filter modules in a short period of time. Check the logs. See if the probes are coming from the same IP address.

An attacker may temporally space out their probes.

An attacker may perform probes from different IP addresses.

Make sure that ANY failure occurring in the filtering or input validation routine is properly handled and that offending input is NOT allowed to go through.  Basically make sure that the vault is closed when failure occurs.

Pre-design: Use a language or compiler that performs automatic bounds checking.

Pre-design through Build: 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.

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

• Run Arbitrary Code
• Privilege Escalation
• Denial of Service

Web form, URL, File, Command line, Network socket, etc.

All of the data that just got into the system unfiltered becomes the payload.

Since the input enters the system effectively unfiltered, it may be dangerous if used in a SQL statement (i.e. SQL injection), as part of the command executed on the target system (i.e. command injection), as part of the reflection API (i.e. reflection injection), placed in logs (i.e. log injection), or perhaps to overflow another buffer in the system and give the attacker ability to execute arbitrary code. A subsequent buffer overflow may not even be required for that as the original one may be leveraged if the attacker gets lucky, that is the payload is activated in the filter itself, which also becomes the activation zone.

Since no input validation is effectively performed in this situation, the impact of the attack may be a complete compromise of confidentiality, integrity, accountability and availability services.

Input validation and filtering logic should fail securely (vault doors are closed)

• Failing Securely

• All input should be treated as rejected by default, unless explicitly allowed by the filter. Thus if the filter fails before "blessing" the data, it will be rejected.

Penetration

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

CWE - Buffer Errors

27

High

The attacker is able to create Symlink links on the target host.

Tainted data from the attacker is used and copied to temporary files.

The target host does insecure temporary file creation.

Medium

• Injection
• Time and State
• Modification of Resources

Medium/High: This attack is sophisticated because the attacker has to overcome a few challenges such as creating symlinks on the target host during a precise timing, inserting malicious data in the temporary file and have knowledge about the temporary files created (file name and function which creates them).

The attacker will certainly look for file system locations where he can write and create Symlink links.

The attacker may also observe the system and locate the temporary files created during a call to a certain function.

Use safe libraries when creating temporary files. For instance the standard library function mkstemp can be used to safely create temporary files. For shell scripts, the system utility mktemp does the same thing.

Access to the directories should be restricted as to prevent attackers from manipulating the files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file.

Follow the principle of least privilege when assigning access rights to files.

Ensure good compartmentalization in the system to provide protected areas that can be trusted.

• Data Modification
• Privilege Escalation
• Denial of Service

The content of the temporary file which is copied to the file pointed to by the Symlink.

The content of the file overwriten when writing to the Symlink.

The new content of the targeted file.

This attack can cause privilege escalation, modification of resources or denial of services.

• Least Privilege

Exploitation

Symlink Race, Wikipedia - http://en.wikipedia.org/wiki/Symlink_race

Safe temporary file creation with mkstemp - http://www.opengroup.org/onlinepubs/009695399/functions/mkstemp.html

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.

36

High

The architecture under attack must publish or otherwise make available services, of some kind, that clients can attach to, either in an unauthenticated fashion, or having obtained an authentication token elsewhere. The service need not be 'discoverable' but in the event it isn't, must have some way of being discovered by an attacker. This might include listening on a well-known port. Ultimately, the likelihood of exploit depends on discoverability of the vulnerable service.

Medium

• Analysis
• API Abuse

Low: A number of web service digging tools are available for free that help discover exposed web services and their interfaces. In the event that a web service is not listed, the attacker does not need to know much more in addition to the format of web service messages that he can sniff/monitor for.

No special resources are required in order to conduct these attacks. Web service digging tools may be helpful.

Probing techniques should often follow normal means of identifying services. Attackers will simply have to execute code that sends the appropriate interrogating SOAP messages to suspected UDDI services (in web-services scenarios). Attackers will likely want to detect and query the organization's SOA Registry.

Probing techniques become more difficult when the service isn't advertised, or doesn't leverage discovery frameworks such as UDDI or the WS-I standard. In these cases, sniffing network traffic may suffice, depending on whether or not discovery occurs over a protected channel.

Authenticating both services and their discovery, and protecting that authentication mechanism simply fixes the bulk of this problem. Protecting the authentication involves the standard means, including: 1) protecting the channel over which authentication occurs, 2) preventing the theft, forgery, or prediction of authentication credentials or the resultant tokens, or 3) subversion of password reset and the like.

• Information Leakage
• Privilege Escalation

This pattern applies in contexts in which an organization makes services available, preferrably in a discoverable fashion.

Attackers can leverage web- or SOA-services available to them whether or not those services are 1) advertised by a directory, 2) themselves respond on well-known interfaces, or are 3) predictably indexed. Once identified and interfaced with, the Attacker is free to use the interface for all its spoils. In these cases, the system's designers have fallen prey to believing security by obscurity will work, or have not thought about a service's actual availability at all.

Unlike more vanilla client-server interfaces, services usually publish an easy to use interface in XML (through UDDI) making reverse engineering services for use trivial.

Authenticate every request or message to a service

Do not rely on lack of discoverability to protect privileged functions within the service

• Never Assuming that Your Secrets Are Safe
• Complete Mediation

• Use Authorization Mechanisms Correctly
• Use Authentication Mechanisms, Where Appropriate, Correctly

Penetration

40

Very High

User terminals must have a permissive access control such as world writeable that allows normal users to control data on other user's terminals.

High

• Injection

Low

Access to a terminal on the target network

Design: Ensure that terminals are only writeable by named owner user and/or administrator

Design: Enforce principle of least privilege

• Privilege Escalation
• Information Leakage
• Run Arbitrary Code

Payload delivered through standard user terminal.

Command(s) executed directly on host, in other victim's terminal

Multi-user host

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

Exploitation

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

42

High

The target system uses a mail server.

Mail server vendor has not released a patch for the MIME conversion routine, the patch itself has a security hole or does not fix the original problem, or the patch has not been applied to the user's system.

High

• Injection

Low:  It may be trivial to cause a DoS via this attack pattern
High:  Causing arbitrary code to execute on the target system.

The first step is to figure what mail server (and what version) is running on the target system.

Stay up to date with third party vendor patches

Disable the 7 to 8 bit conversion.  This can be done by removing the F=9 flag from all Mailer specifications in the sendmail.cf file.  

For example, a sendmail.cf file with these changes applied should look similar to (depending on your system and configuration):

Mlocal,    P=/usr/libexec/mail.local, F=lsDFMAw5:/|@qrmn, S=10/30, R=20/40,
           T=DNS/RFC822/X-Unix,
           A=mail -d $u
Mprog,     P=/bin/sh, F=lsDFMoqeu, S=10/30, R=20/40,
           D=$z:/,
           T=X-Unix,
           A=sh -c $u

This can be achieved for the "Mlocal" and "Mprog" Mailers by modifying the ".mc" file to include the following lines:

define(`LOCAL_MAILER_FLAGS',
    ifdef(`LOCAL_MAILER_FLAGS',
        `translit(LOCAL_MAILER_FLAGS, `9')',
        `rmn'))
define(`LOCAL_SHELL_FLAGS',
    ifdef(`LOCAL_SHELL_FLAGS',
        `translit(LOCAL_SHELL_FLAGS, `9')',
        `eu'))

and then rebuilding the sendmail.cf file using m4(1).

From "Exploiting Software", please see reference below.

Use the sendmail restricted shell program (smrsh)

Use mail.local

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

Content-Based Buffer Overflow

Data files are ubiquitous. They are used to store everything from documents to content media and critical computer settings. Every file has an inherent format that often encompasses special information such as file length, media type, and which fonts are boldface, all encoded directly in the data file. The attack vector against data files like these is simple: Mess up the data file and wait for some unsuspecting user to open it.

Some kinds of files are strikingly simple and others have complex binary structures and numerical data embedded in them. Sometimes the simple act of opening a complex file in a hex editor and tweaking a few bytes is enough to cause the (unsuspecting) program that consumes the file to crash and burn.

The especially formated e-mail message whose body is put together in a way as to trigger the MIME conversion buffer overflow in the 7 to 8 bit MIME conversion function.

The shellcode included as part of the e-mail message body that is executed on the target system with root privileges after the stack based buffer overflow in the 7 to 8 bit MIME conversion function is leveraged.

The function performing 7 to 8 bit MIME conversion.

• Failing Securely

Penetration

Exploitation

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

CERT Advisory CA-1997-05, "MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4". Available at: http://www.cert.org/advisories/CA-1997-05.html

44

Very High

Target software processes binary resource files.

Target software contains a buffer overflow vulnerability reachable through input from a user-controllable binary resource file.

High

• Modification of Resources

Medium: to modify file, deceive client into downloading, locate and exploit remote stack or heap vulnerability

Perform appropriate bounds checking on all buffers.

Design: Enforce principle of least privilege

Design: Static code analysis

Implementation: Execute program in less trusted process space environment, do not allow lower integrity processes to write to higher integrity processes

Implementation: Keep software patched to ensure that known vulnerabilities are not available for attackers to target on host.

• Denial of Service
• Run Arbitrary Code

"Attack Pattern: Overflow Binary Resource File
The attacker modifies a resource file, such as sound, video, graphic, or font file. Sometimes simply editing the target resource file in a hex editor is possible. The attacker modifies headers and structure data that indicate the length of strings, and so forth."

[Hoglund and McGraw 04]

Penetration

Exploitation

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

45

High

The attacker can create symbolic link on the target host.

The target host does not perform correct boundary checking while consuming data from a ressources.

High

• Injection
• Modification of Resources

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 will look for temporary files in the world readable directories. Those temporary files are often created and read by the system.

The attacker will look for Symbolic link or link target file that she can overide.

An attacker creating or modifying Symbolic links is a potential signal of attack in progress.

An attacker deleting temporary files can also be a sign that the attacker is trying to replace legitimate resources with malicious ones.

Pay attention to the fact that the ressource you read from can be a replaced by a Symbolic link. You can do a Symlink check before reading the file and decide that this is not a legitimate way of accessing the resource.

Because Symlink can be modified by an attacker, make sure that the ones you read are located in protected directories.

Pay attention to the resource pointed to by your symlink links (See attack pattern named "Forced Symlink race"), they can be replaced by malicious resources.

Always check the size of the input data before copying to a buffer.

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.

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

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

Content-Based Buffer Overflow

Data files are ubiquitous. They are used to store everything from documents to content media and critical computer settings. Every file has an inherent format that often encompasses special information such as file length, media type, and which fonts are boldface, all encoded directly in the data file. The attack vector against data files like these is simple: Mess up the data file and wait for some unsuspecting user to open it.

Some kinds of files are strikingly simple and others have complex binary structures and numerical data embedded in them. Sometimes the simple act of opening a complex file in a hex editor and tweaking a few bytes is enough to cause the (unsuspecting) program that consumes the file to crash and burn.

What's really interesting from an attacker's point of view is formatting data file-embedded poison pills in such a way that virus code is activated. A great example of this involved the Winamp program in which an overly long IDv3 tag would cause a buffer overflow. In the header of an MP3 file, there is a location where a normal text string can be placed. This is called the IDv3 tag, and if an overly long tag were to be supplied, Winamp would suffer a buffer overflow. This could be used by an attacker to construct malicious music files that attack the computer once they are opened in Winamp.

Access right to the symbolic link:

When a symlink is created there are no rights associated with it (this why you read them with rights lrwxrwxrwx). So everybody can modify them even if the owner of the Symlink is root and if the user changing the Symbolic link has no right on the link target file. The relevant rights are on the linked target file. To prevent someone from modifying the symlink in the first place, the directory containing it should have limited access rights.

The resource pointed to by the Symbolic link (e.g., file, directory, etc.)

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

Penetration

Exploitation

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

CWE - Buffer Errors

46

High

The target program consumes user-controllable data in the form of tags or variables.

The target program does not perform sufficient boundary checking.

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.

An attacker can modify the variables and tag exposed by the target program.

An attacker can automate the probing by input injection with script or automated tools.

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.

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

Do not trust input data from user. Validate all user input.

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

Content-Based Buffer Overflow

Data files are ubiquitous. They are used to store everything from documents to content media and critical computer settings. Every file has an inherent format that often encompasses special information such as file length, media type, and which fonts are boldface, all encoded directly in the data file. The attack vector against data files like these is simple: Mess up the data file and wait for some unsuspecting user to open it.

Some kinds of files are strikingly simple and others have complex binary structures and numerical data embedded in them. Sometimes the simple act of opening a complex file in a hex editor and tweaking a few bytes is enough to cause the (unsuspecting) program that consumes the file to crash and burn.

What's really interesting from an attacker's point of view is formatting data file-embedded poison pills in such a way that virus code is activated. A great example of this involved the Winamp program in which an overly long IDv3 tag would cause a buffer overflow. In the header of an MP3 file, there is a location where a normal text string can be placed. This is called the IDv3 tag, and if an overly long tag were to be supplied, Winamp would suffer a buffer overflow. This could be used by an attacker to construct malicious music files that attack the computer once they are opened in Winamp.

The variable or tag exposed to the user.

The new value of the variable or tag (could be an oversized string).

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

Penetration

Exploitation

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

CWE - Buffer Errors

47

High

The program expands one of the parameters passed to a function with input controlled by the user, but a later function making use of the expanded parameter erroneously considers the original, not the expanded size of the parameter.

The expanded parameter is used in the context where buffer overflow may becomes possible due to the incorrect understanding of the parameter size (i.e. thinking that it is smaller than it really is).

Medium

• Injection

High:  Finding this particular buffer overflow may not be trivial.  Also, stack and especially heap based buffer overflows require a lot of knowledge if the intended goal is aribtrary code execution.  Not only that the attacker needs to write the shell code to accomplish his or her goals, but the attacker also needs to find a way to get the program execution to jump to the planted shellcode.  There also needs to be sufficient room for the payload.  So not every buffer overflow will be exploitable, even by a skilled attacker.

Access to the program source or binary.  If the program is only available in binary then a disassembler and other reverse engineering tools will be helpful.

Ensure that when parameter expansion happens in the code that the assumptions used to determine the resulting size of the parameter are accurate and that the new size of the parameter is visible to the whole system

• Privilege Escalation
• Privilege Escalation
• Denial of Service
• Data Modification

The Multiple Operation Problem

Whenever data are manipulated by a function, the function should track exactly what it's doing to the data. This is straightforward when only one function is "munging" data. But when multiple operations are working on the same data, keeping track of the effects of each operation gets much harder. Incorrect tracking leads to big problems. This is especially true if the operation changes a string somehow.

There are a number of common operations on strings that will change the size of the string. The problem we're discussing occurs if the code performing the conversion does not resize the buffer that the string lives in.

Penetration

Exploitation

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code.

48

High

The victim's software must not differentiate between the location and type of reference passed the client software, e.g. browser

High

• API Abuse
• Modification of Resources
• Protocol Manipulation

Medium: attacker identifies known local files to exploit

Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.

Implementation: Ensure all configuration files and resource are either removed or protected when promoting code into production.

Design: Use browser technologies that do not allow client side scripting.

Implementation: Perform input validation for all remote content.

Implementation: Perform output validation for all remote content.

Implementation: Disable scripting languages such as Javascript in browser

• Information Leakage
• Data Modification

"Attack Pattern: Passing Local Filenames to Functions That Expect a URL
Use local filenames with functions that expect to consume a URL. Find interesting connections."

[Hoglund and McGraw 04]

Exploitation

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

52

High

The program does not properly handle postfix NULL terminators

High

• Injection
• Modification of Resources
• API Abuse

Medium:  Directory traversal
High:  Execution of arbitrary code

Properly handle the NULL characters supplied as part of user input prior to doing anything with the data.

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

• Reluctance to Trust

Penetration

Exploitation

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

iDefense Labs Public Advisory: Adobe Acrobat/Acrobat Reader ActiveX Control Buffer Overflow Vulnerability Available at: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=126

Bugtraq mailing list archive: PHP Input Validation Vulnerabilities Available at: http://msgs.securepoint.com/bugtraq/

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

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

58

High

The attacker needs to be able to identify HTTP Get URLs. The Get methods must be set to call applications that perform operations other than get such as update and delete.

High

• Injection

Low: It is relatively straightforward to identify an HTTP Get method that changes state on the server side and executes against an overprivileged system interface

Attacker may enumerate URLs to identify vulnerable services.

Design: Enforce principle of least privilege

Implementation: Ensure that HTTP Get methods only retrieve state and do not alter state on the server side

Implementation: Ensure that HTTP methods have proper ACLs based on what the funcitonality they expose

• Data Modification
• Privilege Escalation

Payload delivered through standard communication protocols. In the Flickr and del.icio.us examples above, this is done through a normal web browser

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

Exploitation

Mark O'Neill, "Security for REST Web Services", http://www.vordel.com/downloads/rsa_conf_2006.pdf

59

High

The target host uses session IDs to keep track of the users.

Session IDs are used to control access to resources.

The session IDs used by the target host are predictable.For example, the session IDs are generated using predictable information (e.g., time).

High

• Spoofing
• Brute Force
• Analysis

Low: There are tools to brute force sesion ID. Those tools require a low level of knowledge.
Medium/High: Predicting Session ID may require more computation work which uses advanced analysis such as statistic analysis.

The attacker can perform analysis of the randomness of the session generation algortihm.

The attacker may need to steal a few valid session IDs using a different type of attack. And then use those session ID to predict the following ones.

The attacker can use brute force tools to find a valid session ID.

Use a strong source of randomness to generate a session ID.

Use adequate length session IDs

Do not use information available to the user in order to generate session ID (e.g., time).

Ideas for creating random numbers are offered by Eastlake [RFC1750]

Encrypt the session ID if you expose it to the user. For instance session ID can be stored in a cookie in encrypted format.

• Privilege Escalation

• Securing the Weakest Link

Penetration