Finding Path Traversal Vulnerability

Finding Path Traversal Vulnerability

by Harshit Sharma


Local File Inclusion (LFI) also known as path traversal is a vulnerability that can potentially allow an attacker to view sensitive documents or files from the server. It can also lead to Remote Code Execution, Denial of service but before jumping on what local file inclusion or lfi is, let’s understand how modern-day web applications handle application files.

File Handling or Inclusion Functions

Web applications may use files or may include code or view text from files present or hosted on the same server. In order to do that web applications may use a file reading mechanism, For the sake of this blog let’s just call the parameter which includes or reads server files as file inclusion function.

For Example:

In the above code, the “filename” parameter’s job is to read content from the file present on the server and this action of reading file can be influenced by the user. While writing the code the intention of the developer would have been just to manage a user selection and input file or content from files present on the same server, What the developer would not have thought of is that the amount of control he may be giving away to the user. If you observe closely an attacker can abuse the function or feature to ask for any file or to read sensitive data from the server.

NOTE: This is a sample Python script, a similar server-side script can be written to do the same.

So depending upon a web application to another the implementation can vary and it can either be a GET method or it could be a POST method. The question is how can a user or a pentester find out these so-called inclusion functions. It is fairly easy to find such inclusion functions during the recon phase or general browsing through the web application would the job.

Given Below are the URL’S which have the so-called “inclusion function” as GET method requests.

http://www.test.com/user/page=one.php
http://www.test.com/index.php?file=content
http://www.test.com/main.cgi?home=index.html
http://www.test.com/main/index.html

Note: It is not always necessary that the url will have an inclusion function you just need to assume that you might be in web server root directory or web document directory.

and POST requests could look something like this:

COOKIES!!

So Cookies are an integral part of a web application that helps in making HTTP protocol stateful and do a few other tasks if you want to learn about cookies and session read my previous blog, But Coming back to this “one more thing”. Well It turns out cookies can also be used to dynamically generate pages or templates.

Example:

This means that cookies are also in scope for testing for path traversal or file inclusion vulnerability and how do you do that, Well that will come in a bit...

Why does this Vulnerability Occur?

Now you know many applications use this so-called inclusion functionality to manage images, templates, code, static text. The problem arises when these input parameters or inclusion functions are improperly validated. Attackers take advantage of this and are able to pass payloads(known file paths) which could result in sensitive data leaking out as the inclusion function has the ability to read any file from the server, It can even allow attackers to a remote shell of the server.

How to Hunt Local File Inclusion?

Finding Path Traversal vulnerability is fairly easy, in order to find such a vulnerability one should be able to perform the following tasks.

  • Enumerate inclusion functions
  • Test the enumerated inclusion functions

Well How can one enumerate inclusion function?, It’s easy you just need to keep the following question in your mind.

  • Where are the inclusion functions or file-related parameter in the URL or request body?
  • If you can see unusual file extension in the URL or request body?

Example

http://www.test.com/haha?file=index.html

When you are able to find the inclusion function test it!

Example:

http://www.test.com/haha?file=/etc/passwd (known file path)

or

http://www.test.com/main/../../etc/passwd

It is not necessary that you only have to enter “/etc/passwd” you can use all possible guesses for directories and file paths, One can also use “../” to jump back or move to a particular directory.

It is important to keep one thing in mind and that is the recon phase is important for example /etc/passwd file path exists in most Linux and it makes sense when you test the payload on an application running on a Linux server. However, it makes no sense if use “/etc/passwd” payload on an application running on an IIS server as the file does not exist in IIS server. So in layman terms, you need to be agile enough to ask the inclusion function for the file that could possibly exist in that environment.

Each operating system has a different path separator.

Example:

Unix/Linux

Root Directory: “/”

Directory Separator: “/”

Windows

Root Directory: “<drive letter>:\”

Directory Separator: “\”

Let’s Watch it in Action

For testing or practice, you can pick any of the vulnerable apps out there OWASP BWA or DVWA whichever you like. I chose OWASP SKF and Mutillidae and for the demo.

Testing for LFI on Mutillidae Test Case -1 GET Method

In the above test case, it was quite easy to find the file inclusion function and pass on a file path.

Testing For LFI on OWASP SKF Test Case -2 POST Method

This test case has a POST request and all that was required to perform lfi was to tamper with the request body and request for the file. However, this would not be the case in every other lfi hunting instance.

Testing For LFI on OWASP SKF Test Case -3 POST Method(Bypassing Filtered input)

The goal of different test cases is quite simple and that is that the readers of this blog are able to build an aptitude to hunt file inclusion vulnerability. In the above test case, the developer has implemented a filtering mechanism to filter out “../” so if we fool the logic and modify our payload so that after being filtered out it still makes sense then we will be able to get the data. Instead of using “../../../etc/passwd”, I used “…/./…/./…/./etc/passwd so all “../” will be filtered and in the end we will get the data.

Testing For LFI on OWASP SKF Test Case -4 POST Method

In this test case, the webserver completely denies all possible combinations of the payload and in the end, the payload is double URL enoded only then the server accepts and gives us the data. So again this is one such scenario to test, So you might have to encode or double encode your payload.

Pro Tip: Developers do not expect every form of encoding so they only implement a basic form of encoding. If your payload fails at the first attempt then try harder and keep fuzzing keep changing your payload. You can also use Unicode/UTF-8 encoding if the server accepts UTF8 sequences.

Testing For LFI in Cookies Test Case -5

Testing for path traversal on cookies remains as same as it is for inclusion functions in URLs or POST requests. Refer to the below-given image to understand how to test.

DotDotPwn

It is actually hard to guess all possible payload or file paths for different environments. Don’t worry I got you !!. DotDotPwn is an amazing directory/path traversal fuzz tester. Fuzz Testing is a quality assurance technique that involves sending random data input in massive amounts and get an unexpected response, So DotDotpwn helps with Fuzz or test most of the possible file paths and It also has a feature to that lets the pentester determine the depth of traversal and you also get the option to choose payload according to the os environment and it also supports multiple protocols.

Step 1 Open Terminal type: dotdotpwn [space] — help

Step 2 choose the target and protocol and type the relevant attributes in the command in my case, I tested this tool on Mutillidae and I passed the following command

dotdotpwn -m http -h 172.16.111.134/mutillidae/index.php?page=

Step 3 Hit Enter to launch

and the tool will do all the fuzzing.

LFI vs RFI or Are they Same?

A path traversal attack is also known as “directory traversal”, “dot-dot-slash”, “directory climbing”, “backtracking” and local file inclusion. Lets clear the fuss and understand what Local File Inclusion actually is and then we will jump to Remote file Inclusion.

Well, both of the vulnerabilities are file inclusion vulnerabilities, it’s just how the inclusion function is exploited.

In Local File Inclusion, the inclusion function leaks unintentional files present within the server or files that are local to the server. In Remote file inclusion, the attacker passes a URL or file path of a malicious file present in some remote server and the inclusion function loads the malicious file and runs it on its own server and this could result in a remote shell or an XSS attack or maybe the attacker uploads a shell file which allows him to browse directories and whatnot.


About the Author

Harshit Sharma, Security Researcher | Web App Pentester | Cloudsec | Guest Trainer @ Delhi University and Ansal University | @_harshitsharma


The article has been originally published at: https://medium.com/bugbountywriteup/finding-path-traversal-vulnerability-e2506d390569

June 1, 2020
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013