Comprehensive Guide on Path Traversal

In our previous post, we’ve explained the Local File Inclusion attack in detail, which you can read from here. I recommend, then, to revisit our previous article for better understanding, before going deeper with the path traversal vulnerability implemented in this section.

Today, in this article we will explore one of the most critical vulnerabilities, that arises when the developer does not validate the inclusion functions in the web-applications, which thus allows the attacker to read and access any sensitive file from the server.

Table of Content

·         Introduction

·         Basic Path Traversal

·         Blocked Traversal Sequence

·         Validated Path Traversal

·         Path Disclosure in URL

·         Null Byte Bypass

·         Windows Server Path_Traversal Exploitation

Introduction

Path Traversal sometimes also termed as “Directory Traversal” is an HTTP vulnerability which allows an attacker to trick and manipulate the web application's URL in order to access the files or directories that resides outside the application’s root folder. This vulnerability carries when a developer fails to establish or manage the input validations while including the files such as images, static texts, codes, etc. in their web applications.

However, in such attacks, the attacker manipulates the web application input fields by entering the dot-dot-slash (../) sequences or some similar variations, in order to bypass the web page and access the desired system file.

Let’s check out this scenario and learn how an attacker defaces the web-application by grabbing the server’s sensitive files.

Here, the user calls up a file - index.php through the web application's URL i.e. http://abc.com/file=index.php. Thus the application process the URL and calls up the index.php that was present locally into the server folder “RAJ” as “/var/www/html/RAJ”. 

The developer uses this “include” functionality as “file=” with a simple intention to manage the user’s selected input files, such that the application can directly call it from the local server.

Now the attacker tries to manipulate the URL using the dot-dot-slash sequence as http://abc.com/file=../../../../etc/passwd, in order to retrieve the contents of the server’s password file.

Thus again the application will process it and reads up the file at /var/www/html/RAJ /../../../../etc/passwd. Every “../” represents - back to parent directory, thus if we call up “../” for four times, it will put us in the “root” directory, from there we can simply access the password file as etc/passwd.

Let’s now try to implement this in some real scenarios and check the different attacking sequences rather than the dot-dot-slash only.

For all this, I’ll be using two different platforms The Portswigger Academy and DVWA which contains the path traversal vulnerability.

Basic Path Traversal

Login into the PortSwigger academy and drop down till Directory Traversal to get into its labs, choose the first lab as “File path traversal, simple case” and hit the “Access the lab” button.

Here you’ll now be redirected to an e-commerce website, which is having several products in its a catalogue and is suffering from path traversal vulnerability.

As to further, I’ve opened a product and checked out its the display image with a simple right-click as view image.

Now its time check what we could manipulate.

Tune in you burp suite to capture the ongoing HTTP Request and share it all with the Repeater.

As in the GET request, above in the image, you can notice that the filename=67.jpg, let's try to change this filename with

filename=../../../etc/passwd

Great!! From the below image, you can see that we’ve successfully grabbed the passwd file.

Blocked Traversal Sequence

There are situations when the developers end up the traversal process i.e. the dot-dot-slash or any subsequent sequence will not work in such case.

While getting to the second lab, I got the same issue i.e. the “../” sequence didn't work and I fail to capture the password file.

So let’s try to capture this request again in our burpsuite monitor.

From the below image, you can see that I’ve grabbed up the request with filename=66.jpg, and now will shift this all to the Repeater.

As we’re blocked with the “../” sequence. Let’s try to enter /etc/passwd without any preceding values.

Cool!! This worked, we got the passwd file with the direct call.

Validated Path Traversal

Many developers validate their web-applications, that if the “../” comes into the URL, it gets rejected out. Thus when we tried both the above procedures in our next lab, we got rejected out and didn’t get anything.

Therefore we capture the HTTP request in our burpsuite and traverse it to the Repeater.

This time we manipulate the URL filename parameter with “double dots followed by double slashes” i.e. “….//….//….//etc/passwd”

Great!! From the above image, you can see that we’ve again captured the password file with this unusual technique.

As we jumped over the 4^th lab, we got this, the developers had made a validation which blocks up the input which contains the path traversal sequence.

Therefore in order to bypass this validation, I’ve again captured the request and send it to the repeater, to make some manipulations.

From the below image, you can see that, I’ve manipulated the URL filename parameter and have successfully accessed the password file with

 filename=..%252f..%252f..%252fetc/passwd

Path Disclosure in URL

Isn’t it great if you get the number of back steps you need to perform in order to capture your desired file?

Path disclosure is that vulnerability, where the URL offers the complete path of the file it is containing, which thus allows the attacker to simply manipulate the URL and with no efforts he can access the system files.

As we moved further to lab 5, we were encountered with an application that was offering us the complete path of the file.

We simply just captured that request and send it to the repeater. From the below image, you can see that the filename parameter is having the vale as “/var/www/images/21.jpg”. Which means that the image is inside the images directory and the root directory is just 3 steps away from us.

As we are now aware of the number of back steps we need to make to get into the password file so we’ll do that as

filename-/var/www/images/../../../etc/passwd

Null Byte Bypass

Many developers add up a ‘.php’ extension into their codes at the end of the required variable before it gets included.

Therefore the webserver interprets the /etc/passwd as /etc/passwd.php, thus we could not access the file. In order to get rid of this .php we try to terminate the variable using the null byte character () that will force the php server to ignore everything after that, as soon as it is interpreted.

As soon as we share the captured request to the repeater we’ll try to eliminate this null byte character as discussed above.

So from the below image, you can see that we’ve again captured the password file by adding up () in the URL as :

filename=../../../etc/passwd.jpg

Windows Server Path_Traversal Exploitation

It’s not necessary that every time we encounter with an application which is running over a Linux server, thus there are chances that our luck didn’t work and we got stuck with a window’s server.

Let’s learn the different sequences and the method that can be used during such situations.

I’m having DVWA setup over my window’s machine. You can learn this all from here.

Now its time to boot inside the DVWA application as “admin: password” with the security level as “low”. Further, choose the vulnerability as File Inclusion from the left-hand panel.

As soon as we choose this, we’ll be redirected to the webpage which is suffering from path_traversal vulnerability.

Let’s capture this request through burpsuite and see what we can get through it.

From the above image, you can see that file.php is included in the page parameter. Let’s share this all to the repeater and will try to play with this field.

In order to call up the windows file on the web-applications screen, manipulate the page parameter with the following input.

page=C:/Windows/win.ini

From the above image, you can see that we’ve successfully called up the file in the repeater. Now forward this request and check the result over the application’s screen.

Whether the application is hosted over a linux server or a windows one, the developers always validate their web-applications, but yes these validations are somewhere common.

Let’s check out some validations implemented by the developer and try to bypass them.

Double dots with Forward-Backward Slashes

In order to keep the application secure with the path traversal attacks the developers blocks up to some sequences such as “../”, which thus gets rejects out automatically if entered in the URL.

Increase up the DVWA’s security level and set it to “medium”. Capture the request at burpsuite and send everything directly to the repeater.

Form the below image, you can see that we’ve successfully bypassed this validation by the dots followed by the forward-backwards slashes and have again grabbed the “win.ini” file by :

page=…./\..../\..../\..../\..../\Windows/win.ini

Using a similar sequence you can even capture other files present in the windows system. From the below image you can see that I’ve grabbed up a flag i.e. fi.php which resides in the hackable folder by simply manipulating up the URL parameter as :

page=…./\..../\hackable/flags/fi.php

There are many situations when such conditions didn’t work, that is the developer validates and block every possible sequence he can.

Let’s find out is there any other possible way to get the “win.ini” file without getting involved in the commonly used sequences.

Again go for the security option and hit it up with the high security in your DVWA application.

Come back to the File Inclusion section and capture the request in your burpsuite.

Share the HTTP request to the repeater tab and manipulate the URL page parameter with :

page=file://C:/Windows/win.ini

From the below image you can see that we have captured the “win.ini” file by entering the complete path to it in the URL parameter.

Let’s now try to capture the flag with the same procedure as :

 page=file://C:/xampp\htdocs\dvwa\hackable\flags\fi.php

Great!! We have grabbed this hackable flag too.