mod_security RESPONSE_BODY

[yolte]

Hello,

I have a problem about mod_security RESPONSE_BODY rules;

Some mod_sec 2.x rules not working, for examlpe i have a rule set for blocking r57,c99 etc php shells;

SecRule RESPONSE_BODY "(?:<title>[^<]*?(?:\b(??:c(?:ehennemden|gi-telnet)|gamma web shell)\b|imhabirligi phpftp)|(?:r(?:emote explorer|57shell)|aventis klasvayv|zehir)\b|\.:?:news remote php shell injection::\.| rhtools\b)|ph(?(??: commander|-terminal)\b|remoteview)|vayv)|myshell)|\b(???:microsoft windows\b.{,10}?\bversion\b.{,20}?\(c\) copyright 1985-.{,10}?\bmicrosoft corp|ntdaddy v1\.9 - obzerve \| fux0r inc)\.|(?:www\.sanalteror\.org - indexer and read|haxplor)er|php(?:konsole| shell)|c99shell)\b|aventgrup\.<br>|drwxr))" \
"phase:4,t:none,ctl:auditLogParts=+E,deny,log,auditlog,status:404,msg:'Backdoor access',id:'950922',tag:'MALICIOUS_SOFTWARE/TROJAN',severity:'2'"

This rule is working when i switched the apache, but on LS it is not working.

This rule have to return 404 error when someone run r57 shell script.

Can you help to improve security by using SecRule RESPONSE_BODY ?

 

[mistwang]

Currently scanning response body is not supported by LiteSpeed yet.
A rule like that will severely slow down the server when scan a large response body.
So, we will think about it carefully.

 

[yolte]

Hello,

Maybe it will slow down server. But security is more important for us.

You can enable RESPONSE_BODY those who want to use security?

We are looking for to use LiteSpeed instead of Apache in our 20 linux servers. But our security department doesn't approve because of mod_security respone rules.

 

[yolte]

Hello mistwang,

It will be any progress on this issue?

 

[IrPr]

George is right, it will slow down server as hell
but i think special trick for example scanning specified response mime types (plain text) or requested file types (php) would solve performances issue and increases security as well

is it possible?

 

[yolte]

Yes it will slow down but this is our choice. Am i wrong?

 

[mistwang]

It is a low priority feature.

 

[yolte]

It is a low priority feature.

Security is low priority feature?

Each server can be hacked which is not support this feature. How can it be ignored?

Lets test it?

 

[Tony]

Security is low priority feature?

Each server can be hacked which is not support this feature. How can it be ignored?

Lets test it?

I'd say more like a site can be hacked because they do not keep up to date versions of their software or make secure software. For hacking an entire server it be even more tricky assuming the site was on it's own account.



There are other mod_security rules which are already supported which can inflate memory (ones that use location match). I'd rather see the rules that are supported not slow down LSWS to Apache levels.

 

[yolte]

I'd say more like a site can be hacked because they do not keep up to date versions of their software or make secure software. For hacking an entire server it be even more tricky assuming the site was on it's own account.

I think we have to protect customers web sites who doesn't have enough information about script security?

There are other mod_security rules which are already supported which can inflate memory (ones that use location match). I'd rather see the rules that are supported not slow down LSWS to Apache levels.

Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

 

[IrPr]

Im totally agree with yolte

However it may decrease performances but its a trade off between security and performances
it can be disable by default and could be turned on with our own risk

I think we have to protect customers web sites who doesn't have enough information about script security?
Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

c99 phpshells can be defected by some tricks because of using common GET args but r57 is more tricky and couldnt be defected without response body check
All phpshells based on malicious functions such exec, shell_exec, system, etc but we can catch local attackers with response body check

Hope be implemented in future

 

[Tony]

I think we have to protect customers web sites who doesn't have enough information about script security?



Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

There is only so much you can do without making your hosting service have absolutely no features. We have mod_security rulesets up which do have mechanisms to protect against a lot of the exploits of the scripts themselves.

For disabling php functions you have the issue of some scripts rely on them. I know gallery systems use exec and others use system. None use popen* so we disable those.

There is only so much you can do to protect your users if they will not take the time to update their scripts they'll deal with the consequences.

There are other avenues to put up malicious files. Do you not give your users FTP access? We've seen a growing number of hacked web sites come via ftp. Users using passwords that are the same as their username with one number in them. Or their own computers being hacked resulting in malicious files on their website.

This is all why we give users access to 7 days worth of backups that they can restore from themselves. If they get hacked they do have something to fall back on.

So in summary sites are going to get hacked if you want to protect them fully you'd want to not give users any access to their accounts. You'd also want to disable POST and GET via mod_security and whitelist based on domain (one host does this).

 

[anewday]

Tony, can you share your mod_security ruleset? PM me if preferred.

 

[Tony]

I just use gotroot.com then when we find things that get past we add rules for them. We won't give away our added rules so gotroot.com as a starting point.

 

[yolte]

c99 phpshells can be defected by some tricks because of using common GET args but r57 is more tricky and couldnt be defected without response body check
All phpshells based on malicious functions such exec, shell_exec, system, etc but we can catch local attackers with response body check

Thank you. I think disable_functions are nothing for a good hacker

 

[yolte]

I just use gotroot.com then when we find things that get past we add rules for them. We won't give away our added rules so gotroot.com as a starting point.

I'am using gotroot's paid mod_sec rules and our private rules too. You should fear from turkish and russian hackers

I am looking for 2 years and only way response body rules to block completely hacking attempts

 

[Tony]

I'am using gotroot's paid mod_sec rules and our private rules too. You should fear from turkish and russian hackers

I am looking for 2 years and only way response body rules to block completely hacking attempts

Well the best way is for users to be not being hacked left and right. I guess it's too much to ask for them to use a wordpress version made in the past year.

If you can limit the damage to the user account then you've done your best. If you do not allow url includes you've dramatically reduced your risk on a lot of the php inclusion exploits. Those are where most of these shells get uploaded. You're still not going to stop someone really determined unless you flat out do not allow anything. Most of the dangerous attacks in the past few years have involved privilege escalation. They did not even require a r57 shell to do. You could do them via a perl script which most are not bothering to block anyways. The perl scripts do not have the same sort of shell restrictions either.

Oh and I mentioned rules that cause a lot of trouble for LSWS well one such example so something like this:

<LocationMatch /edit_css.ph>
SecRuleRemoveById 340006
SecRuleRemoveById 340007
</LocationMatch>


With a lot of them and a decent amount of vhosts you could see your memory usage being extremely high. We had a machine where we threw up some rules with that and we went from LSWS using 100MB of memory to 800MB of memory.

The request body scanning is another scary rule to really kill the performance. If it's not done well I don't think it's worth doing at the price in resources it's going to come at. It does not guarantee protection either from what I'd deemed very serious.

 

[IrPr]

I'am using gotroot's paid mod_sec rules and our private rules too. You should fear from turkish and russian hackers

I am looking for 2 years and only way response body rules to block completely hacking attempts

Thank you. I think disable_functions are nothing for a good hacker

lol what do you mean by good hacker? most hackers are script kiddies which collect public exploits and rootkits from milw0rm and packetstorm

if i disable all c99's necessary functions then how could you use c99 shell on my server even without any mod_security rules defecting c99 shell?

In fact all php shells are woking based on common php security restriction bypass exploits, if you know php take a look into phpshells source codes and you will find all of 'em are based on some malicious functions

for example latest expoits for php is: PHP safe_mode bypass via proc_open() and custom environment which is not detectable by any mod_security rule! attacker can rename php filename to everything and bypass safe_mode/open_basedir restrictions easily

This exploits is not patched in latest stable PHP version yet, tested on php 5.2.9 myself and its working properly

The only way to patch this exploits is disabling proc_open function

mod_security is not enough to secure your server againts all remote and local attacks

 

[Tony]

I doubt that safe_mode exploit will ever be fixed seeing as how PHP 6.0 will not have safe_mode. At least that's what was said back when 6.0 was in early development. openbase_dir although useful if someone does get around it in theory they should be unable to do any damage. PHP is running as their user they're going to need to find folders that have read and write for everyone to do any damage. So really not a ton they can do and considering suPHP which a lot of people use does not support openbase_dir and we're not reading about people suggesting mod_php is better.

Plus as I said if your server supports Perl then these c99, r57 ect. ect. shells are just a php entry point. If they can get a perl version up they do not have openbase_dir restrictions anyways and can run shell commands.

 

[yolte]

if i disable all c99's necessary functions then how could you use c99 shell on my server even without any mod_security rules defecting c99 shell?

You know that php shells are using lots of php functions which are using by otner normal php scripts (etc oscommerce, joomla)

If we disable this functions other customers scripts has been blocking.

The only way to patch this exploits is disabling proc_open function

If we disable this, it can break any php script?

And finally, gotroot paid and real time rules, blocking %99 of php exploits on milw0rm and packetstorm. Did you try it?