An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targetted, ignores the leading "ghost" characters, and therefore processes the attacker's input. This occurs when the targetted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targetted API. Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes. One commonly used possibility involves adding ghost characters—extra characters that don’t affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.

Determine if the source code is available and if so, examine the filter logic. If the source code is not available, write a small program that loops through various possible inputs to given API call and tries a variety of alternate (but equivalent) encodings of strings with leading ghost characters. Knowlege of frameworks and libraries used and what filters they apply will help to make this search more structured. Observe the effects. See if the probes are getting past the filters. Identify a string that is semantically equivalent to that which an attacker wants to pass to the targeted API, but syntactically structured in a way as to get past the input filter. That encoding will contain certain ghost characters that will help it get past the filters. These ghost characters will be ignored by the targeted API. Once the "winning" alternate encoding using (typically leading) ghost characters is identified, an attacker can launch the attacks against the targetted API (e.g. directory traversal attack, arbitrarary shell command execution, corruption of files) 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 Medium Injection API Abuse Alternate Encoding with Ghost Characters in FTP and Web Servers Some web and FTP servers fail to detect prohibited upward directory traversals if the user-supplied pathname contains extra characters such as an extra leading dot. For example, a program that will disallow access to the pathname “../test.txt” may erroneously allow access to that file if the pathname is specified as “…/test.txt”. This attack succeeds because 1) the input validation logic fails to detect the triple-dot as a directory traversal attempt (since it isn’t dot-dot), 2) some part of the input processing decided to strip off the “extra” dot, leaving the dot-dot behind. Using the file system API as the target, the following strings are all equivalent to many programs: .../../../test.txt ............/../../test.txt ..?/../../test.txt ..????????/../../test.txt ../test.txt As you can see, there are many ways to make a semantically equivalent request. All these strings ultimately result in a request for the file ../test.txt. 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. 173 Targeted 41 Targeted 172 Targeted 171 Targeted 179 Targeted 180 Targeted 181 Secondary 183 Secondary 184 Secondary 20 Targeted 74 Targeted 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 Low Low High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eugene Lebanidze Cigital, Inc 2007-02-26 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name, Attack Execution Flow and Examples Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This attack relies on the attacker using unexpected formats for representing IP addresses. Networked applications may expect network location information in a specific format, such as fully qualified domains names, URL, IP address, or IP Address ranges. The issue that the attacker can exploit is that these design assumptions may not be validated against a variety of different possible encodings and network address location formats. Applications that use naming for creating policy namespaces for managing access control may be susceptible to queryin directly by IP addresses, which is ultimately a more generally authoritative way of communicating on a network. Alternative IP addresses can be used by the attacker to bypass application access control in order to gain access to data that is only protected by obscuring its location. In addition this type of attack can be used as a reconnaissance mechansim to provide entry point information that the attacker gathers to penetrate deeper into the system.

The target software must fail to anticipate all of the possible valid encodings of an IP/web address. High Medium Injection Protocol Manipulation API Abuse An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions. 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. 291 Targeted 180 Targeted 41 Targeted 345 Targeted Penetration Medium Medium High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-01-01 Gunnar Peterson Cigital, Inc 2007-02-28 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-09 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name, Attack Prerequisites,Resources Required and Method of Attack Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This attack against older telephone switches and trunks has been around for decades. The signal is sent by the attacker to impersonate a supervisor signal. This has the effect of rerouting or usurping command of the line and call. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authentication for administrative functions. While the infrastructure is different than standard current applications like web applications, there are hisotrical lessons to be learned to upgrade the access control for administrative functions.

System must use weak authentication mechanisms for administrative functions. Very High Medium Injection Protocol Manipulation Attacker identifies a vulnerable CCITT-5 phone line, and sends a combination tone to the switch in order to request administrative access. Based on tone and timing parameters the request is verified for access to the switch. Once the attacker has gained control of the switch launching calls, routing calls, and a whole host of opportunities are available. 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. 264 Targeted Penetration Low Medium Medium Other Other Other All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-01-01 Gunnar Peterson Cigital, Inc 2007-02-28 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-09 Review and revise

Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection. In order to achieve this using Blind SQL Injection, an attacker: For example, an attacker may try entering something like "username' AND 1=1; --" in an input field. If the result is the same as when the attacker entered "username" in the field, then the attacker knows that the application is vulnerable to SQL Injection. The attacker can then ask yes/no questions from the database server to extract information from it. For example, the attacker can extract table names from a database using the following types of queries: "username' AND ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 108". If the above query executes properly, then the attacker knows that the first character in a table name in the database is a letter between m and z. If it doesn't, then the attacker knows that the character must be between a and l (assuming of course that table names only contain alphabetic characters). By performing a binary search on all character positions, the attacker can determine all table names in the database. Subsequently, the attacker may execute an actual attack and send something like: "username'; DROP TABLE trades; --

Hypothesize SQL queries in application Generated hypotheses regarding the SQL queries in an application. For example, the attacker may hypothesize that his input is passed directly into a query that looks like: "SELECT * FROM orders WHERE ordernum = _____" or "SELECT * FROM orders WHERE ordernum IN (_____)" or "SELECT * FROM orders WHERE ordernum in (_____) ORDER BY _____" Of course, there are many other possibilities. Research types of SQL queries and determine which ones could be used at various places in an application. env-All Determine how to inject information into the queries Determine how to inject information into the queries from the previous step such that the injection does not impact their logic. For example, the following are possible injections for those queries: "5' OR 1=1; --" and "5) OR 1=1; --" and "ordernum DESC; --" Add clauses to the SQL queries such that the query logic does not change. env-All Add delays to the SQL queries in case server does not provide clear error messages (e.g. WAITFOR DELAY '0:0:10' in SQL Server or BENCHMARK(1000000000,MD5(1) in MySQL). If these can be injected into the queries, then the length of time that the server takes to respond reveals whether the query is injectable or not. env-All At least one way to complete a hypothesized SQL query that would violate the application developer's assumptions. Determine user-controllable input susceptible to injection Determine the user-controllable input susceptible to injection. For each user-controllable input that the attacker suspects is vulnerable to SQL injection, attempt to inject the values determined in the previous step. If an error does not occur, then the attacker knows that the SQL injection was successful. Use web browser to inject input through text fields or through HTTP GET parameters. env-Web Use a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc. env-Web Use network-level packet injection tools such as netcat to inject input env-Web env-ClientServer env-Peer2Peer env-CommProtocol Use modified client (modified by reverse engineering) to inject input. env-ClientServer env-Peer2Peer env-CommProtocol Attacker receives normal response from server. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Response takes expected amount of time after delay is injected. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Server sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException) env-Web env-ClientServer env-Peer2Peer env-CommProtocol At least one user-controllable input susceptible to injection found. No user-controllable input susceptible to injection found. Unusual queries such as the ones described in the previous step, in application logs. Log files may contain unusual messages such as "User bob' OR 1=1; -- logged in". Operators should be alerted when such SQL commands appear in the logs. Input validation of user-controlled data before including it in a SQL query Use APIs that help mitigate SQL injection (such as PreparedStatement in Java) Determine database type Determines the type of the database, such as MS SQL Server or Oracle or MySQL, using logical conditions as part of the injected queries Try injecting a string containing char(0x31)=char(0x31) (this evaluates to 1=1 in SQL Server only) env-Web env-ClientServer env-Peer2Peer env-CommProtocol Try injecting a string containing 0x313D31 (this evaluates to 1=1 in MySQL only) env-Web env-ClientServer env-Peer2Peer env-CommProtocol Inject other database-specific commands into input fields susceptible to SQL Injection. The attacker can determine the type of database that is running by checking whether the query executed successfully or not (i.e. wheter the attacker received a normal response from the server or not). env-Web env-ClientServer env-Peer2Peer env-CommProtocol Success outcome in previous step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in previous step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Database platform in use discovered. Database platform in use not discovered. Extract information about database schema Extract information about database schema by getting the database to answer yes/no questions about the schema. Automatically extract database schema using a tool such as Absinthe. env-Web Manually perform the blind SQL Injection to extract desired information about the database schema. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Success outcome in previous step. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in previous step. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Desired information about database schema extracted. Desired information about database schema could not be extracted. Large number of unusual queries in database logs. Exploit SQL Injection vulnerability Use the information obtained in the previous steps to successfully inject the database in order to bypass checks or modify, add, retrieve or delete data from the database Use information about how to inject commands into SQL queries as well as information about the database schema to execute attacks such as dropping tables, inserting records, etc. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Success outcome in previous step. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in previous step. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Attacker achieves goal of unauthorized system access, denial of service, etc. Attacker cannot exploit the information gathered by blind SQL Injection 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 High Injection Analysis In the PHP application TimeSheet 1.1, an attacker can successfully retrieve username and password hashes from the database using Blind SQL Injection. If the attacker is aware of the local path structure, the attacker can also remotely execute arbitrary code and write the output of the injected queries to the local path. Blind SQL Injection is possible since the application does not properly sanitize the $_POST['username'] variable in the login.php file. CVE-2006-4705 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. 89 Targeted 209 Targeted 74 Secondary 20 Secondary 390 Secondary 66 Occasionally Precedes 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 High High High All All All All CWE - Input Validation CWE - Improper Error Handling Chiradeep B Chhaya 2007-02-22 Third Draft - Revised to schema v1.4 Malik Hamro Cigital, Inc 2007-02-27 Reformat to new schema and review Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Description, Attack Prerequisites and Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback Amit Sethi Cigital, Inc. 2007-10-29 Added extended Attack Execution Flow

This attack targets libraries or shared code modules which are vulnerable to buffer overflow attacks. An attacker who has access to an API may try to embed malicious code in the API function call and exploit a buffer overflow vulnerability in the function's implementation. All clients that make use of the code library thus become vulnerable by association. This has a very broad effect on security across a system, usually affecting more than one software process.

1- An attacker can call an API exposed by the target host. 2- On the probing stage, the attacker injects malicious code using the API call and observes the results. The attacker's goal is to uncover a buffer overflow vulnerability. 3- The attacker finds a buffer overflow vulnerability, crafts malicious code and injects it through an API call. The attacker can at worst execute remote code on the target host. 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 High API Abuse Injection Attack Example: Libc in FreeBSD A buffer overflow in the FreeBSD utility setlocale (found in the libc module) puts many programs at risk all at once. Xtlib A buffer overflow in the Xt library of the X windowing system allows local users to execute commands with root privileges. 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. 120 Targeted 119 Targeted 118 Targeted 74 Targeted 20 Targeted 100 More Detailed Bound checking should be performed when copying data to a buffer. Reluctance to trust Defense in Depth Penetration High High High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eric Dalci Cigital, Inc 2007-02-13 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Description Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This attack targets command-line utilities available in a number of shells. An attacker can leverage a vulnerability found in a command-line utility to escalate privilege to root.

1- Attacker identifies command utilities exposed by the target host. 2- On the probing stage, the attacker interacts with the command utility and observes the results of its input. The attacker's goal is to uncover a buffer oveflow in the command utility. For instance the attacker may find that input data are not properly validated. 3- The attacker finds a buffer overflow vulnerability in the command utility and tries to exploit it. He crafts malicious code and injects it using the command utility. The attacker can at worst execute remote code on the target host. 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 High Injection API Abuse Attack Example: HPUX passwd A buffer overflow in the HPUX passwd command allows local users to gain root privileges via a command-line option.</AttackExample> <AttackExample>Attack Example: Solaris getopt A buffer overflow in Solaris’s getopt command (found in libc) allows local users to gain root privileges via a long argv[0]. 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. 120 Targeted 118 Targeted 119 Targeted 74 Targeted 20 Targeted 100 More Detailed 10 More Detailed Reluctance to trust Defense in Depth Least Privilege Bound checking should be performed when copying data to a buffer. Penetration High High High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eric Dalci Cigital, Inc 2007-02-13 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Attack Execution Flow, Probing Techniques and Method of Attack Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.

1- The attacker tries to find an environment variable which can be overwritten for instance by gathering information about the target host (error pages, software's version number, etc.). 2- The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow. 3- The attacker potentially leverages the buffer overflow to inject maliciously crafted code in an attempt to execute privileged command on the target environment. 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 High Injection Attack Example: Buffer Overflow in $HOME A buffer overflow in sccw allows local users to gain root access via the $HOME environmental variable. CVE-1999-0906 Attack Example: Buffer Overflow in TERM A buffer overflow in the rlogin program involves its consumption of the TERM environmental variable. CVE-1999-0046 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. 120 Targeted 302 Targeted 118 Targeted 119 Targeted 74 Targeted 99 Targeted 20 Targeted 100 More Detailed Reluctance to trust Bound checking should be performed when copying data to a buffer. Penetration High High High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eric Dalci Cigital, Inc 2007-02-13 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.

1. The attacker creates a custom hostile service 2. The attacker acquires information about the kind of client attaching to her hostile service to determine if it contains an exploitable buffer overflow vulnerability. 3. The attacker intentionally feeds malicious data to the client to exploit the buffer overflow vulnerability that she has uncovered. 4. The attacker leverages the exploit to execute arbitrary code or to cause a denial of service. The targeted client software communicates with an external server. The targeted client software has a buffer oveflow vulnerability. High Medium API Abuse Injection Attack Example: Buffer Overflow in Internet Explorer 4.0 Via EMBED Tag Authors often use <EMBED> tags in HTML documents. For example <EMBED TYPE="audio/midi" SRC="/path/file.mid" AUTOSTART="true"> If an attacker supplies an overly long path in the SRC= directive, the mshtml.dll component will suffer a buffer overflow. This is a standard example of content in a Web page being directed to exploit a faulty module in the system. There are potentially thousands of different ways data can propagate into a given system, thus these kinds of attacks will continue to be found in the wild. 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. 120 Targeted 353 Targeted 118 Targeted 119 Targeted 74 Targeted 20 Targeted 8 More Detailed Reluctance to Trust Defense in Depth Penetration High High High Client-Server Other All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eric Dalci Cigital, Inc 2007-02-13 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

An attacker tries each of the words in a dictionary as passwords to gain access to the system via some user's account. If the password chosen by the user was a word within the dictionary, this attack will be successful (in the absence of other mitigations). This is a specific instance of the password brute forcing attack pattern.

Determine application's/system's password policy Determine the password policies of the target application/system. Determine minimum and maximum allowed password lengths. env-All Determine format of allowed passwords (whether they are required or allowed to contain numbers, special characters, etc., or whether they are allowed to contain words from the dictionary). env-All Determine account lockout policy (a strict account lockout policy will prevent brute force attacks). env-All Passwords are used in the application/system env-All Passwords are not used in the application/system. env-All Select dictionaries Pick the dictionaries to be used in the attack (e.g. different languages, specific terminology, etc.) Select dictionary based on particular users' preferred languages. env-All Select dictionary based on the application/system's supported languages. env-All Determine username(s) to target Determine username(s) whose passwords to crack. Obtain username(s) by sniffing network packets. env-CommProtocol env-Peer2Peer env-ClientServer Obtain username(s) by querying application/system (e.g. if upon a failed login attempt, the system indicates whether the entered username was valid or not) env-All Obtain usernames from filesystem (e.g. list of directories in C:\Documents and Settings\ in Windows, and list in /etc/passwd in UNIX-like systems) env-Embedded env-Local Remote application or system provides no indication regarding whether a given username is valid or not. env-ClientServer env-Peer2Peer env-Web env-CommProtocol At least one valid username found. Presence of any valid usernames could not be established. Do not reveal information regarding validity of particular usernames to users. Lock out accounts whose usernames are suspected to have been compromised. Use dictionary to crack passwords. Use a password cracking tool that will leverage the dictionary to feed passwords to the system and see if they work. Try all words in the dictionary, as well as common misspellings of the words as passwords for the chosen username(s). env-All Try common combinations of words in the dictionary, as well as common misspellings of the combinations as passwords for the chosen username(s). env-All Application/system does not use password authentication. env-All Attacker determines correct password for a user ID and obtains access to application or system. Attacker is unable to determine correct password for a user ID and obtain access to application or system. Large number of authentication failures in logs. Enforce strict account lockout policies. Enforce strong passwords (having sufficient length and containing mix of lower case and upper case letters, numbers, and special characters) 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. High Medium Brute Force A system user selects the word "treacherous" as their passwords believing that it would be very difficult to guess. The password-based dictionary attack is used to crack this password and gain access to the account. The Cisco LEAP challenge/response authentication mechanism uses passwords in a way that is susceptible to dictionary attacks, which makes it easier for remote attackers to gain privileges via brute force password guessing attacks. Cisco LEAP is a mutual authentication algorithm that supports dynamic derivation of session keys. With Cisco LEAP, mutual authentication relies on a shared secret, the user's logon password—which is known by the client and the network, and is used to respond to challenges between the user and the Remote Authentication Dial-In User Service (RADIUS) server. Methods exist for someone to write a tool to launch an offline dictionary attack on password-based authentications that leverage Microsoft MS-CHAP, such as Cisco LEAP. The tool leverages large password lists to efficiently launch offline dictionary attacks against LEAP user accounts, collected through passive sniffing or active techniques. CVE-2003-1096 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 521 Targeted 262 Targeted 263 Targeted 49 More Abstract Occasionally Follows 70 More Detailed Occasionally Precedes 55 Occasionally Follows Penetration High Medium Low All All All All Eugene Lebanidze Cigital, Inc 2007-02-26 Sean Barnum Cigital, Inc 2007-03-01 Review and revision of content Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Solutions Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback Amit Sethi Cigital, Inc. 2007-10-29 Added extended Attack Execution Flow

In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. lets the user input into the system unfiltered).

Survey The attacker surveys the target application, possibly as a valid and authenticated user Spidering web sites for inputs that involve potential filtering env-Web Brute force guessing of filtered inputs env-All Software messages (e.g., "the following characters are not allowed...") indicate that filtered inputs are present in the software. ( env-Web env-ClientServer Application uses predefined inputs (e.g., drop-down lists, radio buttons, selection lists, etc.) env-Web env-ClientServer env-Local env-Embedded Managed code (e.g., .NET, Java) is likely, based on URLs. env-Web Managed code (e.g., .NET, Java) is likely, based on files found in software. env-ClientServer env-Local env-Embedded env-Peer2Peer env-CommProtocol Java code is likely, based on standard disclaimers (e.g., "This software contains Java from Sun...."). Such declarations are frequent on commercial software that is based on Java. env-Embedded env-Local env-ClientServer Java code is likely, based on one of the other indicators, but it could contain Java Native Interface (JNI) code. This is indicated by the inclusion of DLLs or equivalent binary object code with Java code. env-Embedded env-Local env-ClientServer Attempt injections Try to feed overly long data to the system. This can be done manually or a dynamic tool (black box) can be used to automate this. An attacker can also use a custom script for that purpose. Brute force attack through black box penetration test tool. env-Web env-ClientServer env-CommProtocol env-Peer2Peer Fuzzing of communications protocols env-CommProtocol env-Peer2Peer env-ClientServer Manual testing of possible inputs with attack data. env-All Unexpected output from the application. No unexpected output from the application. Monitor and analyze logs for failures that exceed common usage sizes. For example, if typical transactions, even normal failed transactions, rarely exceed 250 characters, monitor logs for all attempts that contain 250 or more characters. In the event of successful exploitation, there may actually be no useful log. But an attacker's experiments will likely show up, giving clues to the ultimate attack. Disconnect or block connections from systems or users that exceed acceptable heuristics for normal transaction sizes. Monitor responses Watch for any indication of failure occurring. Carefully watch to see what happened when filter failure occurred. Did the data get in? Boron tagging. Choose clear attack inputs that are easy to notice in output. In binary this is often 0xa5a5a5a5 (alternating 1s and 0s). Another obvious tag value is all zeroes, but it is not always obvious what goes wrong if the null values get into the data. env-All Check Log files. An attacker with access to log files can look at the outcome of bad input. env-Local env-Embedded Prevent access to log files that contain error output. Prevent access to and/or sanitize all error output. Abuse the system through filter failure An attacker writes a script to consistently induce the filter failure. DoS through filter failure. The attacker causes the system to crash or stay down because of its failure to filter properly. env-All Malicious code execution. An attacker introduces a malicious payload and executes arbitrary code on the target system. env-All An attacker can use the filter failure to introduce malicious data into the system and leverage a subsequent SQL injection, Cross Site Scripting, Command Injection or similar weakness if it exists. env-All Failure mode of the software (perhaps as a safety mechanism) includes exiting or ceasing to respond. env-All Failures do not involve stopping services, rejecting inputs or connections, and do not affect other simultaneous users of the software. env-All Attacker-supplied code is executed on the target system. The software stops responding for at least two orders of magnitude longer than the input takes to send. (e.g., 0.1s to send input induces at least a 10 second period non-responsiveness). Non-response by an attacker's input has an impact on the quality of service of other simultaneous users of the software. Monitor software response time regularly, and react to unexpected variations. Execute filtering modules with minimal privileges. Execute filtering modules in operating system "sandboxes" or similar containers. Ability to control the length of data passed to an active filter. High High Injection Attack Example: Filter Failure in Taylor UUCP Daemon Sending in arguments that are too long to cause the filter to fail open is one instantiation of the filter failure attack. The Taylor UUCP daemon is designed to remove hostile arguments before they can be executed. If the arguments are too long, however, the daemon fails to remove them. This leaves the door open for attack. A filter is used by a web application to filter out characters that may allow the input to jump from the data plane to the control plane when data is used in a SQL statement (chaining this attack with the SQL injection attack). Leveraging a buffer overflow the attacker makes the filter fail insecurely and the tainted data is permitted to enter unfiltered into the system, subsequently causing a SQL injection. Audit Truncation and Filters with Buffer Overflow. Sometimes very large transactions can be used to destroy a log file or cause partial logging failures. In this kind of attack, log processing code might be examining a transaction in real-time processing, but the oversized transaction causes a logic branch or an exception of some kind that is trapped. In other words, the transaction is still executed, but the logging or filtering mechanism still fails. This has two consequences, the first being that you can run transactions that are not logged in any way (or perhaps the log entry is completely corrupted). The second consequence is that you might slip through an active filter that otherwise would stop your attack. 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. 120 Targeted 119 Targeted 118 Targeted 74 Targeted 20 Targeted 100 Occasionally Follows 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 Medium High Medium All All All All C C++ G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Cigital, Inc 2007-03-01 Eugene Lebanidze Cigital, Inc 2007-02-26 Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" Sean Barnum Cigital, Inc 2007-03-05 Review and revise Paco Hope Cigital, Inc. 2007-10-20 Added extended Attack Execution Flow

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to her. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attacker's Symlink link. If the attacker can insert malicious content in the temporary file she will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

Verify that target host's platform supports symbolic links. This attack pattern is only applicable on platforms that support symbolic links. Research target platform to determine whether it supports symbolic links. env-Embedded env-Local Create a symbolic link and ensure that it works as expected on the given platform. env-Embedded env-Local Target platform supports symbolic links (e.g. Linux, UNIX, etc.) Target platform does not support symbolic links (e.g. MS Windows) Examine application's file I/O behavior Analyze the application's file I/O behavior to determine where it stores files, as well as the operations it performs to read/write files. Use kernel tracing utility such as ktrace to monitor application behavior env-Local Use debugging utility such as File Monitor to monitor the application's filesystem I/O calls env-Local Watch temporary directories to see when temporary files are created, modified and deleted. env-Embedded env-Local