What is Local File Inclusion (LFI)?
Hello everybody and welcome to another NeuraLegion blog post!
Today we will be discussing Local File Inclusions, LFI for short. First things first, what are file inclusions? File inclusions are a key to any server-side scripting language. Web applications’ code is maintained by file inclusions. What does a hacker do with a Local File Inclusion? They mostly use it to extract information from a server. Nothing particularly malicious in its nature. Nevertheless, the information stolen can be sensitive. A world of opportunity opens up to a hacker when they obtain sensitive information.
As LFIs help an attacker trick a web application into either running or exposing files on a web server, an LFI attack can lead to Cross-site Scripting and remote code execution (RFI for short) vulnerabilities.
How do Local File Inclusions work?
When an application uses a file path as an input, the app treats that input 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 PHP script (web shell for example). The main issue occurs when the user then runs the web application which in turn allows the hacker to run any server-side malicious code they want. Just keep in mind that this isn’t always the case as having the ability to upload a malicious file to the application isn’t very common. There’s also no sure way to guarantee that the app saves the file on the server where the LFI vulnerability is located.
Scenarios Where Local File Inclusions Are Used
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:
Can be changed to look like this:
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.
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:
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.
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:
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.
An Exploited Local File Inclusion Vulnerability and its impact
As you can see, Local File Inclusion vulnerabilities present varying degrees of risk. Sometimes it’s only information disclosure, other times your whole system is in danger. The problem lies in the fact that LFIs allow hackers to obtain all kinds of information, which get misused to inflict further damage or locate and exploit other more dangerous vulnerabilities. Local File Inclusion vulnerabilities are a problem that can cause disastrous results.
The prevention of Local File Inclusion
Local File Inclusion can be devastating. There is a reason it was listed in the OWASP top 10 list. This brings us to some suggestions that can help you with your LFI issues:
– ID assignation (save your file paths in a secure database and give an ID for every single one, this way users only get to see their ID without viewing or altering the path)
– Whitelisting (Use the verified and secured whitelist files and ignore everything else)
– Use databases (Don’t include files on a web server that can be compromised, use a database)
– Better server instructions (Make the server send download headers automatically instead of executing files in a specified directory)
How NexDAST can help you find LFI vulnerabilities
The solution to many problems, NexDAST. Want to scan your web application and make sure no one tinkered with the code and tried to use Local File Inclusion to steal sensitive information or exploit Cross-site Scripting and remote code execution (RFI for short) vulnerabilities? NexDAST is perfect for this job. It’s an automated black-box security testing solution that scans your entire application on its own, identifies any vulnerabilities, then notifies you of their existence and tells you how to remedy them as well. No need to waste manpower and money on manually looking for LFI vulnerabilities, NexDAST finds them for you and tells you how to fix them as is shown in the example below:
NexDAST shows the original part of the code in red. The green part of the code is the one that was altered by someone. Our tool also provides remedy guidelines so that the LFI vulnerability can instantly get remediated by the developer or someone from the SecOps team. Want to find out more about NexDAST? We’ve covered it in-depth in one of our blogs before, and if you have a problem that NexDAST can help with, request a demo here!