Testing for LFI
LFI Local File Inclusion
Introduction
An attacker can use Local File Inclusion (LFI) to trick the web application into exposing or running files on the web server.
LFI occurs when an application uses the path to a file as input. If the application treats this input as trusted, a local file may be used in the include statement.
Example:
In the above example, an attacker could make the following request. It tricks the application into executing a PHP script such as a web shell that the attacker managed to upload to the web server.
Directory Traversal
Even without the ability to upload and execute code, a Local File Inclusion vulnerability can be dangerous.
An attacker can still perform a Directory Traversal / Path Traversal attack using an LFI vulnerability as follows.
Testing
If you see a webpage URL look like this:
Basic Linux Test
Test for:
PHP Wrappers
PHP has a number of wrappers that can often be abused to bypass various input filters.
PHP Expect Wrapper
PHP expect://allows execution of system commands, unfortunately the expect PHP module is not enabled by default
PHP Filter Wrapper
php://filter allows a pen tester to include local files and base64 encodes the output. Therefore, any base64 output will need to be decoded to reveal the contents.
First one will often fail because it attempts to execute the php code, thus converting to ROT13 or base64 will help achieve LFI
LFI to RCE via Log Posioning
First find the log file path and attempt to
curlto it
Should see the evidence of your test in the user agent string logged
Now post php code to the log file and then visit the log file location to execute the php code you just injected
LFI to RCE via PHP Sessions
The LFI to RCE via PHP sessions follows the same concept of the log poisoning technique.
PHP sessions are files within the operating system that store temporary information. After the user logs out of the web application, the PHP session information will be deleted.
This technique requires enumeration to read the PHP configuration file first, and then we know where the PHP sessions files are.
Then, we include a PHP code into the session and finally call the file via LFI.
PHP stores session data in files within the system in different locations based on the configuration. The following are some of the common locations that the PHP stores in:
Once the attacker finds where PHP stores the session file and can control the value of their session, the attacker can use it to a chain exploit with an LFI to gain remote command execution.
To find the PHP session file name, PHP, by default uses the following naming scheme,
sess_<SESSION_ID>where we can find theSESSION_IDusing the browser and verifying cookies sent from the server.To find the session ID in the browser, you can open the developer tools
(SHIFT+CTRL+I), then the Application tab.From the left menu, select Cookies and select the target website.
There is a
PHPSESSIDand the value. In my case, the value isvc4567al6pq7usm2cufmilkm45.Therefore, the file will be as
sess_vc4567al6pq7usm2cufmilkm45. Finally, we know it is stored in/tmp.Now we can use the LFI to call the session file.
RCE via SSH
Try to ssh into the box with a PHP code as username .
Then include the SSH log files inside the Web Application.
RCE via Apache logs
Poison the User-Agent in access logs:
Note: The logs will escape double quotes so use single quotes for strings in the PHP payload.
Then request the logs via the LFI and execute your command.
LFI to RCE via credentials files
This method require high privileges inside the application in order to read the sensitive files.
Windows version
First extract sam and system files.
Then extract hashes from these files samdump2 SYSTEM SAM > hashes.txt, and crack them with hashcat/john or replay them using the Pass The Hash technique.
Linux version
First extract /etc/shadow files.
Then crack the hashes inside in order to login via SSH on the machine.
Another way to gain SSH access to a Linux machine through LFI is by reading the private key file, id_rsa.
If SSH is active check which user is being used
/proc/self/statusand/etc/passwdand try to access/<HOME>/.ssh/id_rsa.
Automated LFI with Wfuzz
Automate LFI Tests
Download the
traversal.txtfile in this folder (from PayloadAllTheThings)Test with
wfuzz
grep 200for theOkstatus codew-> the wordlisthttps://www.aptive.co.uk/blog/local-file-inclusion-lfi-testing/
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion#lfi-to-rce-via-phpinfo
Wfuzz for LFI with a Cookie
Requests to look out for
We notice the request with a
?indicating possible LFI but we are not sure the paramater it wantsAttempt to fuzz the parameter for command injection and file inclusion
Wordlist to use:
Use FFuF, or wfuzz
FFuf Fuzzing for subdomains
Notice that you will get back responses with a similar character count, these are often the ones that will fail, to make the output more readable, filter on the bad character count and look for one with a unique character count.
Another ffuf example
In this example we know the first part of the subdomain used by the company, however we need to bruteforce the second half of the sub domain.
ffuf Filter out 302 redirects when looking for subdomains
Sometimes the web server will 302 your request when bruteforcing for subdomains.
First create a new burp listener as such
Now you can use the below command and throw all the requests through the burp proxy to view the requests
Browsing to burp, we can see all the requests and the 302 redirects. Try and figure out what stands out, if most requests are 302's look for 404's or other status codes
Apply our filter removing all 302's
Below is a command to filter the status code without using a burp proxy
FFuf API endpoints
Ffuf with burp Request
-mc all to match all status codes if you are getting every page 404 or something like that
Files to grab if you get LFI
Bypassing Path normalization
If you make a request in the browser to:
And you notice when you make the request the website path goes back to:
Use Burp Suite repeater to make the request manually
Last updated
