What is Path Traversal vulnerability?

Path Traversal attacks are performed when the vulnerable application allows uncontrolled access to files and directories, to which the user should not usually have access. The attack vector is the parameters passed on the application, representing paths to resources, on which specific operations are to be performed – reading, writing, listing the contents of the directory. Path manipulation is done, for example, by adding the string “../”.

In subject literature, you can find other terms of the same vulnerability: Directory Traversal or “dot-dot-slash attack“. The success of the attack determines both the lack or insufficient validation of the input data to the application, as well as configuration errors – incorrect permissions for files and directories. Successful attempt to use vulnerability results in the ability to read the contents of directories and files, to which an attacker should not have access (e.g. configuration files containing access data to external services). The attack is not characteristic of one group of technologies (e.g. PHP). Path Traversal is often a part of other attacks, e.g. LFI(Local File Inclusion).

The susceptibility logic

The standard example of code susceptible to Path Traversal is presented in Listing No. 1.

The readfile function passes the value of the file parameter retrieved directly from the URL. The use of such a code means that by manipulating the value of the file parameter, it is possible to read any file from the server, on which the vulnerable application is running. The only limitation will be the permissions, with which the web server admin is running. Similar code examples can be prepared for any other technology and programming language.

Threats

The occurrence of Path Traversal vulnerability in the application is associated with several threats. The most important of them are discussed below.

Revealing redundant information

Thanks to a successful attack using the vulnerability of Path Traversal, it is possible to list the contents of any directory. The attacker then gets additional information about the application architecture (file and directory structure). They may be useful, for example, to discover the elements of the tested system.

Another potential attack scenario is to read the contents of files, containing the history of executed commands on the server (e.g. Bash_history). Access to this type of files may lead to the disclosure of access data to local as well as external services (e.g. password to the database server).

Revealing configuration files

Although there is a clear resemblance to the previous point, please be aware of the potential access to configuration files in a separate paragraph. This threat may be particularly crucial if the attacker gains access to information about services that are available from outside.

An interesting example is a vulnerability that allows you to list information about the Apache server, vhosts. By default, the attacker may not have knowledge about other applications running on the server, but by listing such configuration, he or she will obtain information about other elements of the system. This will increase the potential field of ​​the attack.

Remote code execution

The vulnerabilities associated with Path Traversal are not limited to the ability to read files. If the application incorrectly validates the data when uploading files to the server, theoretically, there may be a situation when the attacker will have an impact on the path of writing the file on the server. This, in turn, depending on the server configuration, can directly lead to a situation when it will be possible to place the file anywhere in the directory tree. Here, of course, you must take into account the restrictions associated with the permissions where the write operation is performed.

A broader view of the problem

Path Traversal sometimes occurs not only in the parameter passed to the application (or headers) but also in the URL itself. In this way, by going to an address similar to the one given below, it is possible to read any file from the server.

The reason for such vulnerability may be both a web server error and inadequately implemented application routing. It should be remembered that vulnerabilities in this attack cannot be combined only with web applications. This attack is possible to carry out wherever the input data is incorrectly validated, which are used to read files or directories later. As mentioned, Path Traversal may be part of another attack. An example may be the XXE (XML External Entity Processing) vulnerability in the application where passing the crafted path, containing Path Traversal, is possible to read the contents of the directory or selected file.

Examples of vulnerability

The aggregation databases on susceptibility data in the software are full of information about the vulnerabilities that allow Path Traversal attack. It should be noted that this vulnerability class has been known for years, although information about new errors in applications concerning this vulnerability class is still being published.

GlassFish Server

In August 2015, information about Path Traversal was published in the popular GlassFish application server. The transition to the appropriately crafted URL made it possible to read any file from the disk, in which the software was running.

In response, the application returned the contents of the ../etc/passwd file:

Importantly, this vulnerability involved both a server running Linux environment as well as Windows.

ColoradoFTP 1.3

Path Traversal is not just the domain of a web application. Quite often, this condition appears in FTP servers. For example, in the ColoradoFTP software, by adding the appropriate string, you could access files from outside the main server directory. On the other hand, executing the command from the following listing will cause the binary file to be uploaded to the system32 directory:

Testing

Like any other vulnerability in applications (e.g. SQL Injection, XSS), Path Traversal can occur in any piece of software or function element. No segment can be omitted during verification, but there are functions that are particularly vulnerable to Path Traversal:

●        downloading files from the server,

●        loading application configuration (styles, templates, interface language),

●        uploading files to the server.

The basic method of testing that can be used is an ordinary HTTP proxy, e.g. Burp Suite. By manipulating the query and adding the string, “../”, to the parameters, representing paths to files and directories, we can try to search for vulnerabilities:

Automation

The vulnerability to Path Traversal can be searched manually or entrusted to automatic scanners. An example of a simple tool is dotdotpwn – a script that performs basic fuzzing and can determine whether the tested application is vulnerable based on the analysis of the application’s response.

Avoiding filters

As Path Traversal is not a new vulnerability in the world of IT security, the majority of IDS software detects such attacks. Software such as IPS or WAF tries to actively counteract attempts to use vulnerabilities by blocking queries containing the known strings, such as “../”, its variations and duplicated instances. In this case, the susceptibility in the application may still exist, but the tester “reflects” only from the additional protective layer. This type of filters always acts based on blacklists. The table presents the basic forms of bypassing such filters.

payload	Representation
% 2e% 2e% 2f	../
% 2e% 2e /	../
..% 2f	../
% 2e% 2e% 5c	.. \
% 252E% 252E% 255C	.. \
..% 255C	.. \
..% c0% af	.. \
..% c1% 9c	.. \

Protection

The basic form of protection against this vulnerability is the proper validation of input data. If possible, it is also recommended to use mechanisms that identify the files on the disk, e.g. through unique identifiers (UUID). Also, remember to verify file permissions (e.g. appropriate permissions for running a web server).

Blocking the attack by substituting the text

In web applications, you can encounter security that searches for the occurrence of the string, “../”, in the path to the file. The protection consists of removing such strings from the text representing the name of the file or the path to it. This is quite an unfortunate solution because, through simple manipulation, the protection is easy to overcome. When passing the following string to the application, only its middle part will be removed:

Removing such a string from the path will not protect against vulnerability, because it will continue to contain “…/”.

Modeling of threats

If our application performs operations on files or directories while using data from untrusted sources in this process, it is worth answering a few questions:

● Are the data used for operations on files and directories validated appropriately?

● Do functions that allow uploading files to the server allow manipulation of the path, to which the file will be saved?

● Have the application components (e.g. external scripts) been checked for vulnerability to Path Traversal?

Summary

Path Traversal attack is certainly not a novelty. Besides, as with most vulnerabilities, protection against it boils down to the implementation of appropriate validation of input data to the application. The databases that gather information about application errors show, however, that this is undoubtedly not a vulnerability that can be forgotten. New applications still allow for this attack to be successfully performed and, consequently, allow for unauthorised access to resources and even remote code execution.

Author: Marcin Piosek

Tagged: Hack, Path Traversal, Vulnerability