Atomicorp

Hello,

I'm currently "benchmarking" gotroot modsec rules for a potential live account in the future.

I have downloaded the lastest free rules set and running debian wheesy for the tests.
apache2 -v
Server version: Apache/2.2.17 (Debian)
Server built: Apr 10 2011 18:44:46

With libapache-mod-security_2.5.9-1_i386.deb (taken from mod security website)

I have included the following gotroot's rules : I haven't include the advanced rule set as i don't have a recent module version.
Most of the potential standart attacks are blocked like :
However i have test the following (very unsecure) php code : If i call the page with It actually "works", i got file listing of my root directory.

This call is blocked though : This king of attack is quite basic so i'm wondering why this GET call is working ?

Thanks in advance,
Greg

Thanks for the question, hard to say for sure as its a custom setup it could be a bug in the free rules or possibly in your config, but the real time rules catch it fine:

wget http://test3/code_inj.php?pageid=plop\; ... etc/passwd


[modsecurity] [client 10.31.45.91] [domain test3] [403] [/20110502/20110502-1608/20110502-160845-l0ZUh0rQm4UAAFimMycAAAAH] [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "224"] [id "340009"] [rev "47"] [msg "Atomicorp.com WAF Rules: Protected Path Access denied in URI/ARGS"] [data " /etc/"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "rx (alt_mod_frameset.php|checkout_shipping.php|^/components/com_zoom/etc/|/admin\\.swf\\?nick=|/editor/filemanager/browser/default/browser\\.html\\?(type=image&)?Connector=\\.\\./\\.\\./connectors|phpthumb/phpthumb\\.php\\?src=\\.\\./\\.\\./uploads|^/etc/ ..." against "REQUEST_URI" required.

wget http://test3/code_inj.php?pageid=plop\;ls%20/


[modsecurity] [client 10.31.45.91] [domain test3] [403] [/20110502/20110502-1622/20110502-162238-yN-VoUrQm4UAAF9iIdAAAAAH] [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "423"] [id "340029"] [rev "5"] [msg "Atomicorp.com WAF Rules: Command in Referer string"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Pattern match "; ?(cat|ls|perl|uname|pwd|cp|kill) " at REQUEST_URI.

$varerror = system('cat '.$_GET['pageid'], $valoretorno);

ASL alerts on this entire function as a vulnerability and will disable it:

With system allowed:

asl -s -f
Function system: allowed [HIGH]

With ASL configured to fix vulnerabilities:

asl -s -f
Function system: disabled [FIXED]

<?php
$varerror = system('cat '.$_GET['pageid'], $valoretorno);
echo $varerror;
?>

The Atomic clamav signatures pick this up as a potentially malicious script, so it wouldnt be possible to upload it:

[mshinn@test4 ~]$clamscan code_inj.php
code_inj.php: Atomicorp.PHP.raw.GET.into.system.20091214185624.UNOFFICIAL FOUND
----------- SCAN SUMMARY -----------
Known viruses: 3102995
Engine version: 0.97
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 16.936 sec (0 m 16 s)

And the ASL real time malware protection system will block any PHP script with a function like this from even running, no matter how it gets on the box:

[mshinn@test3 ~]$ cat code_inj.php
cat: code_inj.php: Permission denied

Mon May 2 16:28:07 2011 -> /home/mshinn/code_inj.php: Atomicorp.PHP.raw.GET.into.system.20091214185624.UNOFFICIAL FOUND

Thanks for the quick answer !

Is there any chance someone could test that trivial code injection with the free ruleset in order to know if it is a real bug or a problem with my config ?

It sounds weird to have this kind of attack working even with a free ruleset.

My apache's config is a (on purpose) default debian configuration, i just added the modsecurity details as specified in your wiki.

Thanks again,
Greg

Tough to say from just that, it could be something environmental preventing it from working correctly

I mean don't you have a testing machine with the free delayed rules installed on which you can test this sample php code ?

If it is a configuration issue my bad then, but if it is a bug in your free delayed rules, it might be interesting for you to make a fix.

Most of the attacks are blocked (xss, remote file, SQL injection, directory traversal, etc), so i guess my config is not completly broken.

Thanks,
Greg

PS : The issue is not only with the "ls" command, for example this call is working :
http://192.168.200.74:8080/code_inj.php ... =plop;echo evil > /var/www/uploads/file

It could be a bug in the unsupported/delayed rules, its definitely not an issue in the real time rules which means if there was a bug its already been fixed.

So if it is a bug in the unsupported/delayed rules you can wait until they catch up with the real time rules, or you can use the real time rules.

Good to know, thanks for the answers !

Greg