Introduction

Local File Inclusion (LFI) is a type of attack where the web application is tricked into running or displaying local files on the server. File inclusions are a key to any server-side scripting language. They are needed to keep web application code tidy and maintainable. They also allow web applications to read files from the file system, provide download functionality, parse configuration files, and do other similar tasks. However, if not implemented properly, attackers can exploit file inclusion capabilities to craft an LFI attack that may lead to information disclosure, cross-site scripting, and remote code execution (RCE).

Working

When an application uses a file path as an input, the app treats it as trusted and safe. A local file can then be injected into the included statement. This happens when your code is vulnerable. In this case, a hacker makes a request that fools the app into executing a malicious script (web shell for example).  In some cases, if the application provides the ability to upload files, attackers can run any server-side malicious code they want.

Here is an example of how LFI can enable attackers to extract sensitive information from a server. If the application uses code like this, which includes the name of a file in the URL: https://example-site.com/?module=contact.php. An attacker can change the URL to look like this: https://example-site.com/?module=/etc/passwd . And in the absence of proper filtering, the server will display the sensitive content of the /etc/passwd file.

Scenarios Where Local File Inclusions Are Used

1. Including Files to be Parsed by the Language’s Interpreter

Developers usually divide a website’s code into directories, multiple files, etc. to make everything neat and readable. In order for an interpreter to find these files you need to designate the correct file path and then pass it to a function. The function then opens the file in question and includes it inside the document for the parser to be able to see it as valid code that can be interpreted.

What happens when there’s no effective filtering? Well, code like this: https://example-site.com/?module=contact.php can be changed to look like this: https://example-site.com/?module=/etc/passwd.

As you can see, the contact.php part of the code was replaced with /etc/passwd. Passwords, username information, the attacker can see the content of everything depending on what they are looking for. That’s not all, as more severe cases include the injection of code on the webserver. The parser then interprets this code as an instruction that can exploit an LFI vulnerability. Some hackers can use the Local File Inclusion vulnerability to stage a directory traversal/path traversal attack that in turn gives the hacker full access to error.log and access.log or some other type of sensitive meta-data.

2. Including Files that are Printed to a Page

A developer sometimes wants to share the output of a file across multiple web pages. A header. file or something similar. To keep things quick, a dev wants the change of this file to be seen on all pages where it was included immediately. This file, while standardly plain HTML, can also be used to display ordinary text files: https://example-site.com/?helpfile=login.txt. This way the content of the text file gets printed straight to the page. The information isn’t stored in any database. A hacker will exploit this and alter the link if no filter stops them. Then helpfile=login.txt becomes helpfile=../secret/.htpasswd and all of a sudden the hacker has access to the password hashes of a .htpasswd file. A file that includes all the credentials of any user that can access a restricted area of that webserver. Naturally, this information falling into the hands of a hacker is a terrible thing for a company and is a severe security threat.

3. Including Files that are Served as Downloads

Lastly, we have types of files that all web browsers automatically open. A PDF, for example. Users can configure this so the files get downloaded instead of shown in the browser window. That’s achieved by adding an additional header that tells the browser to do things differently. A simple Content-Disposition: attachment; filename=file.pdf addition in the request and now the files are downloaded instead of opened. An example would look something like this: https://example-site.com/?download=brochure.pdf.

An issue arises when the request isn’t sanitized. This way the hacker has the option of requesting the download of the base files (the building blocks of the web app). They can then read the source code and find other web application vulnerabilities, making that hacker an enormous threat to your cybersecurity.

Impact of Exploited Local File Inclusion vulnerabilities

The impact of a Local File Inclusion attack can vary based on the exploitation and the read permissions of the webserver user. Based on these factors, an attacker can gather usernames via an /etc/passwd file, harvest useful information from log files, or combine this vulnerability with other attack vectors (such as file upload vulnerability) to execute commands remotely. Let’s take a closer look at three possible outcomes of local file inclusion:

1. Information disclosure: Although not the worst outcome of a local file inclusion vulnerability, information disclosure can reveal important information about the application and its configuration. That information can be valuable to an attacker to gain a deeper understanding of the application and can help them detect and exploit other vulnerabilities.
2. Directory Traversal: A local file inclusion vulnerability can lead to Directory Traversal attacks, where an attacker will try to find and access files on the web server to gain more useful information, such as log files. Log files can reveal the structure of the application or expose paths to sensitive files. An incorrectly configured server can give attackers access to user config files, giving them access to other files on your server, or even gain administrator access.
3. Remote Code Execution: Combined with a file upload vulnerability, a Local File vulnerability can lead to remote code execution. In this case the attacker would use LFI to execute the unwanted file. To compound matters, an attacker can upload a file to the server to gain the ability to execute commands remotely, resulting in the attacker being able to control the whole server remotely.

Prevention

Here are a few ways to prevent LFI attacks:

• ID assignation: Save the file paths in a database and assign an ID to each of them. That way, users can only see the ID and are not able to view or change the path.
• Whitelisting: Use a whitelist of files and ignore every other filename and path.
• Use databases: Instead of including files on the web server, store their content in databases where possible.
• Better server instructions: Instruct the server to automatically send download headers and not execute files in a specific directory such as /download/. That way, you can point the user directly to the file on the server without having to write additional code for the download. An example link could look like https://example.com/downloads/brochure2.pdf