mod_security RESPONSE_BODY

[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

Originally Posted by yolte

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]

Originally Posted by yolte

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]

Originally Posted by IrPr

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]

Originally Posted by 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.

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]

Originally Posted by yolte

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]

Originally Posted by yolte

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

Originally Posted by yolte

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]

Originally Posted by IrPr

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?