1BO4r2U
1BO4r2U
1BO4r2U
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
145 146<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
• Metasploit, A rapid exploit development and Testing frame<br />
work - http://www.metasploit.com<br />
References<br />
Whitepapers<br />
• w00w00: “Heap Overflow Tutorial” - http://www.cgsecurity.<br />
org/exploit/heaptut.txt<br />
• David Litchfield: “Windows Heap Overflows” - http://www.<br />
blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/<br />
bh-win-04-litchfield.ppt<br />
Testing for Stack Overflow<br />
Summary<br />
Stack overflows occur when variable size data is copied into fixed<br />
length buffers located on the program stack without any bounds<br />
checking. Vulnerabilities of this class are generally considered to<br />
be of high severity since their exploitation would mostly permit<br />
arbitrary code execution or Denial of Service. Rarely found in interpreted<br />
platforms, code written in C and similar languages is<br />
often ridden with instances of this vulnerability. In fact almost<br />
every platform is vulnerable to stack overflows with the following<br />
notable exceptions:<br />
• J2EE – as long as native methods or system calls are not<br />
invoked<br />
• .NET – as long as /unsafe or unmanaged code is not invoked<br />
(such as the use of P/Invoke or COM Interop)<br />
• PHP – as long as external programs and vulnerable PHP<br />
extensions written in C or C++ are not called can suffer from<br />
stack overflow issues.<br />
Stack overflow vulnerabilities often allow an attacker to directly<br />
take control of the instruction pointer and, therefore, alter the<br />
execution of the program and execute arbitrary code. Besides<br />
overwriting the instruction pointer, similar results can also be<br />
obtained by overwriting other variables and structures, like Exception<br />
Handlers, which are located on the stack.<br />
How to Test<br />
Black Box testing<br />
The key to testing an application for stack overflow vulnerabilities<br />
is supplying overly large input data as compared to what is<br />
expected. However, subjecting the application to arbitrarily large<br />
data is not sufficient. It becomes necessary to inspect the application’s<br />
execution flow and responses to ascertain whether an<br />
overflow has actually been triggered or not. Therefore, the steps<br />
required to locate and validate stack overflows would be to attach<br />
a debugger to the target application or process, generate<br />
malformed input for the application, subject the application to<br />
malformed input, and inspect responses in a debugger. The debugger<br />
allows the tester to view the execution flow and the state<br />
of the registers when the vulnerability gets triggered.<br />
On the other hand, a more passive form of testing can be employed,<br />
which involves inspecting assembly code of the application<br />
by using disassemblers. In this case, various sections are<br />
scanned for signatures of vulnerable assembly fragments. This<br />
is often termed as reverse engineering and is a tedious process.<br />
As a simple example, consider the following technique employed<br />
while testing an executable “sample.exe” for stack overflows:<br />
#include<br />
int main(int argc, char *argv[])<br />
{<br />
char buff[20];<br />
printf(“copying into buffer”);<br />
strcpy(buff,argv[1]);<br />
return 0;<br />
}<br />
File sample.exe is launched in a debugger, in our case OllyDbg.<br />
Since the application is expecting command line arguments, a large<br />
sequence of characters such as ‘A’, can be supplied in the argument<br />
field shown above.<br />
On opening the executable with the supplied arguments and continuing<br />
execution the following results are obtained.<br />
As shown in the registers window of the debugger, the EIP or Extended<br />
Instruction Pointer, which points to the next instruction<br />
to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal<br />
representation for the character ‘A’ and therefore the string<br />
‘AAAA’ translates to 41414141.<br />
This clearly demonstrates how input data can be used to overwrite<br />
the instruction pointer with user-supplied values and control<br />
program execution. A stack overflow can also allow overwriting<br />
of stack-based structures like SEH (Structured Exception<br />
Handler) to control code execution and bypass certain stack protection<br />
mechanisms.<br />
As mentioned previously, other methods of testing such vulnerabilities<br />
include reverse engineering the application binaries, which<br />
is a complex and tedious process, and using fuzzing techniques.<br />
Gray Box testing<br />
When reviewing code for stack overflows, it is advisable to search<br />
for calls to insecure library functions like gets(), strcpy(), strcat()<br />
etc which do not validate the length of source strings and blindly<br />
copy data into fixed size buffers.<br />
For example consider the following function:-<br />
void log_create(int severity, char *inpt) {<br />
char b[1024];<br />
if (severity == 1)<br />
{<br />
strcat(b,”Error occurred on”);<br />
strcat(b,”:”);<br />
strcat(b,inpt);<br />
FILE *fd = fopen (“logfile.log”, “a”);<br />
fprintf(fd, “%s”, b);<br />
fclose(fd);<br />
. . . . . .<br />
}<br />
From above, the line strcat(b,inpt) will result in a stack overflow<br />
if inpt exceeds 1024 bytes. Not only does this demonstrate an<br />
insecure usage of strcat, it also shows how important it is to examine<br />
the length of strings referenced by a character pointer that<br />
is passed as an argument to a function; In this case the length<br />
of string referenced by char *inpt. Therefore it is always a good<br />
idea to trace back the source of function arguments and ascertain<br />
string lengths while reviewing code.<br />
Usage of the relatively safer strncpy() can also lead to stack overflows<br />
since it only restricts the number of bytes copied into the<br />
destination buffer. If the size argument that is used to accomplish<br />
this is generated dynamically based on user input or calculated<br />
inaccurately within loops, it is possible to overflow stack buffers.<br />
For example:-<br />
void func(char *source)<br />
{<br />
Char dest[40];<br />
…<br />
size=strlen(source)+1<br />
….<br />
strncpy(dest,source,size)<br />
}<br />
where source is user controllable data. A good example would be<br />
the samba trans2open stack overflow vulnerability (http://www.<br />
securityfocus.com/archive/1/317615).<br />
Vulnerabilities can also appear in URL and address parsing code. In<br />
such cases, a function like memccpy() is usually employed which<br />
copies data into a destination buffer from source until a specified<br />
character is not encountered. Consider the function:<br />
void func(char *path)<br />
{<br />
char servaddr[40];<br />
…<br />
memccpy(servaddr,path,’\’);<br />
….<br />
}<br />
In this case the information contained in path could be greater than<br />
40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow.<br />
A similar vulnerability was located in Windows RPCSS subsystem<br />
(MS03-026). The vulnerable code copied server names from<br />
UNC paths into a fixed size buffer until a ‘\’ was encountered. The<br />
length of the server name in this case was controllable by users.<br />
Apart from manually reviewing code for stack overflows, static code<br />
analysis tools can also be of great assistance. Although they tend to<br />
generate a lot of false positives and would barely be able to locate a<br />
small portion of defects, they certainly help in reducing the overhead<br />
associated with finding low hanging fruits, like strcpy() and sprintf()<br />
bugs. A variety of tools like RATS, Flawfinder and ITS4 are available<br />
for analyzing C-style languages.<br />
Tools<br />
• OllyDbg: “A windows based debugger used for analyzing buffer<br />
overflow vulnerabilities” - http://www.ollydbg.de<br />
• Spike, A fuzzer framework that can be used to explore vulnerabilities<br />
and perform length testing - http://www.immunitysec.com/<br />
downloads/SPIKE2.9.tgz<br />
• Brute Force Binary Tester (BFB), A proactive binary checker - http://<br />
bfbtester.sourceforge.net/<br />
• Metasploit, A rapid exploit development and Testing frame work -<br />
http://www.metasploit.com<br />
References<br />
Whitepapers<br />
• Aleph One: “Smashing the Stack for Fun and Profit” - http://insecure.org/stf/smashstack.html