What Is a Directory Traversal Attack and How to Prevent it?

Consider a situation where your magazine subscription service grants you access to view the file “commentary.html” at www.magazine.com/accounts/info/news/commentary.html. Somehow, out of curiosity, you decide to navigate and sneak peek at other locations in the URL such as www.magazine.com/accounts/info/news and www.magazine.com/accounts/info to see what’s inside. Whether or not you succeed, you are attempting to traverse directories. For example, if the website isn’t correctly configured, you might discover that you now have access to every single file in the directory www.magazine.com/accounts/info/. This is referred to as directory traversal (also known as directory climbing or backtracking).

Just as the name implies, a directory traversal occurs when you can traverse (move across or through) in and out of your current directory into the parent directory or other nearby directories.

Directory traversal vulnerabilities are simply loopholes in an application that allows unauthorized users to access files outside a restricted directory structure. Traversal loopholes are among the most common problems found with any protocol that maps user requests to local file paths. It has been the cause of numerous Microsoft security vulnerabilities. These loopholes can easily be exploited to launch directory traversal attacks.

A directory traversal attack aims to access files and directories that are stored outside the immediate directory. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and their variations or using absolute file paths, it may be possible to access arbitrary files and directories stored on file systems. The dot dot slash or “../” tells the file system to move one level back towards the root (home) directory. For instance, the code “a/b/c/../” means the file system navigates to “a/b/” without using the full path. This allows you to find other files from different folders without knowing and using the full path to those files.

How Does a Directory Traversal Attack Work?

Directory traversal attacks can be efficiently executed if there are inherent vulnerabilities in the configuration of web servers, File Transfer Protocol (FTP) servers, or hosted applications. For example, consider a scenario where a university IT department decides to adopt FTP to allow students and researchers to upload their research work to the university web portal. FTP software was chosen because it supported large file uploads and transfers that are otherwise impossible with email and popular file-sharing programs.

This same type of scenario could play out in websites, web applications, web servers, and other systems running applications with directory traversal vulnerability, even if the host web server is fully patched and up-to-date. This in-a-nutshell is how a malicious actor can exploit directory traversal vulnerability to steal sensitive information or database credentials from web servers and hosted applications. However, the process can be a lot more complicated than that.

In Microsoft OS, for example, directory traversal uses the ..\ or ../ parameters, while the root directory uses the notation “C:\” (where C is usually the primary home partition), and there is no standard root directory above that. This means that for most directory vulnerabilities on Windows, attacks are limited to a single partition. On the other hand, in the Unix/Linux system, directory traversal uses the “../”  parameter.

In most operating systems, null bytes such as “%00” can be injected to terminate filenames or extensions. For example, sending commands such as: ?file=commentary.doc%00.pdf to a vulnerable web application will result in the application seeing a string that ends with “.pdf,” and the operating system will see a file that ends in “.doc.” Attackers use this trick to bypass validation routines. URLs such as http://university.com/get-files?file=list that accepts input from users serve as a potential doorway to directory traversal attacks. An attacker may take advantage of such loopholes to inject malicious strings as the user input parameter to access files located outside the current directory. For example:

• http://university.com/get-files?file=../../../../etc/passwd
• http://university.com/../../../../etc/passwd

A typical example of vulnerable application code is the PHP script shown below:

<?php

$commentary = 'file.php';

if ( is_set( $_COOKIE['COMMENTARY'] ) )

$commentary = $_COOKIE['COMMENTARY'];

include ( "/root/accounts/info/commentary/" . $commentary );

?>

An attack against this application could be to send the following HTTP request:

GET /vulnerable.php HTTP/1.0

Cookie: 'COMMENTARY'=../../../../../../../../../etc/passwd

Thereby generating the following server response:

HTTP/1.0 200 OK

Content-Type: text/html

Server: Apache

root:Ei3sFG95iakR6:0:1:System Operator:/:/bin/ksh

daemon:*:1:1::/tmp:

info:E9dk3k1OIf42.:182:100:Developer:/root/accounts/info/:/bin/csh

The ../ characters after /root/accounts/info/commentary/ has caused the include() function to traverse to the root directory, and then include the Linux password file /etc/passwd.

What can an Attacker do if Your System or Application is Vulnerable?

The primary objective of information security efforts is to protect the confidentiality, integrity, and availability of data. Confidentiality means that data is protected from unauthorized viewing or access.  Integrity means that information is protected from unauthorized modification to ensure that it is reliable and accurate. Finally, availability means that authorized users have access to the systems and the resources they need.

Suppose a web server or web application is vulnerable to directory traversal attack. In that case, the attacker can exploit the vulnerability to compromise the confidentiality, integrity, and availability of the system or data. For example, the attacker can compromise the system’s secrecy by gaining unauthorized access to the root directory and stealing sensitive information such as system configuration, password files, database credentials, and much more. The attacker can also execute powerful commands on the webserver, leading to a data breach or a complete compromise of the webserver.

Attackers may use directory traversal to compromise the system’s integrity by modifying critical files such as programs files, libraries, source codes, or even financial or health records, as the case may be—which usually require high data integrity.

Worse yet, an attacker may use directory traversal to gain complete control of the server and possibly delete applications or critical system configuration files, causing potentially irrecoverable damage to your system and making it unavailable to users.

How Can You Test and Detect Directory Traversal Vulnerabilities?

Standard security testing techniques can be utilized to test and detect directory traversal vulnerabilities in web applications. Web Application Security Project (OWASP) recommends that testers perform the following procedures:

Input vectors enumeration: Detecting attack vectors in IT systems is called enumeration. Input vector enumeration is the systematic evaluation of each input vector to determine which part of the web application is vulnerable to input validation bypassing.  To do this, the tester needs to itemize (enumerate) all aspects of the application that accept input from the user, including HTTP, GET and POST calls, file uploads, and HTML forms. Some of the critical questions and checks to consider at this stage include:

• Are there request parameters that could be used for file-related operations? E.g., https://mywebsite.com/getUserProfile.jsp?item=tkpga.htm
• Are there unusual file extensions? E.g., https://mywebsite.com/index.jsp?file=content

• Are there interesting variable names? E.g., https://mywebsite.com/main.php?home=index.htm

Testing Techniques The next stage of the testing process is to analyze the input validation functions present in the web application. This involves a systematic evaluation of various attack techniques used by an attacker to exploit and uncover inherent flaws. There are different web application testing techniques you can use to discover these vulnerabilities. Some may involve a white box, black box, or grey box testing as the case be. OWASP provides a detailed guideline on directory traversal vulnerability testing for web applications (web servers are not covered). Some of the popular testing techniques you can use include:

• Static Application Security Testing (SAST): SAST is used to secure applications by reviewing the source code when it’s not running to identify vulnerabilities or evidence of known insecure practices. SAST tools employ a white-box testing strategy that scans the source code of applications and their components to identify potential security flaws.
• Dynamic Application Security Testing (DAST): DAST tools communicate with applications through the front-end to identify potential security vulnerabilities. DAST tools do not have access to source codes; instead, they perform actual attacks using the black-box strategy to detect vulnerabilities. With dynamic analysis, security checks are performed while running or executing the code or application under review. A technique known as fuzzing is used in dynamic tests to submit random, malformed data as inputs to the application to determine if it will uncover directory traversal flaws.
• Interactive Application Security Testing (IAST): IAST combines the best of SAST and DAST. It analyzes code for security vulnerabilities while the app is run by any activity interacting with the application functionality.

With the techniques described above, you can quickly test and detect directory traversal vulnerabilities in your web applications. However, this may require the services of a skilled pen tester. If you already have an existing web application, and you want to quickly find out if it is vulnerable to directory traversal attack or not, you can begin by inserting relative paths to files known to exist on your web server, such as ../../../../../../etc/passwd on Linux servers. You’d also have to check if the system is vulnerable to tricks such as ../ removal using percent-encoded values such  %2e%2e%2f and file extension checking by sticking a null byte such as  %00 before inserting the valid extension. As you would imagine, this can be technically tasking for most people. This is where web vulnerability scanners come into play.

Web Vulnerability Scanners

1. Veracode

Veracode is a SaaS platform for automated Web application testing that works on the DAST model and can be integrated into the DevOps cycle.

2. Checkmarx

Checkmarx cloud platform offers two separate packages for DAST and SAST services and both can be integrated into a CI/CD pipeline.

3. Invicti

The Invicti vulnerability testing system offers DAST, SAST, and IAST and can be deployed for the development cycle on-demand or running continuously. Invicti installs on Windows and Windows Server and is also available as a SaaS package.

4. Acunetix

A vulnerability manager for Web applications and networks that can also serve as a development testing service with DAST, SAST, and IAST features. Offered as a SaaS platform or for installation on Windows, macOS, and Linux.

Web vulnerability scanners such as Veracode, Checkmarx, Invicti, Acunetix, and others are an effective way to check whether your website and web applications are vulnerable to directory traversal attacks. They implement most of the web application testing techniques discussed above and allow you to apply those techniques to scan your web application for vulnerabilities. A web vulnerability scanner crawls your entire website or application and automatically checks for directory traversal vulnerabilities and other security issues. It will then generate a report on the vulnerabilities found and attempt to fix them automatically.

How Can You Prevent Directory Traversal Attacks?

To prevent directory traversal attacks, you must first ensure that your web servers and hosted applications are up-to-date and that all patches have been applied. You don’t want to be caught running an old, vulnerable web server; otherwise, none of the recommendations below will help you even if you use a web application firewall (WAF).

Secondly, directory traversal vulnerabilities and attacks can be easily prevented by adhering to secure coding practices during the software development process. Developers must ensure that user inputs are effectively filtered. User input sanitization libraries should be used when writing application codes. This involves proper user input validation, including filtering metacharacters from the user input and removing everything but the known good data. This will ensure that only what should be entered in the field will be submitted to the server.

User input filtering and validation should be part of the software development lifecycle (SDLC) for applications being actively developed. Developers and testing teams should be trained to identify and prevent such vulnerabilities early in the development process. Other ways to prevent directory traversal attacks are as follows:

• When making calls to the filesystem, you should avoid relying on user input for any part of the path.
• If you really can’t avoid relying on user input, normalize the information or the path before using it. Then, check that its prefix matches the directory that users are permitted to access.
• Process URI requests that do not result in a file request, and 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).
• Ensure that your web server operating system and critical application files are kept separate from each other. Do not store any sensitive files in the webserver storage device. This will lower your risk in case of any eventuality.
• Do not use administrator or superuser accounts to run web servers whose permissions only allow them to read only the files it needs to run. It should not write to any files since all user data should be stored in a separate database.