Recently, I was preparing some Remote File Include (RFI) demo for one of my Web Application Security class. I headed straight to my favorite vulnerability tracking site and picked out the first 3 Opensource packages that are vulnerable to RFI. After downloading the vulnerable version of the applications, I got them loaded on my test web app server. This script kiddie is ready for some pwning actions!

It wasn’t even ten minutes into testing that I noticed none of the exploits were working, this is not just one Opensource package, but three, something must be wrong. Time for some kung-fu to kick in, I first inspected the PHP environment using the phpinfo() function call which display everything under the Sun about the running PHP environment. Everything looks as vulnerable as it should be,
allow_url_fopen = On
register_globals = On
[PHP version < 5.20, so allow_url_include option not available yet, otherwise I would check that as well]

Please note these settings are very insecure, don’t try this at home!  :-)

Everything in PHP looked fine to me, the problem might be elsewhere. I started digging into the code to see what the problem is. In the supposingly vulnerable PHP file, I have the follow lines of code at the beginning of the file,
include (‘config.php’);
include(“lang/”.$lang.”.php”);

The exploit inject PHP commands into $lang. From the looks of it, exploit should work as the $lang is a variable that could potentially be user input. More digging required.... The whole thing became clear when config.php was inspected, in the config.php, there is a line,
$lang = “english”;

That explained why exploit attempts did not work, $lang is statically defined within the program code, the user input of $lang can be global variable but it is overwritten by the static definition. The code certainly look suspicious but this one is not RFI. I inspected the other OpenSource packages I downloaded, they are all NOT vulnerable due to similar control in place.

I have also found some previous mis-reported “RFI vulnerabilities” (see links below). These are all reported in most major vulnerability tracking sites.
http://seclists.org/bugtraq/2007/Jul/0380.html
http://seclists.org/bugtraq/2007/May/0421.html
http://seclists.org/bugtraq/2007/Jun/0124.html
http://seclists.org/bugtraq/2007/Jun/0122.html

RFI is definitely a very serious web application security issue, don't let all these false positives make you think otherwise. Moral of the story is, use discretion when handling vulnerability information. Perform proper testing with any potential vulnerability, understanding how vulnerability works is the key to handling these information properly.

-----------
Jason Lam