Web Application Vulnerabilities 101 - Directory Traversal

Directory traversal aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.  Directory traversals come from a lack of filtering/encoding of information used as part of a path by an application. We can test this directly in the browser by manipulating the URL, however it is also important to check the source code of the website as this path of the vulnerability may not be displayed directly in the browser.

For example,the browser does not directly show the image path, its only once you 'right click' and 'view page source', that the image path is displayed: img src="/file.php?file=hacker.png"

Example 1:

Our initial URL is: http://192.168.0.99/examples/file.php?file=hacker.png  To exploit the URL, we simple need to remove the file name, hacker.png and the append the ../, as shown below:
http://192.168.0.99/examples/file.php?file=../../../../../../../../etc/passwd

Example 2:

In some cases, you can see the full path being used to access the file ( either in the URL or via 'view page source'),  img src="/file.php?file=/var/www/hacker.png" However, in most cases a simple check performed by the PHP code will prevent you from just replacing it with /etc/passwd.  However, it can be bypassed by keeping the beginning of the path and adding the payload at the end, so in our example we simply remove 'hacker.png' before adding the ../, as shown below:
http://192.168.0.99/examples/file.php?file=/var/www/../../../../../../etc/passwd

Example 3:

Many language libraries include a function that checks the path to ensure that only allowed filetypes are passed to the filesystem. In an image management application, for example, a request to /var/www/images/new.jpg would succeed, but a request to /var/www/images/../../../etc/passwd would fail this check, since passwd does not end with a valid image format filetype.

Using a null byte %00.

Fortunately, this type of check is sometimes possible to bypass by appending a null byte character ‘%00’ in a way that the web application verifies the extension: /var/www/images/../../../etc/passwd%00new.jpg

The web application will check the path extension and verify that it is a .jpg file, bypassing the filter. When this path is passed to the filesystem, the null byte character effectively tells the filesystem to ignore anything that comes after it. When the path is resolved by the filesystem, it interprets the directory traversal vulns and transforms /var/www/images/../../../etc/passwd%00new.jpg into /etc/passwd.

Example

After reviewing the page source code, we note:
/file.php?file=hacker

We try the following but it fails -
http://192.168.0.99/examples/file.php?file=/var/www/../../../../../../etc/passwd

Solution: http://192.168.0.99/examples/file.php?=../../../../../../../pentesterlab.key%00

The developer tried to filter the file var. However, I can still use Null character to bypass it. The web application will check the path extension and verify that it is a .png file, bypassing the filter. When this path is passed to the filesystem, the null byte character effectively tells the filesystem to ignore anything that comes after it. When the path is resolved by the filesystem, it interprets the directory traversal vulns and transforms /var/www/images/../../../etc/passwd%00new.png into /etc/passwd

Further reading:

https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/
https://www.owasp.org/index.php/Path_Traversal