Directory Traversal

Web servers are generally set up to restrict public access to a specific portion of the Web server's file system. In a directory traversal or path traversal attack, an intruder manipulates a URL in such a way that the Web server executes or reveals the contents of a file anywhere on the server, residing outside of the Web server's root directory. Path traversal attacks take advantage of special character sequences in URL input parameters, cookies, and HTTP request headers.

A common path traversal attack uses the "../" character sequence to alter the document or resource location requested in a URL. Although most Web servers prevent this method by escaping sequences, alternate encodings of the "../" sequence can bypass basic security filters. Even if a Web server properly restricts path traversal attempts in the URL path, any application that exposes an HTTP-based interface is also potentially vulnerable to such attacks.

These method variations include valid and invalid Unicode-encoding of:

• The forward slash character, such as "..%u2216" or "..%c0%af".

• The backslash characters, such as URL encoded characters "%2e%2e%2f" , or double URL encoding "..%255c".

Several typical path traversal attacks are shown below:

Path Traversal Attacks Against a Web Server

Example Code 1

http://example.test/../../../secret/file

This attack is the "classic" version of a path traversal attack. Most Web servers and applications will at least filter the '../' character string. However, it is worth noting that many applications running under Windows might also be vulnerable to the '..\' character string (backslash instead of slash).

Example Code 2

http://example.test/..%5c..%5c..%5csecret/file

The second attack uses escaped encoding ('%5c' translates to '\'). It relies on the assumption that the target application either has no relevant security checks for path traversal in place or that those checks are done before the translation of the escaped characters.

Example Code 3

http://example.test/..%255c..%255c..%255csecret/file

The third attack is a special version that is widely known for its use against a Web server that (unintentionally) translated escaped encoded characters twice. However, the security checks were done only after the first conversion. As '%25' translates to '%' after the first conversion the third attack looked exactly like the second attack but was not detected by the security checks in place. After the second conversion the '%5c' were replaced by '/' and the attack string was complete.

Note that the string "%5c" within the URL is a Web server escape code. Escape codes are used to represent normal characters in the form %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.

This example demonstrates how 'creative' exploitable programming errors can be. Multiple decoding of masked characters is a common problem for many applications.

Path Traversal Attacks Against a Web Application

Original URL

http://example.test/cgi-bin/index.cgi?web/web.html

Example of a Path Traversal Attack

http://example.test/cgi-bin/index.cgi?../cgi-bin/index.cgi

Obviously, the Web pages on this Web server are not addressed directly. Rather this work is done by a script called index.cgi. The script evaluates the parameter (web/web.html) included in the URL after the question mark and outputs the designated file, probably doing some standard extra work like adding header and footer. If the attacker guessed the directory structure and the script did not perform appropriate input validation, the script would probably display its source code to the attacker in a Web page, thus giving away valuable hints for further attacks.

Path Traversal Attacks Using Special Characters

Original URL

http://example.test/cgi-bin/index.cgi?web/web.html

Example of a Path Traversal Attack

http://example.test/cgi-bin/index.cgi?../cgi-bin/index.cgi%00.html

One input validation technique consists of checking the extension of a file name parameter. The underlying idea is to only display files with a 'correct' extension like 'html' or '.txt' thus preventing the application from displaying, for example, script code. The attack above uses the escaped encoded NULL character ('%00') creating a URL that ends with .html to pass this validation step. However, it is likely that the script - when using the parameter - will stop evaluating the parameter string as soon as it reaches the NULL character and once again might be tricked into displaying its source code to the attacker.

Some SAP programs access file on the application server using the ABAP command OPEN DATASET or related statements. For some of these programs, the user can enter the file name in the user interface, for example, in a selection screen.

In this context, if the user input is not restricted, a user can enter any physical file name, including the same or similar character sequences as described before. The user can also enter an absolute file name (for example, /usr/etc/pwd/<xyz> or C:\Windows\<xyz>).

The AS ABAP does allow for a mapping of physical path and file names to a logical file name. Also in this case, the user input should be restricted to prevent the user from selecting or entering a logical file name that provides access to a part of the file system that does not belong to the application's context.

When accessing the file system, the AS ABAP automatically performs the following authority checks:

• When accessing all files, an authority check for the authorization object S_DATASET is performed.
• When accessing files whose physical file names are stored in table SPTH, an authority check for the authorization object S_PATH is performed, if the field FS_BRGRU (user authorization group) is filled.
• When accessing physical file names that end with .PSE, an authority check for the authorization object S_RZL_ADM is performed. (These files are system security files where keys used for digital signatures and encryption are stored.)

In addition, logical file names can be used to specify platform-independent path and file names that map to the actual physical path and file name. These logical file names can also be used to prevent directory traversal by building a whitelist of valid paths and file names. If a user attempts to access a location in the file system that is not included in the whitelist for a certain context, access is denied.

To use the whitelist for access protection:

• Programs that access files in the application server file system have to call the function module FILE_VALIDATE_NAME explicitly before performing the file access.

• The program provides the function module with the physical file name for which access is being requested and a hard-coded logical file name. This logical file name is used to validate the physical file name.

• For the validation to be successful, the system administrator must maintain the mapping between the physical path and file name to the hard-coded logical file name.

The combination of these steps allows the system administrator to restrict access to the application server file system.

To prevent path traversal attacks in ABAP programs:

• Do not implement file access functionality that is based on user input, unless there is no other alternative.

• Call FILE_VALIDATE_NAME prior to accessing the file system (for example, with OPEN DATASET) to ensure that the file being accessed is in a valid directory as specified in the logical file name mapping table.

In the context of a Web server environment, you should also ensure that:

• A codepage (such as charset = ISO-8859-1) is defined to clearly decide which characters are problematic.

• The given input is filtered for malicious metacharacters.

In addition to the aspects mentioned above for preventing path traversal attacks, the Web server provides two main security mechanisms:

• The root directory, which limits users' access to a specific directory in the Web server's file system.

• The administrators' access control list, which limits users' access to specific files within the root directory.