LOCAL FILE INCLUSION

Tanmay Deshpande July 02, 2021

 

What is Local File Inclusion?

Local File Inclusion is an attack technique in which attackers trick a web application into either running or exposing files on a web server. LFI attacks can expose sensitive information, and in severe cases, they can lead to cross-site scripting (XSS) and remote code execution. LFI is listed as one of the OWASP Top 10 web application vulnerabilities.

This vulnerability exists when a web application includes a file without correctly sanitising the input, allowing an attacker to manipulate the input and inject path traversal characters (such as ../) and include other files from the web server.

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.com/?module=contact.php

An attacker can change the URL to look like this:

https://example.com/?module=/etc/passwd

In the absence of proper filtering, the server will display the sensitive content of the /etc/passwd file.


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). 
In some cases, if the application provides the ability to upload files, attackers can run any server-side malicious code they want. Most applications do not provide this capability, and even if they do, the attacker cannot guarantee that the app saves the file on the server where the LFI vulnerability is located. The attacker will also need to know the file path to their uploaded file on the server file system.

Identifying LFI Vulnerabilities within Web Applications

Here are a few ways to test for LFI vulnerabilities in your web applications.

Basic Local File Inclusion

In order to perform the basic LFI attack, we’ll be manipulating the “URL language parameter” with “/etc/passwd” to access the password file present in the local system.

Initially: https://example.com/?module=contact.php

After manipulating: https://example.com/?module=/etc/passwd

If the above mentioned conditions are met, an attacker would see something like the following:
 
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...

Null Byte Injection

The terms “null character”, “null terminator”, and “null byte” all refer to a control character where the value zero is present in the reserved character sets used to mark the end of the string. The null byte ensures that any character following it is ignored. 

Typically, a null byte is injected as %00 at the end of a URL. Here is an example:

https://example.com/preview.php?file=../../../../../passwd%00

Path and Dot Truncation

The majority of PHP installations limit filenames to 4096 bytes. If a filename is longer, PHP truncates it and discards all additional characters. However, attackers can remove the 4096 bytes limitation from the .php extension, manipulating the process. In this case, no error is triggered, additional characters are dropped, and the PHP engine continues its execution.

Typically, attackers combine this bypass with other logic bypass techniques. For example, attackers might introduce double encoding, encode part of a file path with Unicode, or use other inputs that represent a valid filename.

PHP Wrappers

LFI vulnerabilities usually give attackers read-only access to sensitive data, granted from the host server. There are, however, ways to turn this read-only access into a fully compromised host. This type of attack is called Remote Code Execution (RCE). Attackers create RCE vulnerabilities by combining an LFI vulnerability with PHP wrappers. 

A wrapper is an entity that surrounds another entity (in this case – code). The wrapper can contain functionality added to the original code. PHP uses built-in wrappers, which are implemented alongside file system functions. Attackers use this native functionality of PHP to add vulnerabilities into wrappers.

Here are two commonly used wrappers:

  • PHP filter – provides access to a local file system. Attackers use this filter to read PHP files containing source code, typically for the purpose of identifying sensitive information, including credentials. eg: php://filter

  • PHP ZIP – this wrapper was designed to manipulate files compressed into a ZIP format. However, its behaviour enables attackers to create a malicious ZIP file and upload it to the server. eg: zip://

 
Impacts of an Exploited Local File Inclusion Vulnerability

As shown above, the impacts of exploiting a Local File Inclusion (LFI) vulnerability vary from information disclosure to complete compromise of the system. Even in cases where the included code is not executed, it can still give an attacker enough valuable information to be able to compromise the system. Even though old ways of exploiting the first scenario won't work anymore on most modern systems, e.g. including the access.log file, there are still some methods that can still lead to a complete system compromise through evaluated script code.

 
Preventing Local File Inclusion Vulnerabilities

Here are a few ways to prevent LFI attacks:

  1. 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.

  2. Whitelisting  – use verified and secured whitelist files and ignore everything else.

  3. Use databases – don’t include files on a web server that can be compromised, use a database instead.

  4. Better server instructions – make the server send download headers automatically instead of executing files in a specified directory.

 

I hope you guys have got a good idea about LFI after reading this. Thanks for reading.

0 Comments