Testing for LFI
Last updated
Last updated
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.
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 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
First find the log file path and attempt to curl to 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
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 the SESSION_ID using 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 PHPSESSID and the value. In my case, the value is vc4567al6pq7usm2cufmilkm45.
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.
Try to ssh into the box with a PHP code as username .
Then include the SSH log files inside the Web Application.
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.
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/status and /etc/passwd and try to access /<HOME>/.ssh/id_rsa.
Automate LFI Tests
Download the traversal.txt file in this folder (from PayloadAllTheThings)
Test with wfuzz
grep 200 for the Ok status code
w -> the wordlist
https://www.aptive.co.uk/blog/local-file-inclusion-lfi-testing/
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion#lfi-to-rce-via-phpinfo
We notice the request with a ? indicating possible LFI but we are not sure the paramater it wants
Attempt to fuzz the parameter for command injection and file inclusion
Wordlist to use:
-mc all to match all status codes if you are getting every page 404 or something like that
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
