Directory path traversal VS file inclusion vulnerabilities

For many years, one of the most confusing vulnerabilities for both security professionals and clients in the industry is the Directory path traversal and the file inclusion (LFI/RFI). So what is the difference between these two vulnerabilities?

The main difference between a Directory path traversal and the file inclusion vulnerabilities is the ability to execute the source codes that are not saved in interpretable files (like .php or .asp and others).

In this blog post I am going to explain in detail with examples from multiple technologies both vulnerabilities and when do they happen. So, if you want to know more about this subject, then just keep reading.

What is a Directory path traversal vulnerability?

Definition

Directory path traversal vulnerability happens, when the application or the webserver gives the user the ability to read files in an internal system location that is not supposed to be accessible. This ability to read those files gives the attacker a way to read some critical files and perform remote code execution in some cases.

The impact of this vulnerability is in most cases not direct, as most of the time, all we can do with this vulnerability is to read files. Reading the files is used to gather critical information about the application or system functionalities and possible hidden vulnerabilities. However, combined with some configuration vulnerabilities, this vulnerability could become as much dangerous as file uploads or others. In fact, it can be used to perform what we call a remote code execution, which is the most critical vulnerability type and exploitation in the industry.

Let me give you some exploitation scenarios of this vulnerability to better understand the severity of this vulnerability.

The first scenario is giving the www-data user to directly access the /etc/shadow file. Having this configuration vulnerability combined with the directory path traversal, an attacker could easily read the shadow file. After that, the attacker could perform what we call a bruteforce attack against that file to find the root password.

The second scenario is related to configuring the Mysql DBMS in a known and default path. Successful exploitation of the directory path traversal vulnerability in this situation will give the attacker the ability to access any database tables and possibly read the admin login and password of the app.

To be honest, this second scenario is getting more and more rare, as most newer versions are taking this kind of attack into consideration. Therefore, they force administrators to create some random folder names or doing it automatically.

Known examples

In this section, I would like to talk about a realistic vulnerability that existed in the history of webservers and which was successfully exploited by black hat hackers in the wild.

This popular directory path traversal vulnerability was discovered in 2010 in the QuickPHP Web Server version 1.9.1. Moreover, it was exploited by attackers to read any file in the Windows file system including the SAM file.

What to do to prevent it

Now to protect your web application against this vulnerability you should do this:

• Keep your web server updated with the last patches
• In a web application always work with a whitelist

What is a File inclusion vulnerability?

Definition (talk about types)

A file inclusion vulnerability happens when user input is directly used in a file inclusion instruction without any filtering. You need to know that this vulnerability has two types:

• Local file inclusion (LFI), happens when the application only allows the attacker to include local files
• Remote file inclusion (RFI), happens when the application and the web server give the user the ability to include some remote source code, and this is even worst (I will explain why in detail in the next section).

Note:

The remote file inclusion vulnerability is getting more and more rare, as remote inclusion is being disabled by default in the webserver. However, some developers in some situations need to use remote inclusion.

Source code examples

Now let me give you some practical source code examples to have an idea about how this vulnerability looks like and to be able to identify it in your source code. However, if you are not a developer or you already have an idea about that you can skip this part of the post.

In PHP:

Include(“/uploads/”.$_GET[‘page’].”.php”);

In ASP.NET:

string filename = Request.QueryString["page"];
string sBasePath = System.Web.HttpContext.Current.Request.ServerVariables["APPL_PHYSICAL_PATH"];
if (sBasePath.EndsWith("\\"))
        sBasePath = sBasePath.Substring(0, sBasePath.Length - 1);
sBasePath = sBasePath + "\\" + ConfigurationManager.AppSettings["FilesPath"] + "\\" + filename; 
Response.AddHeader("content-disposition", String.Format("attachment;filename={0}", filename));
Response.WriteFile(sBasePath);

In Java:

<jsp:include page="<%=(String)request.getParameter(\"template\")%>">

What to do to prevent it

Preventing this vulnerability is not trivial to put in place especially for the LFI type. The only correct way to fix this vulnerability is by using the whitelists. Therefore, a list of all the possible file names should be put in place to verify the user input against it before using it.

Now let me explain something here, I have noticed that most developers think that this whitelist of files names should be hardcoded. But, in case the file names are dynamically generated by the web application (not the users) but are not predictable, they think that in this case there is no solution.

Well, you are wrong, there is always a solution. In this case, you can create a table or column (depending on your structure) in your database and store the file names there. Then each time a user send you a file name you compare this file name with the list you have stored in you database.  

Which one is the most dangerous and why?

Now let’s analyze which vulnerability is the most critical and why. Personally, when I start talking about this aspect and I want to have a precise estimation of the severity of any discovered vulnerability, I usually use the methodology I have explained here. However, when I just want to have a quick idea about it I take into consideration the two most important aspects for me:

1. The impact of a successful exploitation
2. The exploitation complexity

Therefore, here is my analysis about these two vulnerabilities.

For the directory path traversal, in most cases, successful exploitation gives simply the ability to read files. In addition, to get remote code execution from a directory traversal more advanced techniques are used. However, a successful Remote File Inclusion vulnerability exploitation always gives a Remote code execution. In addition, the exploitation is very easy and in most cases does not need any authentication.

Therefore, it is very obvious that a File Inclusion is more dangerous than the directory path traversal.