Using Nested Traversal Sequences to Bypass File Path Traversal Defense

A file path traversal (AKA directory traversal) vulnerability is a serious security flaw in which attackers are able to access and abuse the file system of the back-end web server. An attacker can exploit this vulnerability to read and write arbitrary files to the system, modify application data, and even gain a foothold or shell on the machine.

A basic file path traversal vulnerability uses the sequence ../ to ‘go up’ a directory in the directory structure. This is the most basic unit for exploiting a file path traversal vulnerability on a Linux machine, whereas ../ or ..\ can be used for Windows machines to jump directories. Multiple instances of this sequence are used together in order to access an arbitrary file. For instance, on a linux machine, a simple file path traversal sequence would be as follows:

../../../etc/passwd

Essentially, we are entering the file system at a given point in the application, and navigating to a target file. For instance, an example from PortSwigger Web Security Academy is as follows:

“Consider a shopping application that displays images of items for sale. Images are loaded via some HTML like the following”:

<img src=”/loadImage?filename=218.png>

“The loadImage URL takes a filename parameter and returns the contents of the specified file. The image files themselves are stored on disk in the location /var/www/images/. To return an image, the application appends the requested filename to this base directory and uses a filesystem API to read the contents of the file. In the above case, the application reads from the following file path”:

/var/www/images/218.png

So, we enter our file path traversal sequence three times in the appropriate web application input field, as shown above, which brings us ‘up’ in the directory tree three directories, to the root directory, then into etc, and into passwd. The contents of this target file will now, generally, be readable in the HTTP response from the application. Our entire path is shown below:

/var/www/images/../../../etc/passwd

There are some effective ways to prevent a file path traversal vulnerability, one of which is stripping or blocking file path traversal sequences from the user-supplied filename query, preventing unrestrained access to the server-side file system. However, this can be circumvented by an attacker by using a nested traversal sequence technique, which will be covered in this article.

….// is a basic nested traversal sequence. It effectively bypasses the defense outlined above, by using the defense against itself. The application strips the inner file path traversal sequence defensively, but leaves a remaining ../, which we can use to jump directories. Below, I will use the free Burp Suite Community Edition tool and PortSwigger’s free Web Security Academy, to walk us through an example of this attack. Other tools used include the Firefox Browser, and FoxyProxy, a Firefox add-on.

Burp Suite Community edition can be downloaded here: https://portswigger.net/burp/communitydownload

A PortSwigger Web Security Academy account can be created here: https://portswigger.net/web-security

Firefox Browser can be downloaded here:

https://www.mozilla.org/en-US/firefox/new/

The FoxyProxy Firefox add-on can be downloaded here: https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/

First, we need to access the ‘file path traversal, traversal sequences stripped non-recursively’ lab on Portswigger’s Web Security Academy.

We are presented with an online web shopping application. I have already opened Burp Suite and have it running, so I will open FoxyProxy to select Burp Suite. This passes all communications with the app through Burp Suite itself, allowing us to manipulate our requests.

Next, we need to change the scope and settings in Burp Suite to focus on this website only. We navigate to the target tab on Burp Suite, click on Scope, and then click Add. Here we will paste the URL of the target web application. Click ‘OK’ to save the target scope. Then, click ‘Yes’ to avoid accumulating project data for out of scope items.

Next, go to the Proxy tab on Burp Suite, and click on Options. Under ‘Intercept Client Requests’ check the box next to ‘And’. Under ‘Intercept Server Responses’, check the box next to ‘And’ as well. This will further narrow the scope of our operation.

Go to the Proxy tab, and select Intercept. Click the box so it says ‘Intercept is On’. Then, go to the target application in our browser, and click the refresh button. This will populate an HTTP request in Burp Suite. We have successfully intercepted the packet on its way to our target website. We can now manipulate it in any way we see fit. Of particular interest to us, in this scenario, is the following detail:

/image?filename=72.jpg

This is found in the GET request which is now populated in Burp Suite. This is a request from our browser to the site, asking it to retrieve 72.jpg from the disk space on the back-end server machine.

This website strips file path traversal sequences from user-supplied filename queries as a defensive tactic, so we will need to use a nested traversal sequence technique to bypass this defense. Replace ’72.jpg’ with our attack sequence:

….//….//….//etc/passwd

Forward the packet, and then in Burp Suite, navigate to the HTTP history tab. Select the GET request that we edited to include our attack, which is easily found by looking for the request that has a checkmark under the ‘edited’ column. Select the ‘Response’ tab, and we will see that we have successfully extracted the contents of the sensitive /etc/passwd directory.

We have successfully completed the Web Security Academy lab.

Now, as an attacker, we have system usernames, and the paths to their respective user directories. Perhaps more importantly, we have an easy way to access the sensitive server-side files we should not be able to read. We can visit the /etc/shadow file to retrieve hashes to crack. An experienced attacker could also go further with this vulnerability and use it to gain a foothold shell on the machine. Prevention of this attack is simple, but requires thinking ahead. Nested traversal sequences such as ….// should be blocked by the application before it goes live, that way the opportunity for a nested file path traversal sequence attack never exists in the first place.