Directory Traversal Attack: Real-life Attacks and Code Examples

What is a Directory Traversal attack?

To run a secure web server, it is crucial to control access to the web content. A directory traversal attack (or file path traversal attack) allows attackers to read random files on the server that is running a web application. These files may include the application’s source code and data, credentials for backend systems, or sensitive OS files. The attacker might even be able to write to arbitrary files on the server, allowing them to modify the application’s data or behavior, or to even take full control of the server.

There are two main levels of security mechanisms web servers provide:

• Access Control Lists (ACLs)
• Root directory

Access control lists are used during the authorization process. A web administrator creates these lists to specify which users or user groups are able to access, modify or execute particular files on the server, as well as other access rights.

This is part of a series of articles about Security misconfiguration.

The root directory is a specific directory on the server’s file system and limits users from accessing anything above this root. The root directory limits users from accessing any files they are not meant to see or modify.

A directory traversal attack can be the result of a directory traversal vulnerability in the webserver software itself or in the application’s source code.

All an attacker needs to perform a directory traversal attack is a web browser and some knowledge on where to find any default files and directories on the system.

How does a Directory Traversal attack work?

If there are vulnerabilities in the web application’s code or the server’s configuration, it’s easy to execute a directory traversal attack. For example, let’s examine this PHP code snippet that is prone to directory traversal attacks:

/**
* Get the filename from a GET input
* Example - https://example-website.com/?file=filename.php
*/
$file = $_GET[‘file’];

/**
* Unsafely include the file
* Example: filename.php
*/
file_get_contents(‘directory/’ . $file);

In this case, attackers can use the command https://example-website.com/?file=../../../../etc/passwd and manipulate the web application to reveal hidden information of the /etc/passwd system file. 

Similar to our example, attackers can use directory traversal vulnerabilities to access credentials, modify files, or take control of the compromised web server.

The impact of a Directory Traversal attack

An attacker can leverage a directory traversal vulnerability in the system to step out of the root directory, allowing them to access other parts of the file system to view restricted files and gather more information required to further compromise the system.

Examples of Directory Traversal attacks

Real-life directory traversal attack examples

Back in September 2019, researchers discovered a “critical severity” directory traversal vulnerability in Atlassian’s Jira Service Desk Server and Jira Service Desk Data Center that allowed attackers to access information belonging to the company’s customers.

Atlassian wasn’t the only company to make news with such a vulnerability. In late September 2019, Adobe released a fix for three vulnerabilities in its ColdFusion platform, including a “critical” directory traversal vulnerability that could allow attackers to bypass access controls.

Another directory traversal disclosure took place in June 2019 and involved Kubecti. Kubecti is a command-line interface (CLI) for controlling Kubernetes clusters. The flaw was found in the cp command, which allows users to copy files from the Kubernetes pod to their local machine. The bug allowed malicious users to copy relative file paths and potentially use this to execute code or elevate privileges.

The target of a directory traversal attack doesn’t have to be a web application. Researchers found that 12 out of 13 routers and NAS devices from different manufacturers had security flaws that allowed remote-level access, and seven of those had directory traversal vulnerabilities.

Example of a directory traversal attack via web application code

Web applications that utilize dynamic pages receive input from the browser using GET or POST requests. Here is an example of an HTTP GET request URL:

GET http://example-shop.com/show.asp?view=oldarchive.html HTTP/1.1
Host: example-shop.com

Using this URL, the browser requests the dynamic page show.asp and sends a parameter with the value of oldarchive.html. Once the request is executed, show.asp retrieves the file oldarchive.html from the server, renders it, and sends it back to the browser which displays it to the user.

Now, if an attacker assumes that show.asp can retrieve files from the filesystem, he could send a custom URL, like this one:

GET http://example-shop.com/show.asp?view=../../../../../Windows/system.ini HTTP/1.1
Host: example.shop.com

The dynamic page would retrieve the file system.ini from the filesystem and display it to the user. The directive ../ shown in the URL above would tell the system to go one level up in the directory tree. The attacker would have to guess how many directories they have to go up to find the Windows folder, easily done with persistence and trial-and-error.

Example of a directory traversal attack via webserver

Directory traversal vulnerabilities are not limited to the code; the web server itself can be vulnerable to directory traversal attacks.

Vendors fixed directory traversal vulnerabilities in the latest versions of web server software, but there are servers online which still run older versions and may still be vulnerable to directory traversal attacks. Even running the latest version of the software won’t always help if some sensitive default script directories are exposed. 

Below is an example of a URL request which uses the IIS scripts directory to traverse directories and execute a command:

GET
http://example-server.com/scripts/..%5c../Windows/System32/cmd.exe?c+dir’c: HTTP/1.1
Host: example-server.com

The above-shown request would return a list of all files in the C: directory to the attacker. First, the request would execute the cmd.exe command shell file and then run the command dir c: in the shell. The %5c expression shown in the example represents a server escape code used to represent normal characters, in this case, the character .

Escape codes shouldn’t present a problem for newer versions of web server software, but some older versions don’t filter out these codes in the root directory enforcer and will let the attackers execute such commands.

Related content: Read our guide to misconfiguration attacks.

Detecting Directory Traversal Vulnerabilities

You should detect directory traversal vulnerabilities as early as possible. A best practice is to check the code while it’s being written, or before the software is deployed, using code analysis tools.

But code analysis tools typically miss about half of all vulnerabilities and come with a high rate of false positives. This makes the process of remediating directory traversal vulnerabilities lengthy and expensive.

Web vulnerability scanners (like Dynamic Application Security Testing scanners, or DAST) do a great job at detecting directory traversal vulnerabilities,l automatically crawling the website, and testing for vulnerabilities. They typically come with less false positives, or in the case of Bright, without any false positives at all. After the application is deployed you can opt for penetration testing, but this process is time-consuming. An alternative is to use fuzzing to experiment with different inputs and trying to cause problems with malformed data. 

Preventing Directory Traversal Attacks

To prevent directory traversal vulnerabilities, try to avoid passing user-supplied input to the filesystem APIs. Many of the functions that do that can be rewritten to deliver the same behavior, without exposing you to security risks.

If for any reason you can’t avoid passing user-supplied input, you should use two layers of defense:

• Make the application validate the user input before processing it. Either compare the input against a whitelist of permitted values or verify that the input contains only permitted content – for example, alphanumeric characters
• After validating the user-supplied input, make the application verify that the canonicalized path starts with the expected base directory.

Below is a simple Java code snippet that can be used to validate the canonical path of a file based on user input:

File file = new File (BASE_DIRECTORY, userInput);
if (file.getCanonicalPath().startsWith (BASE_DIRECTORY)) {
// process file
}

Check if your website is vulnerable with Bright

Bright automatically scans your web applications for directory traversal and other security vulnerabilities. Bright is false-positive free and easy to use for developers, so the remediation process will be less time-consuming without the need for manual validation.

The created reports come with clear remediation guidelines for your team, and the integration with ticketing tools like Jira makes it easy to assign findings to team members.
Register for a free account and start testing for directory traversal and hundreds of other vulnerabilities today – Try Bright today

Subscribe to Bright newsletter!