HTTP exploits use the Web server software to perform malicious activities. Directory traversal is one such exploit which lets attackers access restricted directories, execute commands and view data outside the normal Web server directory where the application content is stored.
Attackers use directory traversal attacks to try to access restricted Web server files residing outside of the Web server’s root directory.
The basic role of Web servers is to serve files. Files can be static, such as image and HTML files, or dynamic, such as ASP and JSP files. When the browser requests a dynamic file, the Web server first executes the file and then returns the result to the browser. Hence, dynamic files are actually files executed on the Web server.
To prevent users from accessing unauthorized files on the Web server, Web servers provide two main security mechanisms: the root directory and access controls lists. The root directory limits users’ access to a specific directory in the Web server’s file system. All files placed in the root directory and in its sub-directories are accessible to users. To limit users’ access to specific files within the root directory, administrators use access control lists. Using access control lists, administrators can determine whether a file can be viewed or executed by users, as well as other access rights.
The root directory prevents attackers from executing files such as cmd.exe on Windows platforms or accessing sensitive files such as the “passwd” password file on Unix platforms, as these files reside outside of the root directory. The Web server is responsible for enforcing the root directory restriction.
By exploiting directory traversal vulnerabilities, attackers step out of the root directory and access files in other directories. As a result, attackers might view restricted files or execute powerful commands on the Web server, leading to a full compromise of the Web server.
A directory traversal vulnerability can exist either in the commercial Web server itself or in the Web application code executed on the Web server. In the case of Web application code, dynamic pages usually receive input from browsers. Here is an example of such an HTTP request:
In this example, the dynamic page requested by the browser is called
and the browser sends the Web server the parameter item with a value of
. When executed by the Web server,
retrieves the file
from the Web server’s file system, renders it and sends it back to the browser which presents it to the user. A skilled attacker will immediately identify the potential problem in this request as the value of the parameter ends with a file extension, in this case “html”. The attacker will then assume that the dynamic page retrieves the file from the file system and uses it. By sending the following URL to the Web server:
the attacker causes
to retrieve the file
from the file system and send it to the attacker’s browser. The term “../” stands for “one directory up”. This is a common operating system directive. Therefore, the string
means “go four directories up and retrieve the file win.ini from there”. The attacker needs to guess how many directories to climb in order to get to the desired directory. (In this example the attacker tries to get to “C:” and is assuming that the Web server’s root directory is located four directories below “C:”). Guessing the exact combination is very easy. The attacker simply sends multiple requests until the desired result is achieved.
The directory traversal vulnerability occurs when programmers fail to validate input received from browsers. In the above example, the getnews.asp code does not validate that the value of the item parameter does not exceed from the root directory. The directory traversal vulnerability actually bypasses the Web server’s root directory restriction by introducing bad code into the Web server.
Web applications are not the only source of directory traversal vulnerabilities in your Web site. Some vulnerabilities exist within the Web server. These vulnerabilities can be part of sample files (e.g., sample ASP files) that exist on the Web server, or can be incorporated into the Web server software. For example, some earlier versions of the Microsoft IIS Web server included directory traversal vulnerabilities that allow attackers to fully compromise the Web server by executing files on the server. For example, the following URL:
would execute the cmd.exe file (operating system shell) and run the “dir c:” command which lists all files in the C: directory. Notice the string “%5c” that appears in the URL. This is a Web server escape code. Escape codes are used to represent normal characters in the form of %nn, where nn stands for a two-digit number. The escape code “%5c” represents the character “”. The problem is that the IIS root directory enforcer did not check for escape codes and allowed that request to execute. The Web server’s operating system understands escape codes and executes the command.
Escape codes are also very useful for bypassing poorly written filters enforced on input received from users. If the filter looks for “../”, then the attacker could easily change the input to “%2e%2e/”. This has the same meaning as “../”, but is not detected by the filter. The escape code %2e represents the character “.” (dot).