File Inclusion/Path Traversal
Ability to include files and resources within the web page via parameters (not correctly programmed).
Tools
curl --path-as-is --data-urlencode [-G (get)]
Test Local File Inclusion Vulnerabilities.
python3 liffy.py http://<DOMAIN>/?<PARAM>= <OPTIONS>
Functions
include()/include_once()
✅
✅
✅
require()/require_once()
✅
✅
❌
file_get_contents()
✅
❌
✅
fopen()/file()
✅
❌
❌
fs.readFile()
✅
❌
❌
fs.sendFile()
✅
❌
❌
res.render()
✅
✅
❌
include
✅
❌
❌
import
✅
✅
✅
@Html.Partial()
✅
❌
❌
@Html.RemotePartial()
✅
❌
✅
Response.WriteFile()
✅
❌
❌
include
✅
✅
✅
Local File Inclusion (LFI)
Files to try to read:
Linux:
/etc/passwdWindows:
C:\Windows\boot.iniorC:\Windows\win.ini
It is possible to try different payloads of SecLists, in particular LFI-Jhaddix.txt.
Bypassing Filters
....//....//....//
Regex
%2e%2e%2f%2e%2e%2f
Encoding (../../../../)
%25%32%65%25%32%65%25%32%66
Double Encoding (../../../../)
../../<FILE>%00.png
Null Byte (PHP <5.5)
<PATH>/../../<FILE>
Forced initial path
Read Source PHP
If you include code that is interpreted and executed, but instead want to read the source, you can use wrappers and filters.
In particular try to read the main PHP configuration file: php.ini
In this file you can see if allow_url_include is enabled.
Is usually located in:
Apache :
/etc/php/X.Y/apache2/php.iniNginx:
/etc/php/X.Y/fpm/php.ini
Where X.Y is the installed PHP version (try brute force)
RCE PHP
Require allow_url_include.
Allows you to include external data, including php code and execute it. Possibility to pass it the code as base64.
Similar to the data wrapper but uses POST requests, useful in case the server only uses POSTs.
Dedicated to execute commands but it is external, it must have been installed manually.
(Check the presence of extension=expect in php.ini)
Remote File Inclusion (RFI)
The file is loaded from a remote server.
In php this is disabled by default, require allow_url_include.
In Windows, however, you can use SMB to enable the remote file without allowing_url_include.
This is because Windows treats files on remote SMB servers as normal files, which can be referenced directly with a UNC path (//server/share/file). This technique is more likely to work if we were on the same network, since access to remote SMB servers over the Internet may be disabled by default, depending on Windows server configurations.
RCE
If the included file is executed, a webshell can be created according to the language being used by the server and hosted by making it public. Then upload it via the RFI.
Possible to apply SSRF techniques , such as port scanning etc.
File Upload + LFI
If there is the presence of file uploads on the site (even non-vulnerable ones) combined with LFI with a function that executes, then it is possible to exploit the uploaded files to obtain RCE.
Insert a real image (ex. gif) with simply a PHP piece containing the webshell inside.
Upload the file, get the path and use it in the LFI.
In this case we should upload a zip. Create a webshell to wrap a zip file and upload the zip, then access it via the zip wrapper in LFI. However, this wrapper is not enabled by default, and may not always work.
Similar result to the case with the ZIP, but via the phar wrapper.
Write the following PHP script
This script can be compiled into a phar file which, when called, will write a web shell into a subfile shell.txt, which we can interact with.
Compilation and renaming in shell.jpg
Log Poisoning
If the LFI functions have execution, you can try to poison the logs by injecting code (ex. php) and then reading them through the LFI.
Cookies can contain user-specific information in the backend. Examine the log file via the LFI to see what information it contains, and whether it can be poisoned.
Linux:
/var/lib/php/sessions/sess_<PHPSESSID>Windows:
C:\Windows\Temp\sess_<PHPSESSID>
Both Apache and Nginx maintain log files (access.log and error.log). access.log contains all requests made to the server, including User-agent, which can be manipulated by us. We use the latter to poison the logs.
It is necessary to have read access to the logs.
Nginx by default makes logs readable by low-privileged users (like www-data), while Apache logs are only readable by high-privileged users (except for old or badly configured versions).
!!! Be aware that getting the payload wrong will block access to the logs.
access.log and error.log are located in:
Apache:
Linux:
/var/log/apache2/Windows:
C:\xampp\apache\logs
Nginx:
Linux:
/var/log/nginx/Windows:
C:\nginx\log\
They can change, see: WORDLIST
The User-Agent also appears on process files in the Linux /proc/ directory. So, we can try to include the files /proc/self/environment/proc/self/fd/N (where N is a PID usually between 0 and 50) and we might be able to perform the same attack on these files. This might be useful if we don't have read access to the server logs, however, these files might only be readable by privileged users.
There are other similar log poisoning techniques that we could use on various system logs, depending on which logs we have read access to.
Some of the logs we could read:
/var/log/sshd.log/var/log/mail/var/log/vsftpd.log
Last updated
Was this helpful?