DIRECTORY TRAVERSAL ATTACK

What is a Directory Traversal Attack?

Properly controlling access to web content is crucial for running a secure web server. Directory
traversal is an HTTP exploit which allows attackers to access restricted directories and execute
commands outside of the web servers root directory.
Web servers provide two main levels of security mechanisms

Access Control Lists (ACLs)

Root directory

An Access Control List is used in the authorization process. It is a list which the web servers
administrator uses to indicate which users or groups are able to access, modify or execute particular
files on the server, as well as other access rights.

What an Attacker can do if your Website is Vulnerable

With a system vulnerable to directory traversal, an attacker can make use of this vulnerability to step
out of the root directory and access other parts of the file system. This might give the attacker the
ability to view restricted files, or even more dangerous, allowing the attacker to execute powerful
commands on the web server which can lead to a full compromise of the system.
Depending on how the website access is set up, the attacker will execute commands by
impersonating himself as the user which is associated with the website. Therefore it all depends on
what the website user has been given access to in the system.

Example of a Directory Traversal Attack via Web Server

Apart from vulnerabilities in the code, even the web server itself can be open to directory traversal
attacks. The problem can either be incorporated into the web server software or inside some sample
script files left available on the server.
The vulnerability has been fixed in the latest versions of web server software, but there are web
servers online which are still using older versions of IIS and Apache which might be open to directory
traversal attacks. Even tough you might be using a web server software version that has fixed this
vulnerability, you might still have some sensitive default script directories exposed which are well
known to hackers.

For example, a URL request which makes use of the scripts directory of IIS to traverse directories
and execute a command can be
GET http://server.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\ HTTP/1.1
Host: server.com

The request would return to the user a list of all files in the C:\ directory by executing
the cmd.exe command shell file and run the command dir c:\ in the shell. The %5c expression that is
in the URL request is a web server escape code which is used to represent normal characters. In
this case %5c represents the character \.
Newer versions of modern web server software check for these escape codes and do not let them
through. Some older versions however, do not filter out these codes in the root directory enforcer and
will let the attackers execute such commands.

URI encoded directory traversal[edit]

Canonicalization problem.
Some web applications scan query string for dangerous characters such as:

..

..\

../

to prevent directory traversal. However, the query string is usually URI decoded before use.
Therefore these applications are vulnerable to percent encoded directory traversal such as:

%2e%2e%2f which translates to ../

%2e%2e/ which translates to ../

..%2f which translates to ../

%2e%2e%5c which translates to ..\

Unicode / UTF-8 encoded directory traversal[edit]

Canonicalization problem.

UTF-8 was noted as a source of vulnerabilities and attack vectors by Bruce Schneier and Jeffrey
Streifling.[1]
When Microsoft added Unicode support to their Web server, a new way of encoding ../ was
introduced into their code, causing their attempts at directory traversal prevention to be
circumvented.
Multiple percent encodings, such as

%c1%1c

%c0%af

translated into / or \ characters.

Percent encodings were decoded into the corresponding 8-bit characters by Microsoft webserver.
This has historically been correct behavior as Windows and DOS traditionally used canonical 8-bit
characters sets based upon ASCII.
However, the original UTF-8 was not canonical, and several strings were now string encodings
translatable into the same string. Microsoft performed the anti-traversal checks without UTF8 canonicalization, and therefore not noticing that (HEX) C0AF and (HEX) 2F were the same
character when doing string comparisons. Malformed percent encodings, such as %c0%9v was also
utilized.[2]

Zip/archive traversal attacks[edit]

The use of archive formats like zip allows for directory traversal attacks: files in the archive can be
written such that they overwrite files on the filesystem by backtracking. Code that uncompresses
archive files can be written to check that the paths of the files in the archive do not engage in path
traversal.

Absolute Path Traversal

The following URLs may be vulnerable to this attack:

http://testsite.com/get.php?f=list
http://testsite.com/get.cgi?f=2
http://testsite.com/get.asp?f=test

An attacker can execute this attack like this:

http://testsite.com/get.php?f=/var/www/html/get.php
http://testsite.com/get.cgi?f=/var/www/html/admin/get.inc
http://testsite.com/get.asp?f=/etc/passwd

When the web server 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).

Possible methods to prevent directory traversal[edit]

A possible algorithm for preventing directory traversal would be to:
1. Process URI requests that do not result in a file request, e.g., executing a hook into user
code, before continuing below.
2. When a URI request for a file/directory is to be made, build a full path to the file/directory if it
exists, and normalize all characters (e.g., %20 converted to spaces).
3. It is assumed that a 'Document Root' fully qualified, normalized, path is known, and this
string has a length N. Assume that no files outside this directory can be served.
4. Ensure that the first N characters of the fully qualified path to the requested file is exactly the
same as the 'Document Root'.
5. If so, allow the file to be returned.
6. If not, return an error, since the request is clearly out of bounds from what the web-server
should be allowed to serve.
7. Using a hard-coded predefined file extension to suffix the path does not limit the scope of the
attack to files of that file extension.
<?php
include($_GET['file'] . '.html');

The user can use %00 (NULL, indicating the end of the string) in order to bypass everything after the
$_GET

http://resources.infosecinstitute.com/web-vulnerabilities-explained/
http://resources.infosecinstitute.com/owasp-top-ten-testing-andtools-for-2013/