4Noobies — Local File Inclusion (LFI)
If you are starting in the security field you may have heard about the Local File Inclusion (LFI) attack. In this short article I’ll show you the basics and some hands on exercises!
What is it?
Local File Inclusion (LFI) is a technique that consists in the usage of files that already exists in the web server of the victim, for example: a .php file that maps another existing file in the web server. This issue is triggered due to a bad or none input handling (sanitization/filtering) of parameters, allowing the Trudy’s to read any existing file in our web server and finding valuable information stored in the system.
Why it is so dangerous?
One of the most used techniques once this vulnerability was exploited is to make use of the “directory path traversal” attack, in which the main objective is to access files and directories that are stored outside the web root folder. If it success they will be able to move in the web server while trying to find key files such as /etc/passwd or /etc/shadows (which are user files) to see if their modes (permissions) are properly set, if they are not, for example: rwx-rw-rw- (others and groups can write to this file) they will modify it and do a privileges scalation to get full access to the web server.
Technical details and practical example about LFI
In this practical example we are going to use our own web server using Apache2 in a ParrotOS VM and a vulnerable .php file to show in technical details how this LFI occurs and also how to solve this vulnerability!
1- Starting our Apache2 server
service apache2 start
service apache2 status
2- Creating the vulnerable file
cd /var/www/html
Here we will create an index.php file with the following vulnerable code
<?php
$filename = $_REQUEST[‘page’];
echo include($filename);
?>
This code is vulnerable because we are trusting the parameter given by the user with the $_REQUEST parameter and since we are not sanitizing the input we are able to read any file in the system.
Apart of that, we will create the hello.php file with a Hello world!! text on it, in plain text just for testing.
3- Testing our vulnerable web app
To make sure it is working we should put localhost/?page=hello.php which was the second file created. If you see the following message you are in the right path!
But why this code is vulnerable? Well… The entry is not sanitized and the user can request any existing file from the web server. Remember that we are doing an echo of the file that was filled in the URL like this /?page=<REQUEST>
4- Executing the directory path traversal
As you can see here we were able to scape and read other files from the web server. In this case we are reading the /etc/passwd file of the web server!!
5- In this example we are an unprivileged user
One thing to get in mind is that we are able to access to all those files in which other users or the user who own the server application (In this case apache) has privileges, in this case our user is wwwdata since it is the user who owns our apache server.
6- How to avoid LFI in this example?
There are different ways and obviously more robust ones! An easy way to show how to avoid this is to use include instead of $_GET or $_REQUEST so you can gather directly the resource and avoid the user to manipulate the request. Here is how this .php index will look (you can compare with the previous one). in this one we are hardcoding the file requested and avoiding the the manipulation of the URL to request a resource.
<?php
include(‘hello.php’);
?>
LFI in a simulated production environment
In this practical example I’ll be using the retired machine called Beeb from Hack The Box, so you can see the risk in a simulated production environment.
I will not enter into details how you can hack this box, but all you need to know in this example is that we already found an Elastix service which is an unified communications server software.
And here is how it looks, obviously we cannot login since we do not know the credentials… yet :)
1- We are going to use searchsploit to find the right Exploit to hack this system.
2- Then we are going to select graph.php Local File Inclusion Exploit
searchsploit -x php/webapps/37637.pl
3- And after reading the exploit we see this is how you can make use of the vulnerable grap.php file to do a directory path traversal attack
/vtigercrm/graph.php?current_language=../../../../../../../..//etc/amportal.conf%00&module=Accounts&action
4- So then we are going to paste that URL after the IP of the web server and there you go! We have a key file with users and passwords that we can use to log in via SSH or using the UI and gain access to the system!!!
5- Also you can check other files in the system, again /etc/passwd
Or maybe check the internal ports opened in the machine (/proc/net/tcp) but not exposed to the public as public services, and then parsing those from HEX to DEC format to understand what we have there ;)
How I can protect my systems?
The most effective solution is to avoid “trusting the user input” it means to avoid passing user-input to any filesystem instead you can use of “indexes” to search for the files and if an invalid index arrives it should be rejected and last but not least will be to apply the Principle of least privilege, in which we only assign those privileges needed to complete its task.
Conclusions
As you can see, if you understand how a vulnerability works it will be a little bit easier to patch and pay attention to simple things such as a bad handling of inputs without sanitization and their impact. Always try to go from basics as we did in this article so you can get a better understanding of this security world! Thanks for reading, hope you like it!
