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.
Attack Execution Flow
Explore
Obtain copy of cookie:
The attacker first needs to obtain a copy of the
cookie. The attacker may be a legitimate end user
wanting to escalate privilege, or could be somebody
sniffing on a network to get a copy of HTTP
cookies.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Obtain cookie from local filesystem (e.g.
C:\Documents and Settings\*\Cookies and
C:\Documents and Settings\*\Application
Data\Mozilla\Firefox\Profiles\*\cookies.txt in
Windows)
env-Web
2
Sniff cookie using a network sniffer such as
Wireshark
env-Web
3
Obtain cookie from local memory or
filesystem using a utility such as the Firefox
Cookie Manager or AnEC Cookie Editor.
env-Web
4
Steal cookie via a cross-site scripting
attack.
env-Web
5
Guess cookie contents if it contains
predictable information.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
Cookies used in web application.
env-Web
2
Negative
Cookies not used in web application.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
Cookie captured by
attacker.
2
Failure
Cookie cannot be captured by
attacker.
Security Controls
ID
type
Security Control Description
1
Preventative
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.).
Experiment
Obtain sensitive information from
cookie:
The attacker may be able to get sensitive
information from the cookie. The web application
developers may have assumed that cookies are not
accessible by end users, and thus, may have put
potentially sensitive information in them.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
If cookie shows any signs of being encoded
using a standard scheme such as base64, decode
it.
env-Web
2
Analyze the cookie's contents to determine
whether it contains any sensitive
information.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Negative
Cookie only contains a random session ID
(e.g. ASPSESSIONID, JSESSIONID, etc.)
env-Web
2
Positive
Cookie contains sensitive information (e.g.
"ACCTNO=0234234", or "DBIP=0xaf112a22" -- database
server's IP address).
env-Web
3
Inconclusive
Cookie's contents cannot be
deciphered.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
Cookie contains sensitive
information that developer did not intent the end
user to see.
2
Failure
Cookie does not contain any
sensitive information.
Security Controls
ID
type
Security Control Description
3
Preventative
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.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Modify logical parts of cookie and send it
back to server to observe the effects.
env-Web
2
Modify numeric parts of cookie
arithmetically and send it back to server to
observe the effects.
env-Web
3
Modify cookie bitwise and send it back to
server to observe the effects.
env-Web
4
Replace cookie with an older legitimate
cookie and send it back to server to observe the
effects. This technique would be helpful in cases
where the cookie contains a "points balance" for a
given user where the points have some value. The
user may spend his points and then replace his
cookie with an older one to restore his
balance.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
Subversion of security controls
on server
2
Failure
Cookie reset by
server
Security Controls
ID
type
Security Control Description
1
Detective
Web server logs
contain many messages indicating that invalid
cookies were received from
client.
2
Preventative
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.
Attack Prerequisites
Target server software must be a HTTP daemon that relies on
cookies.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Modification of Resources
API Abuse
Protocol Manipulation
Time and State
Examples-Instances
Description
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To overwrite session cookie data, and submit targeted attacks via
HTTP
High: Exploiting a remote buffer overflow generated by attack
Resources Required
Ability to send HTTP request containing cookie to server
Solutions and Mitigations
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.
Attack Motivation-Consequences
Information Leakage
Data Modification
Privilege Escalation
Injection Vector
HTTP cookie
Payload
Malicious input delivered through cookie in HTTP Request.
Activation Zone
Client software, such as a browser and its component libraries, or an
intermediary
Payload Activation Impact
1. Enables attacker to leverage state stored in cookie
2. Enables attacker a vector to attack web server and platform
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.
Attack Prerequisites
System must use weak authentication mechanisms for administrative
functions.
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
Injection
Protocol Manipulation
Examples-Instances
Description
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Resources Required
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
Solutions and Mitigations
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
Attack Motivation-Consequences
Denial of Service
Privilege Escalation
Injection Vector
Payload delivered through standard communication protocols.
Blind SQL Injection results from an insufficient mitigation for SQL
Injection. Although suppressing database error messages are considered best
practice, the suppression alone is not sufficient to prevent SQL Injection.
Blind SQL Injection is a form of SQL Injection that overcomes the lack of
error messages. Without the error messages that facilitate SQL Injection,
the attacker constructs input strings that probe the target through simple
Boolean SQL expressions. The attacker can determine if the syntax and
structure of the injection was successful based on whether the query was
executed or not. Applied iteratively, the attacker determines how and where
the target is vulnerable to SQL Injection.
For example, an attacker may try entering something like "username' AND
1=1; --" in an input field. If the result is the same as when the attacker
entered "username" in the field, then the attacker knows that the
application is vulnerable to SQL Injection. The attacker can then ask yes/no
questions from the database server to extract information from it. For
example, the attacker can extract table names from a database using the
following types of queries:
"username' AND ascii(lower(substring((SELECT TOP 1 name FROM
sysobjects WHERE xtype='U'), 1, 1))) > 108".
If the above query executes properly, then the attacker knows that the
first character in a table name in the database is a letter between m
and z. If it doesn't, then the attacker knows that the character must be
between a and l (assuming of course that table names only contain
alphabetic characters). By performing a binary search on all character
positions, the attacker can determine all table names in the database.
Subsequently, the attacker may execute an actual attack and send
something like:
"username'; DROP TABLE trades; --
Attack Execution Flow
Explore
Hypothesize SQL queries in
application:
Generated hypotheses regarding the SQL queries in
an application. For example, the attacker may
hypothesize that his input is passed directly into a
query that looks like:
"SELECT * FROM orders WHERE ordernum =
_____"
or
"SELECT * FROM orders WHERE ordernum IN
(_____)"
or
"SELECT * FROM orders WHERE ordernum in
(_____) ORDER BY _____"
Of course, there are many other
possibilities.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Research types of SQL queries and determine
which ones could be used at various places in an
application.
env-All
Determine how to inject information into
the queries:
Determine how to inject information into the
queries from the previous step such that the
injection does not impact their logic. For example,
the following are possible injections for those
queries:
"5' OR 1=1; --"
and
"5) OR 1=1; --"
and
"ordernum DESC; --"
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Add clauses to the SQL queries such that the
query logic does not change.
env-All
2
Add delays to the SQL queries in case server
does not provide clear error messages (e.g.
WAITFOR DELAY '0:0:10' in SQL Server or
BENCHMARK(1000000000,MD5(1) in MySQL). If these
can be injected into the queries, then the length
of time that the server takes to respond reveals
whether the query is injectable or not.
env-All
Outcomes
ID
type
Outcome Description
1
Success
At least one way to complete a
hypothesized SQL query that would violate the
application developer's
assumptions.
Experiment
Determine user-controllable input
susceptible to injection:
Determine the user-controllable input susceptible
to injection. For each user-controllable input that
the attacker suspects is vulnerable to SQL
injection, attempt to inject the values determined
in the previous step. If an error does not occur,
then the attacker knows that the SQL injection was
successful.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use web browser to inject input through text
fields or through HTTP GET parameters.
env-Web
2
Use a web application debugging tool such as
Tamper Data, TamperIE, WebScarab,etc. to modify
HTTP POST parameters, hidden fields, non-freeform
fields, etc.
env-Web
3
Use network-level packet injection tools
such as netcat to inject input
At least one user-controllable
input susceptible to injection
found.
2
Failure
No user-controllable input
susceptible to injection
found.
Security Controls
ID
type
Security Control Description
1
Detective
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.
2
Preventative
Input validation of
user-controlled data before including it in a SQL
query
3
Preventative
Use APIs that help
mitigate SQL injection (such as PreparedStatement
in Java)
Determine database
type:
Determines the type of the database, such as MS
SQL Server or Oracle or MySQL, using logical
conditions as part of the injected queries
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Try injecting a string containing
char(0x31)=char(0x31) (this evaluates to 1=1 in
SQL Server only)
Inject other database-specific commands into
input fields susceptible to SQL Injection. The
attacker can determine the type of database that
is running by checking whether the query executed
successfully or not (i.e. wheter the attacker
received a normal response from the server or
not).
Desired information about
database schema extracted.
2
Failure
Desired information about
database schema could not be
extracted.
Security Controls
ID
type
Security Control Description
1
Detective
Large number of
unusual queries in database
logs.
Exploit SQL Injection
vulnerability:
Use the information obtained in the previous steps
to successfully inject the database in order to
bypass checks or modify, add, retrieve or delete
data from the database
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use information about how to inject commands
into SQL queries as well as information about the
database schema to execute attacks such as
dropping tables, inserting records, etc.
Attacker achieves goal of
unauthorized system access, denial of service,
etc.
2
Failure
Attacker cannot exploit the
information gathered by blind SQL
Injection
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Analysis
Examples-Instances
Description
In the PHP application TimeSheet 1.1, an attacker can successfully
retrieve username and password hashes from the database using Blind SQL
Injection. If the attacker is aware of the local path structure, the
attacker can also remotely execute arbitrary code and write the output
of the injected queries to the local path. Blind SQL Injection is
possible since the application does not properly sanitize the
$_POST['username'] variable in the login.php file.
Related Vulnerabilities
CVE-2006-4705
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Medium
Determining the database type and version, as well as the right number
and type of parameters to the query being injected in the absence of
error messages requires greater skill than reverse-engineering database
error messages.
Resources Required
None
Probing Techniques
In order to determine the right syntax for the query to inject, the
attacker tries to determine the right number of parameters to the query and
their types. This is achieved by formulating conditions that result in a
true/false answer from the database. If the logical condition is true, the
database will execute the rest of the query. If not, a custom error page or
a default page is returned. Another approach is to ask such true/false
questions of the database and note the response times to a query with a
logically true condition and one with a false condition.
Indicators-Warnings of Attack
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.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Data Modification
Information Leakage
Run Arbitrary Code
Injection Vector
User-controllable input to the application
Payload
SQL statements intended to bypass checks or retrieve information about the
database
Activation Zone
Back-end database
Payload Activation Impact
The injected SQL statements are such that they result in a true/false query to
the database. If the database evaluates a statement to be logically true, it
responds with the requested data. If the condition is evaluated to be logically
false, an error is returned. The attacker modifies the boolean condition each
time to gain information from the database.
Custom error pages must be used to handle exceptions such that they do not
reveal any information about the architecture of the application or the
database.
Special characters in user-controllable input must be escaped before use
by the application.
Employ application-level safeguards to filter data and handle exceptions
gracefully.
Related Security Principles
Reluctance to Trust
Failing Securely
Defense in Depth
Related Guidelines
Never Use Input as Part of a Directive to any Internal Component
Handle All Errors Safely
Purposes
Penetration
CIA Impact
Confidentiality Impact: High
Integrity Impact: High
Availability Impact: High
Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
References
CWE - Input Validation
CWE - Improper Error Handling
Content History
Submissions
Submitter
Date
Comments
Chiradeep B Chhaya
2007-02-22
Third Draft - Revised to schema
v1.4
Modifications
Modifier
Organization
Date
Comments
Malik Hamro
Cigital, Inc
2007-02-27
Reformat to new schema and
review
Sean Barnum
Cigital, Inc
2007-03-05
Review and revise
Richard Struse
VOXEM, Inc
2007-03-26
Review and feedback leading to changes in Description,
Attack Prerequisites and Related Attack Patterns
Sean Barnum
Cigital, Inc
2007-04-13
Modified pattern content according to review and
feedback
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.
Attack Execution Flow
An attacker can call an API exposed by the target
host.
On the probing stage, the attacker injects
malicious code using the API call and observes the
results. The attacker's goal is to uncover a buffer
overflow vulnerability.
The attacker finds a buffer overflow
vulnerability, crafts malicious code and injects it
through an API call. The attacker can at worst
execute remote code on the target host.
Attack Prerequisites
The target host exposes an API to the user.
One or more API functions exposed by the target host has a buffer overflow
vulnerability.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
API Abuse
Injection
Examples-Instances
Description
A buffer overflow in the FreeBSD utility setlocale (found in the libc
module) puts many programs at risk all at once.
Description
A buffer overflow in the Xt library of the X windowing system allows
local users to execute commands with root privileges.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Denial of Service
Run Arbitrary Code
Information Leakage
Data Modification
Injection Vector
The user supplied data.
Payload
The buffer overrun by the attacker.
Activation Zone
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.
This attack targets command-line utilities available in a number of
shells. An attacker can leverage a vulnerability found in a command-line
utility to escalate privilege to root.
Attack Execution Flow
Attacker identifies command utilities exposed by
the target host.
On the probing stage, the attacker interacts with
the command utility and observes the results of its
input. The attacker's goal is to uncover a buffer
oveflow in the command utility. For instance the
attacker may find that input data are not properly
validated.
The attacker finds a buffer overflow vulnerability
in the command utility and tries to exploit it. He
crafts malicious code and injects it using the
command utility. The attacker can at worst execute
remote code on the target host.
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
API Abuse
Examples-Instances
Description
A buffer overflow in the HPUX passwd command allows local users to
gain root privileges via a command-line option.
A buffer overflow in Solaris's getopt command (found in libc)
allows local users to gain root privileges via a long
argv[0].
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Probing Techniques
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.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Privilege Escalation
Run Arbitrary Code
Data Modification
Denial of Service
Information Leakage
Injection Vector
The user supplied data.
Payload
The buffer overrun by the attacker.
Activation Zone
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.
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.
Attack Execution Flow
The attacker tries to find an environment variable
which can be overwritten for instance by gathering
information about the target host (error pages,
software's version number, etc.).
The attacker manipulates the environment variable
to contain excessive-length content to cause a
buffer overflow.
The attacker potentially leverages the buffer
overflow to inject maliciously crafted code in an
attempt to execute privileged command on the target
environment.
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Examples-Instances
Description
A buffer overflow in sccw allows local users to gain root access via
the $HOME environmental variable.
Related Vulnerabilities
CVE-1999-0906
Description
A buffer overflow in the rlogin program involves its consumption of
the TERM environmental variable.
Related Vulnerabilities
CVE-1999-0046
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Probing Techniques
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.
Indicators-Warnings of Attack
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.
Solutions and Mitigations
Do not expose environment variable to the user.
Do not use untrusted data in your environment variables.
Use a language or compiler that performs automatic bounds checking
There are tools such as Sharefuzz (http://sharefuzz.sourceforge.net/)
which is an environment variable fuzzer for Unixes that support loading a
shared library. You can use Sharefuzz to determine if you are exposing an
environment variable vulnerable to buffer overflow.
Attack Motivation-Consequences
Denial of Service
Run Arbitrary Code
Information Leakage
Data Modification
Privilege Escalation
Injection Vector
The user modifiable environment variable.
Payload
User supplied data potentially containing malicious code.
Activation Zone
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.
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.
Attack Execution Flow
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().
Attack Prerequisites
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).
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
Injection
Examples-Instances
Description
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.
Related Vulnerabilities
CVE-2001-0249
Description
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.
Related Vulnerabilities
CVE-2006-6652
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Resources Required
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.
Solutions and Mitigations
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
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.
Attack Execution Flow
The attacker creates or modifies a symbolic link
pointing to a resources (e.g., file, directory). The
content of the symbolic link file includes
out-of-bounds (e.g. excessive length) data.
The target host consumes the data pointed to by
the symbolic link file. The target host may either
intentionally expect to read a symbolic link or it
may be fooled by the replacement of the original
resource and read the attacker's symbolic
link.
While consuming the data, the target host does not
check for buffer boundary which can lead to a buffer
overflow. If the content of the data is controlled
by the attacker, this is an avenue for remote code
execution.
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Modification of Resources
Examples-Instances
Description
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Skill or Knowledge Level: 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.
Probing Techniques
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.
Indicators-Warnings of Attack
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.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Denial of Service
Run Arbitrary Code
Information Leakage
Data Modification
Injection Vector
The resource pointed to by the Symbolic link (e.g., file, directory,
etc.)
Payload
The buffer overrun by the attacker.
Activation Zone
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.
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.
Attack Prerequisites
The user must allow Javscript to execute in their browser
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Protocol Manipulation
Injection
Brute Force
Examples-Instances
Description
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).
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Medium
To land and launch a script on victim's machine with appropriate
footprinting logic for enumerating services and vulnerabilities in
Javascript
Solutions and Mitigations
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.
Attack Motivation-Consequences
Information Leakage
Injection Vector
Payload delivered through standard communication protocols, such as Ajax
application.
Payload
Command(s) executed directly on host
Activation Zone
Client machine and client network
Payload Activation Impact
Enables attacker to execute probes against client system.
This type of attack exploits a buffer overflow vulnerability in targeted
client software through injection of malicious content from a custom-built
hostile service.
Attack Execution Flow
The attacker creates a custom hostile
service
The attacker acquires information about the kind
of client attaching to her hostile service to
determine if it contains an exploitable buffer
overflow vulnerability.
The attacker intentionally feeds malicious data to
the client to exploit the buffer overflow
vulnerability that she has uncovered.
The attacker leverages the exploit to execute
arbitrary code or to cause a denial of
service.
Attack Prerequisites
The targeted client software communicates with an external server.
The targeted client software has a buffer oveflow vulnerability.
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
API Abuse
Injection
Examples-Instances
Description
Authors often use <EMBED> tags in HTML documents. For
example
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Probing Techniques
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.
Indicators-Warnings of Attack
An example of indicator is when the client software crashes after
executing code downloaded from a hostile server.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Denial of Service
Run Arbitrary Code
Payload
Attacker-supplied data potentially containing malicious code.
Activation Zone
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.
Payload Activation Impact
The most common are remote code execution or denial of service.
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.
Attack Execution Flow
Explore
Determine application's/system's password
policy:
Determine the password policies of the target
application/system.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Determine minimum and maximum allowed
password lengths.
env-All
2
Determine format of allowed passwords
(whether they are required or allowed to contain
numbers, special characters, etc., or whether they
are allowed to contain words from the
dictionary).
env-All
3
Determine account lockout policy (a strict
account lockout policy will prevent brute force
attacks).
env-All
Indicators
ID
type
Indicator Description
Environments
1
Positive
Passwords are used in the
application/system
env-All
2
Negative
Passwords are not used in the
application/system.
env-All
Select dictionaries:
Pick the dictionaries to be used in the attack
(e.g. different languages, specific terminology,
etc.)
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Select dictionary based on particular users'
preferred languages.
env-All
2
Select dictionary based on the
application/system's supported languages.
env-All
Determine username(s) to
target:
Determine username(s) whose passwords to
crack.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Obtain username(s) by sniffing network
packets.
env-CommProtocol env-Peer2Peer
env-ClientServer
2
Obtain username(s) by querying
application/system (e.g. if upon a failed login
attempt, the system indicates whether the entered
username was valid or not)
env-All
3
Obtain usernames from filesystem (e.g. list
of directories in C:\Documents and Settings\ in
Windows, and list in /etc/passwd in UNIX-like
systems)
env-Embedded env-Local
Indicators
ID
type
Indicator Description
Environments
1
Negative
Remote application or system provides no
indication regarding whether a given username is
valid or not.
Presence of any valid usernames
could not be established.
Security Controls
ID
type
Security Control Description
1
Preventative
Do not reveal
information regarding validity of particular
usernames to users.
2
Corrective
Lock out accounts
whose usernames are suspected to have been
compromised.
Exploit
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.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Try all words in the dictionary, as well as
common misspellings of the words as passwords for
the chosen username(s).
env-All
2
Try common combinations of words in the
dictionary, as well as common misspellings of the
combinations as passwords for the chosen
username(s).
env-All
Indicators
ID
type
Indicator Description
Environments
1
Negative
Application/system does not use password
authentication.
env-All
Outcomes
ID
type
Outcome Description
1
Success
Attacker determines correct
password for a user ID and obtains access to
application or system.
2
Failure
Attacker is unable to determine
correct password for a user ID and obtain access
to application or system.
Security Controls
ID
type
Security Control Description
1
Detective
Large number of
authentication failures in
logs.
2
Preventative
Enforce strict account
lockout policies.
3
Preventative
Enforce strong
passwords (having sufficient length and containing
mix of lower case and upper case letters, numbers,
and special
characters)
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
Brute Force
Examples-Instances
Description
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.
Description
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.
Related Vulnerabilities
CVE-2003-1096
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
A variety of password cracking tools and dictionaries are available to
launch this type of an attack.
Resources Required
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.
Indicators-Warnings of 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.
Obfuscation Techniques
Employ IP spoofing to make it seem like login attempts are coming from
different machines.
Solutions and Mitigations
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.
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).
Attack Execution Flow
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.
Attack Prerequisites
The program does not properly handle postfix NULL terminators
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Modification of Resources
API Abuse
Examples-Instances
Description
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
Description
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].
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.
Attack Execution Flow
Explore
Spider:
Using a browser or an automated tool, an attacker
follows all public links on a web site. He records
all the entry points (input) that becomes part of
generated HTTP header (not only GET/POST/COOKIE, but
also Content-Type, etc.)
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a spidering tool to follow and record
all links and analyze the web pages to find entry
points. Make special note of any links that
include parameters used in the HTTP
headers.
env-Web
2
Look for HTML meta tags that could be
injectable
env-Web
3
Use a proxy tool to record all links visited
during a manual traversal of the web
application.
env-Web
4
Use a browser to manually explore the
website and analyze how it is constructed. Many
browsers' plugins are available to facilitate the
analysis or automate the discovery.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
Web content is generated by the application
and served to the browser based on
user-controllable inputs.
env-Web
2
Positive
HTTP header variables are used by the
application or the browser (DOM)
env-Web
3
Inconclusive
No HTTP variables appear to be used on the
current page. Even though none appear, the web
application may still use them if they are
provided.
env-Web
4
Negative
Applications that have only static pages or
that simply present information without accepting
input are unlikely to be susceptible.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
A list of URLs, with their
corresponding HTTP variables is created by the
attacker.
Security Controls
ID
type
Security Control Description
1
Detective
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).
2
Detective
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.
3
Preventative
Use CAPTCHA to prevent
the use of the application by an automated
tool.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be
automated.
Experiment
Probe identified potential entry points
for XSS vulnerability:
The attacker uses the entry points gathered in the
"Explore" phase as a target list and injects various
common script payloads to determine if an entry
point actually represents a vulnerability and to
characterize the extent to which the vulnerability
can be exploited. He records all the responses from
the server that include unmodified versions of his
script.
The attacker tries also to inject extra-parameter
to the HTTP request to see if they are reflected
back in the web page or in the HTTP response.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Manually inject various script payloads into
each identified entry point using a list of common
script injection probes and observe system
behavior to determine if script was
executed.
env-Web
2
Use an automated injection attack tool to
inject various script payloads into each
identified entry point using a list of common
script injection probes and observe system
behavior to determine if script was
executed.
env-Web
3
Use a proxy tool to record results of manual
input of XSS probes in known URLs.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
User-controllable input is embedded as part
of generated HTTP headers
env-Web
2
Positive
Input parameters become part of the web page
(even in meta tags)
env-Web
3
Positive
Output to the browser is not encoded to
remove executable scripting syntax.
env-Web
4
Inconclusive
Nothing is returned to the web page. It may
be a stored XSS. The unique identifier from the
probe helps to trace the flow of the possible
XSS.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker's cross-site
scripting string is repeated back verbatim at some
point in the web site (if not on the same page).
Note that sometimes, the payload might be well
encoded in the page, but wouldn't be encoded at
all in some other section of the same web page
(title, script, etc.)
2
Failure
All HTML-sensitive characters
are consistently re-encoded before being sent to
the web browser.
3
Inconclusive
Some sensitive characters are
consistently encoded, but others are
not.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor input to web
servers (not only GET, but all in the inputs),
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.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Do not embed
user-controllable input generated HTTP
headers
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
As the attacker succeeds in exploiting the
vulnerability, he can choose to steal user's
credentials in order to reuse or to analyze them
later on.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and sends document information to the
attacker.
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute
appropriately.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the user's
cookies or other session
identifiers.
2
Success
The attacker gets the content
of the page the user is
viewing.
3
Success
The attacker causes the user's
browser to visit a page with malicious
content.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Forceful browsing:
When the attacker targets the current application
or another one (through CSRF vulnerabilities), the
user will then be the one who perform the attacks
without being aware of it. These attacks are mostly
targeting application logic flaws, but it can also
be used to create a widespread attack against a
particular website on the user's current network
(Internet or not).
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and performs actions on the same web
site
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute request to
other web sites (especially the web applications
that have CSRF vulnerabilities).
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker indirectly
controls the user's browser and makes it
performing actions exploiting
CSRF.
2
Success
The attacker manipulates the
browser through the steps that he designed in his
attack. The user, identified on a website, is now
performing actions he is not aware
of.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Content spoofing:
By manipulating the content, the attacker targets
the information that the user would like to get from
the website.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and exposes attacker-modified invalid
information to the user on the current web
page.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The user sees a page containing
wrong information
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Attack Prerequisites
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.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Modification of Resources
Protocol Manipulation
Examples-Instances
Description
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.
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
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To achieve a redirection and use of less trusted source, an attacker
can simply edit HTTP Headers that are sent to client machine.
Skill or Knowledge Level: High
Exploiting a client side vulnerability to inject malicious scripts
into the browser's executable process.
Resources Required
Ability to deploy a custom hostile service for access by targeted clients.
Ability to communicate synchronously or asynchronously with client
machine
Solutions and Mitigations
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.
Attack Motivation-Consequences
Run Arbitrary Code
Information Leakage
Privilege Escalation
Injection Vector
Malicious input delivered through HTTP Headers.
Payload
Varies with instantiation of attack pattern. In the case of HTTP headers they
may not be visible to the end user via a browser
Activation Zone
Header processing on the server or Client browser
Payload Activation Impact
Enables attacker to execute scripts to launch attacks on server as well as
remote client machine and environment
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
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.
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.
Attack Execution Flow
Explore
Spider:
Using a browser or an automated tool, an attacker
follows all public links on a web site. He records
all the links he finds.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a spidering tool to follow and record
all links. Make special note of any links that
include parameters in the URL.
env-Web
2
Use 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-Web
3
Use a browser to manually explore the
website and analyze how it is constructed. Many
browser's plugins are available to facilitate the
analysis or automate the URL discovery.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
URL parameters are used by the application
or the browser (DOM)
env-Web
2
Inconclusive
Using URL rewriting, parameters may be part
of the URL path.
env-Web
3
Inconclusive
No parameters appear on the URL. Even though
none appear, the web application may still use
them if they are provided.
env-Web
4
Inconclusive
Application could use POST variable as GET
inside the application. Therefore, looking for
POST parameters and adding them to the query
string.
env-Web
5
Negative
Applications that have only static pages or
that simply present information without accepting
input are unlikely to be susceptible.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
A list of URLs, with their
corresponding parameters is created by the
attacker.
Security Controls
ID
type
Security Control Description
1
Detective
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).
2
Detective
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.
3
Preventative
Use CAPTCHA to prevent
the use of the application by an automated
tool.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be
automated.
Experiment
Attempt variations on input
parameters:
Possibly using an automated tool, an attacker
requests variations on the URLs he spidered before.
He sends parameters that include variations of
payloads. He records all the responses from the
server that include unmodified versions of his
script.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a list of XSS probe strings to inject in
parameters of known URLs. If possible, the probe
strings contain a unique identifier.
env-Web
2
Use a proxy tool to record results of manual
input of XSS probes in known URLs.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
The 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-Web
2
Positive
Input parameters become part of JavaScript,
VBScript, or other script in a web page.
env-Web
3
Inconclusive
Nothing is returned to the web page. It may
be a stored XSS. The unique identifier from the
probe helps to trace the flow of the possible
XSS.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker's cross-site
scripting string is repeated back verbatim at some
point in the web site (if not on the same page).
Note that sometimes, the payload might be well
encoded in the page, but wouldn't be encoded at
all in some other section of the same web page
(title, script, etc.)
2
Failure
All HTML-sensitive characters
are consistently re-encoded before being sent to
the web browser.
3
Inconclusive
Some sensitive characters are
consistently encoded, but others are
not.
Security Controls
ID
type
Security Control Description
1
Detective
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.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Do not embed
user-controllable input generated HTTP
headers
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
As the attacker succeeds in exploiting the
vulnerability, he can choose to steal user's
credentials in order to reuse or to analyze them
later on.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and sends document information to the
attacker.
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute
appropriately.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the user's
cookies or other session
identifiers.
2
Success
The attacker gets the content
of the page the user is
viewing.
3
Success
The attacker causes the user's
browser to visit a page with malicious
content.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Forceful browsing:
When the attacker targets the current application
or another one (through CSRF vulnerabilities), the
user will then be the one who perform the attacks
without being aware of it. These attacks are mostly
targeting application logic flaws, but it can also
be used to create a widespread attack against a
particular website on the user's current network
(Internet or not).
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and performs actions on the same web
site
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute request to
other web sites (especially the web applications
that have CSRF vulnerabilities).
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker indirectly
controls the user's browser and makes it
performing actions exploiting
CSRF.
2
Success
The attacker manipulates the
browser through the steps that he designed in his
attack. The user, identified on a website, is now
performing actions he is not aware
of.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Content spoofing:
By manipulating the content, the attacker targets
the information that the user would like to get from
the website.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and exposes attacker-modified invalid
information to the user on the current web
page.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The user sees a page containing
wrong information
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
1
Detective
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
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Attack Prerequisites
Target client software must allow scripting such as Javascript. Server
software must allow display of remote generated HTML without sufficient
input or output validation.
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To place malicious payload on server via HTTP
Skill or Knowledge Level: High
Exploiting any information gathered by HTTP Query on script
host
Resources Required
Ability to send HTTP post to scripting host and collect output
Solutions and Mitigations
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
Attack Motivation-Consequences
Information Leakage
Run Arbitrary Code
Injection Vector
Script delivered through standard web server, such as a web server with
user-generated content.
Payload
HTTP Request Query String
Activation Zone
Client web browser where script is executed
Payload Activation Impact
Client web browser may be used to steal session data, passwords, cookies, and
other tokens.
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).
Attack Execution Flow
Explore
Survey:
The attacker surveys the target application,
possibly as a valid and authenticated user
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Spidering web sites for inputs that involve
potential filtering
env-Web
2
Brute force guessing of filtered
inputs
env-All
Indicators
ID
type
Indicator Description
Environments
1
Positive
Software messages (e.g., "the following
characters are not allowed...") indicate that
filtered inputs are present in the software.
(
Java code is likely, based on standard
disclaimers (e.g., "This software contains Java
from Sun...."). Such declarations are frequent on
commercial software that is based on Java.
env-Embedded env-Local
env-ClientServer
6
Inconclusive
Java code is likely, based on one of the
other indicators, but it could contain Java Native
Interface (JNI) code. This is indicated by the
inclusion of DLLs or equivalent binary object code
with Java code.
env-Embedded env-Local
env-ClientServer
Experiment
Attempt injections:
Try to feed overly long data to the system. This
can be done manually or a dynamic tool (black box)
can be used to automate this. An attacker can also
use a custom script for that purpose.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Brute force attack through black box
penetration test tool.
Manual testing of possible inputs with
attack data.
env-All
Outcomes
ID
type
Outcome Description
1
Success
Unexpected output from the
application.
2
Failure
No unexpected output from the
application.
Security Controls
ID
type
Security Control Description
1
Detective
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.
2
Corrective
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?
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Boron tagging. Choose clear attack inputs
that are easy to notice in output. In binary this
is often 0xa5a5a5a5 (alternating 1s and 0s).
Another obvious tag value is all zeroes, but it is
not always obvious what goes wrong if the null
values get into the data.
env-All
2
Check Log files. An attacker with access to
log files can look at the outcome of bad
input.
env-Local env-Embedded
Security Controls
ID
type
Security Control Description
1
Preventative
Prevent access to log
files that contain error
output.
2
Preventative
Prevent access to
and/or sanitize all error
output.
Exploit
Abuse the system through filter
failure:
An attacker writes a script to consistently induce
the filter failure.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
DoS through filter failure. The attacker
causes the system to crash or stay down because of
its failure to filter properly.
env-All
2
Malicious code execution. An attacker
introduces a malicious payload and executes
arbitrary code on the target system.
env-All
3
An attacker can use the filter failure to
introduce malicious data into the system and
leverage a subsequent SQL injection, Cross Site
Scripting, Command Injection or similar weakness
if it exists.
env-All
Indicators
ID
type
Indicator Description
Environments
1
Positive
Failure mode of the software (perhaps as a
safety mechanism) includes exiting or ceasing to
respond.
env-All
2
Negative
Failures do not involve stopping services,
rejecting inputs or connections, and do not affect
other simultaneous users of the software.
env-All
Outcomes
ID
type
Outcome Description
1
Success
Attacker-supplied code is
executed on the target
system.
2
Success
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).
3
Success
Non-response by an attacker's
input has an impact on the quality of service of
other simultaneous users of the
software.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor software
response time regularly, and react to unexpected
variations.
2
Preventative
Execute filtering
modules with minimal
privileges.
3
Preventative
Execute filtering
modules in operating system "sandboxes" or similar
containers.
Attack Prerequisites
Ability to control the length of data passed to an active filter.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
Examples-Instances
Description
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.
Description
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.
Description
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: 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.
Probing Techniques
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.
Indicators-Warnings of Attack
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.
Obfuscation Techniques
An attacker may temporally space out their probes.
An attacker may perform probes from different IP addresses.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Run Arbitrary Code
Privilege Escalation
Denial of Service
Injection Vector
Web form, URL, File, Command line, Network socket, etc.
Payload
All of the data that just got into the system unfiltered becomes the
payload.
Activation Zone
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.
Payload Activation Impact
Since no input validation is effectively performed in this situation, the
impact of the attack may be a complete compromise of confidentiality, integrity,
accountability and availability services.
Input validation and filtering logic should fail securely (vault doors are
closed)
Related Security Principles
Failing Securely
Related Guidelines
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.
Purposes
Penetration
CIA Impact
Confidentiality Impact: Medium
Integrity Impact: High
Availability Impact: Medium
Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
C
C++
References
G. Hoglund and G. McGraw.
"Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
CWE - Buffer Errors
Content History
Submissions
Submitter
Organization
Date
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code.
Addison-Wesley, February 2004.
Cigital, Inc
2007-03-01
Modifications
Modifier
Organization
Date
Comments
Eugene Lebanidze
Cigital, Inc
2007-02-26
Fleshed out content to CAPEC schema from the original
descriptions in "Exploiting Software"
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.
Attack Execution Flow
Explore
Identify HTTP parsing
chain:
Determine the technologies used in the target
environment such as types of web servers,
application firewalls, proxies, etc.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Investigation of the target environment to
determine the types of technologies used to parse
the incoming HTTP requests. Attempt to understand
the parsing chain traversed by the incoming HTTP
request.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
Full HTTP parsing chain for the
application has been
identified
Experiment
Probe for vulnerable differences in HTTP
parsing chain:
Attacker sends malformed HTTP Requests to the
application looking for differences in the ways that
individual layers in the parsing chain parse
requests. When differences are identified, the
attacker crafts specially malformed HTTP requests to
determine if the identified parsing differences will
allow extra requests to be smuggled through parsing
layers.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Create many consecutive requests to the
server. Some of which must be malformed.
env-Web
2
Use a proxy tool to record the HTTP
responses headers.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
At some point, the server is waiting for
more request information to send the last
response.
env-Web
2
Inconclusive
No response is being received.
env-Web
3
Negative
Malformed HTTP requests are being totally
ignored.
env-Web
4
Negative
Responses are being sent even if the HTTP
header is incomplete.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
One layer in the application's
HTTP parsing chain processes HTTP Requests that
other layers do not. The server smuggles the user
request into the last attacker's request and
transport data such as cookie,
etc.
2
Failure
The server replies with an
error to the last attacker's
request.
3
Inconclusive
No response for the last
incomplete request from the attacker by the
server
Security Controls
ID
type
Security Control Description
1
Detective
Monitor requests to
the server that seem
malformed.
Exploit
Cache poisoning:
The attacker decides to target the cache server.
The server will then cache the request and serve a
wrong page to a legitimate user's request. The
malicious request will most likely exploit a
Cross-Site Scripting or another injection typed
vulnerability.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Leverage the vulnerabilities identified in
the Experiment Phase to inject malicious HTTP
request that contains HTTP Request syntax that
will be processed and acted on by the outer
parsing layer of the cache server but not by the
inner application layer. In this way it will be
cached by the server without obvious sign from the
application and the corrupt data will be served to
future requesters.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the users to
be served with this cached malicious HTTP
request.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for consecutive suspicious HTTP
requests.
Session Hijacking:
The attacker decides to target the web server by
crafting a malicious HTTP Request containing a
second HTTP Request using syntax that will not be
processed and acted on by an outer "filter" parsing
layer but will be acted on by the inner web
server/application processing layers. The
application/web server will then act on the
malicious HTTP Request as if it is a valid request
from the client potentially subverting session
management.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Leverage the vulnerabilities identified in
the Experiment Phase to inject malicious HTTP
request that contains HTTP Request syntax that
will not be processed and acted on by the outer
parsing layer of the malicious content filters but
will be by the inner application/web server layer.
In this way it will be acted on by the
application/web server as if it is a valid request
from the client.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the
application/web server to act on the malicious
HTTP request and allows the attacker to gain
control of the target user's
session.
Security Controls
ID
type
Security Control Description
1
Preventative
Monitor server logs
for consecutive suspicious HTTP
requests.
Attack Prerequisites
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 server
Differences in the way the two HTTP entities parse HTTP requests
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
Protocol Manipulation
Injection
Examples-Instances
Description
When 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.
Related Vulnerabilities
CVE-2006-6276
Description
Apache 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".
Related Vulnerabilities
CVE-2005-2088
Attacker Skills or Knowledge Required
Skill or Knowledge Level: High
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.
Resources Required
None
Probing Techniques
If 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.
Indicators-Warnings of Attack
Differences in requests processed by the two entities. This requires
careful monitoring or a capable log analysis tool.
Solutions and Mitigations
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.
Attack Motivation-Consequences
Run Arbitrary Code
Privilege Escalation
Data Modification
Injection Vector
HTTP requests that are interpreted and parsed differently by the targeted
entities.
Payload
HTTP request to be smuggled through the first entity to the second one.
Activation Zone
The application server behind another HTTP entity
Payload Activation Impact
The 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
Scripting
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:
Attack Execution Flow
Explore
Spider:
Using a browser or an automated tool, an attacker
follows all public links on a web site. He records
all the links, the forms and all potential
user-controllable input points for the web
application.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a spidering tool to follow and record
all links and analyze the web pages to find entry
points. Make special note of any links that
include parameters in the URL, forms found in the
pages (like file upload, etc.).
env-Web
2
Use a proxy tool to record all links visited
during a manual traversal of the web
application.
env-Web
3
Use a browser to manually explore the
website and analyze how it is constructed. Many
browsers' plugins are available to facilitate the
analysis or automate the discovery.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
Inputs are transported through HTTP
env-Web
2
Positive
The application uses redirection techniques
(HTTP Location, etc.)
env-Web
3
Inconclusive
Using URL rewriting, parameters may be part
of the URL path.
env-Web
4
Inconclusive
No parameters appear to be used on the
current page. Even though none appear, the web
application may still use them if they are
provided.
env-Web
5
Negative
Applications that have only static pages or
that simply present information without accepting
input are unlikely to be susceptible.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
A list of user-controllable
input entry points is created by the
attacker.
Security Controls
ID
type
Security Control Description
1
Detective
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).
2
Detective
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.
3
Preventative
Use CAPTCHA to prevent
the use of the application by an automated
tool.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be
automated.
Experiment
Attempt variations on input
parameters:
The attacker injects the entry points identified
in the Explore Phase with response splitting syntax
and variations of payloads to be acted on in the
additional response. He records all the responses
from the server that include unmodified versions of
his payload.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use CR\LF characters (encoded or not) in the
payloads in order to see if the HTTP header can be
split.
env-Web
2
Use a proxy tool to record the HTTP
responses headers.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
The web server uses unvalidated
user-controlled input as part of the response
headers
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The CR\LF characters are passed
in the HTTP header and two responses are generated
for a single request.
2
Failure
All CR\LF characters are
consistently re-encoded or stripped before being
written in the HTTP header
3
Inconclusive
The size of the payload is
being limited by the server-side
application.
4
Inconclusive
Some sensitive characters are
consistently encoded, but others are
not.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor input to web
servers (not only GET, but all in the inputs),
application servers, and other HTTP infrastructure
(e.g., load balancers). Alert on CR\LF
characters.
2
Preventative
Do not use
user-controllable inputs in HTTP
headers
3
Preventative
Filter CR/LF syntax
out of any user-controllable input utilized in
HTTP headers.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating HTTP
Response Splitting
attacks.
Exploit
Cross-Site Scripting:
As the attacker succeeds in exploiting the
vulnerability, he can choose to attack the user with
Cross-Site Scripting. The possible outcomes of such
an attack are described in the Cross-Site Scripting
related attack patterns.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Inject cross-site scripting payload preceded
by response splitting syntax (CR/LF) into
user-controllable input identified as vulnerable
in the Experiment Phase.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The malicious script is
executed within the user's
context.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for consecutive suspicious HTTP
request
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
Cache poisoning:
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
The attacker decides to target the cache
server by forging new responses. The server will
then cache the second request and response. The
cached response has most likely an attack vector
like Cross-Site Scripting; this attack will then
be serve to many clients due to the caching
system.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
System performs caching of HTTP
responses
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the users to
be served with this cached malicious HTTP
response.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for consecutive suspicious HTTP
requests.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
Attack Prerequisites
User-controlled input used as part of HTTP header
Ability of attacker to inject custom strings in HTTP header
Insufficient input validation in application to check for input sanity
before using it as part of response header
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack
Injection
Protocol Manipulation
Examples-Instances
Description
In 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.
Related Vulnerabilities
CVE-2006-0207
Attacker Skills or Knowledge Required
Skill or Knowledge Level: High
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.
Resources Required
None
Probing Techniques
With 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 tools
If 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.
Indicators-Warnings of Attack
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
client
Solutions and Mitigations
To 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.
Attack Motivation-Consequences
Run Arbitrary Code
Privilege Escalation
Injection Vector
User-controllable input that forms part of output HTTP response headers
Payload
Encoded 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.
Activation Zone
API calls in the application that set output response headers.
Payload Activation Impact
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.
View Data
