Let’s talk about Local File Inclusion

Local File inclusion

Welcome back to our blog series on the top reported vulnerabilities in our Bug Bounty and CVD programs! Today we are diving deeper on Local file inclusion and discussing its impact, severity and ways of prevention and mitigation.

But first of all, what is Local file inclusion?

Local file inclusion (LFI) is a vulnerability where an attacker can manipulate input in such a way that files that exist on the web server are included for processing. Often, this is done through the exploitation of insecure ways of including files in the application.

For instance, this can happen when a page receives the filename or path which has to be included in a way that can be manipulated by the attacker. An example of this is as an URL parameter. A local file inclusion vulnerability exists when this input is not filtered or checked, and the attacker can retrieve different files than intended by changing the input.

An example of this would be: https://greatbank.com/get.php?module=contact.php which includes the contact page. If the input for the module parameter is not validated on the server, an attacker can use this to include other files present on the server. While this vulnerability can exist in any type of application, it is most commonly seen in applications that make use of scripting at run time such as those built in PHP, JSP, and ASP.

Impact

Information disclosure

The impact of the successful exploitation of a Local File Inclusion vulnerability can give an attacker access to files they normally wouldn’t have access to. When the file inclusion can be combined with path traversal an attacker can move through directories on the server, and this way also access files outside the web root. For example, the ‘passwd’ file which stores sensitive information such as the list of the system accounts and in rare cases even password hashes. Other files an attacker would look for are for example configuration files or source code. These files can contain sensitive information such as credentials or keys that should remain private. Path traversal can be done by injecting ../ sequences into the vulnerable parameter to move up the directory tree as shown in the example below.

Remote code execution

A Local File Inclusion vulnerability can lead to Remote Code Execution when it can be combined with other vulnerabilities. For instance an upload functionality that saves the files outside the web root because the application won’t normally need to serve them back to the user, an attacker could upload malicious code, but without a way to  execute this file, the insecure upload is of no use to the attacker. This combined with a LFI vulnerability would allow the attacker to retrieve this file and execute their payload.

For this to work, an upload form needs to be present on the website and accept (or be manipulated into accepting) executable code. If the attacker knows the path to where the uploaded files are stored, they can use the LFI vulnerability to include and execute their script. This code execution could then be used to connect to a listener set up by the attacker and they get what is called “a reverse shell” as shown in the example below.

Severity

The severity of a Local File Inclusion vulnerability depends on the impact. A vulnerability that can use path traversal to get to etc/passwd or read secrets in config files or the source code will have a high or critical severity. Because these files contain sensitive information that could allow an attacker further access to the system. Another example of when this vulnerability has a higher severity is applications that store sensitive information about its users in files, for instance uploaded documents with Personal Identifiable Information. If the attacker can gain access to these uploads from other users the consequences are serious.

LFI vulnerabilities where only limited information on a server is found often have a low severity.

A LFI vulnerability that can be escalated to remote code execution will have a critical severity as this compromises the entire server. 

Prevention

A way to prevent LFI vulnerabilities is by assigning all files that are allowed to be included a unique ID, and then referencing them by this ID. This ID is shown in the URL instead of the filename, and requests that do not use a correct ID will simply not include a file. 

Mitigation 

Make sure that there are no pages that show file paths like debug pages. The disclosed file paths can be used with a LFI attack to get information from those directories.

Local file inclusion is generally a known vulnerability in PHP web frameworks. Older versions have many known LFI vulnerabilities and in some cases bypasses of earlier patches that address this vulnerability.

One example of such a known vulnerability that is patched in PHP 5.3.4 and above is the null byte technique. By adding %00 to the end of an URL, everything after this gets disregarded by the web application. This can be used to bypass a simple blacklist that filters files with a .php extension. 

Keeping the framework and other software updated and patched is always good advice and will help prevent LFI and other vulnerabilities.

We hope you found this information useful, and we have far more interesting insights on the top reported vulnerabilities that still yet to come! Stay tuned for the upcoming blog!

References

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion

O