1BO4r2U
1BO4r2U
1BO4r2U
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
147 148<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
• The Samba trans2open stack overflow vulnerability - http://www.<br />
securityfocus.com/archive/1/317615<br />
• Windows RPC DCOM vulnerability details - http://www.xfocus.<br />
org/documents/200307/2.html<br />
Testing for Format String<br />
Summary<br />
This section describes how to test for format string attacks that can<br />
be used to crash a program or to execute harmful code. The problem<br />
stems from the use of unfiltered user input as the format string<br />
parameter in certain C functions that perform formatting, such as<br />
printf().<br />
Various C-Style languages provision formatting of output by means<br />
of functions like printf( ), fprintf( ) etc. Formatting is governed by a parameter<br />
to these functions termed as format type specifier, typically<br />
%s, %c etc. The vulnerability arises when format functions are called<br />
with inadequate parameters validation and user controlled data.<br />
A simple example would be printf(argv[1]). In this case the type specifier<br />
has not been explicitly declared, allowing a user to pass characters<br />
such as %s, %n, %x to the application by means of command line<br />
argument argv[1].<br />
This situation tends to become precarious since a user who can supply<br />
format specifiers can perform the following malicious actions:<br />
Enumerate Process Stack: This allows an adversary to view stack<br />
organization of the vulnerable process by supplying format strings,<br />
such as %x or %p, which can lead to leakage of sensitive information.<br />
It can also be used to extract canary values when the application is<br />
protected with a stack protection mechanism. Coupled with a stack<br />
overflow, this information can be used to bypass the stack protector.<br />
Control Execution Flow: This vulnerability can also facilitate arbitrary<br />
code execution since it allows writing 4 bytes of data to an address<br />
supplied by the adversary. The specifier %n comes handy for overwriting<br />
various function pointers in memory with address of the malicious<br />
payload. When these overwritten function pointers get called,<br />
execution passes to the malicious code.<br />
Denial of Service: If the adversary is not in a position to supply malicious<br />
code for execution, the vulnerable application can be crashed<br />
by supplying a sequence of %x followed by %n.<br />
How to Test<br />
Black Box testing<br />
The key to testing format string vulnerabilities is supplying format<br />
type specifiers in application input.<br />
For example, consider an application that processes the URL<br />
string http://xyzhost.com/html/en/index.htm or accepts inputs<br />
from forms. If a format string vulnerability exists in one of the<br />
routines processing this information, supplying a URL like http://<br />
xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of<br />
the form fields might crash the application creating a core dump<br />
in the hosting folder.<br />
Format string vulnerabilities manifest mainly in web servers, application<br />
servers, or web applications utilizing C/C++ based code or<br />
CGI scripts written in C. In most of these cases, an error reporting<br />
or logging function like syslog( ) has been called insecurely.<br />
When testing CGI scripts for format string vulnerabilities, the<br />
input parameters can be manipulated to include %x or %n type<br />
specifiers. For example a legitimate request like<br />
http:/hostname/cgi-bin/query.cgi?name=john&code=45765<br />
can be altered to<br />
http:/hostname/cgi-bin/query.cgi?name=john%x.%x.%x-<br />
&code=45765%x.%x<br />
If a format string vulnerability exists in the routine processing<br />
this request, the tester will be able to see stack data being printed<br />
out to browser.<br />
If code is unavailable, the process of reviewing assembly fragments<br />
(also known as reverse engineering binaries) would yield<br />
substantial information about format string bugs.<br />
Take the instance of code (1) :<br />
int main(int argc, char **argv)<br />
{<br />
printf(“The string entered is\n”);<br />
printf(“%s”,argv[1]);<br />
return 0;<br />
}<br />
when the disassembly is examined using IDA Pro, the address of<br />
a format type specifier being pushed on the stack is clearly visible<br />
before a call to printf is made.<br />
On the other hand, when the same code is compiled without “%s”<br />
as an argument , the variation in assembly is apparent. As seen<br />
below, there is no offset being pushed on the stack before calling<br />
printf.<br />
Gray Box testing<br />
While performing code reviews, nearly all format string vulnerabilities<br />
can be detected by use of static code analysis tools. Subjecting<br />
the code shown in (1) to ITS4, which is a static code analysis tool,<br />
gives the following output.<br />
The functions that are primarily responsible for format string vulnerabilities<br />
are ones that treat format specifiers as optional. Therefore<br />
when manually reviewing code, emphasis can be given to functions<br />
such as:<br />
printf<br />
fprintf<br />
sprintf<br />
snprintf<br />
vfprintf<br />
vprintf<br />
vsprintf<br />
vsnprintf<br />
There can be several formatting functions that are specific to the<br />
development platform. These should also be reviewed for absence<br />
of format strings once their argument usage has been understood.<br />
Tools<br />
• ITS4: “A static code analysis tool for identifying format string vulnerabilities<br />
using source code” - http://www.cigital.com/its4<br />
• An exploit string builder for format bugs - http://seclists.org/lists/<br />
pen-test/2001/Aug/0014.html<br />
References<br />
Whitepapers<br />
• Format functions manual page - http://www.die.net/doc/linux/<br />
man/man3/fprintf.3.html<br />
• Tim Newsham: “A paper on format string attacks” - http://comsec.<br />
theclerk.com/CISSP/FormatString.pdf<br />
• Team Teso: “Exploiting Format String Vulnerabilities” - http://www.<br />
cs.ucsb.edu/~jzhou/security/formats-teso.html<br />
• Analysis of format string bugs - http://julianor.tripod.com/formatbug-analysis.pdf<br />
Testing for Incubated Vulnerability<br />
(OTG-INPVAL-015)<br />
Summary<br />
Also often refered to as persistent attacks, incubated testing is a<br />
complex testing method that needs more than one data validation<br />
vulnerability to work. Incubated vulnerabilities are typically used to<br />
conduct “watering hole” attacks against users of legitimate web applications.<br />
Incubated vulnerabilities have the following characteristics:<br />
• The attack vector needs to be persisted in the first place, it needs to<br />
be stored in the persistence layer, and this would only occur if weak<br />
data validation was present or the data arrived into the system via<br />
another channel such as an admin console or directly via a backend<br />
batch process.<br />
• Secondly, once the attack vector was “recalled” the vector would<br />
need to be executed successfully. For example, an incubated XSS<br />
attack would require weak output validation so the script would be<br />
delivered to the client in its executable form.<br />
Exploitation of some vulnerabilities, or even functional features of<br />
a web application, will allow an attacker to plant a piece of data that<br />
will later be retrieved by an unsuspecting user or other component of<br />
the system, exploiting some vulnerability there.<br />
In a penetration test, incubated attacks can be used to assess the<br />
criticality of certain bugs, using the particular security issue found<br />
to build a client-side based attack that usually will be used to target<br />
a large number of victims at the same time (i.e. all users browsing<br />
the site).<br />
This type of asynchronous attack covers a great spectrum of attack<br />
vectors, among them the following:<br />
• File upload components in a web application, allowing the attacker<br />
to upload corrupted media files (jpg images exploiting CVE-2004-<br />
0200, png images exploiting CVE-2004-0597, executable files, site<br />
pages with active component, etc.)<br />
• Cross-site scripting issues in public forums posts (see Testing for<br />
Stored Cross_site scripting (OTG-INPVAL-002) for additional<br />
details). An attacker could potentially store malicious scripts or<br />
code in a repository in the backend of the web-application (e.g.,<br />
a database) so that this script/code gets executed by one of the<br />
users (end users, administrators, etc). The archetypical incubated<br />
attack is exemplified by using a cross-site scripting vulnerability in a<br />
user forum, bulletin board, or blog in order to inject some JavaScript<br />
code at the vulnerable page, and will be eventually rendered and<br />
executed at the site user’s browser --using the trust level of the<br />
original (vulnerable) site at the user’s browser.<br />
• SQL/XPATH Injection allowing the attacker to upload content to a<br />
database, which will be later retrieved as part of the active content