Effective iframe/gumblar hack prevention?

[Wallaby]

I wonder if anyone has found a genuinely effective method for preventing this type of hack.

I've tried the script from http://anti-gumblar.oxio.net and it does not seem to be effective: I've seen hacks take place which this has not prevented.

I've looked at ConfigServer eXploit Scanner (ConfigServer eXploit Scanner (cxs)) but it seems to be fairly similar and also gives the impression that it will throw quite a lot of false positives?

I should note that in the most recent hack the affected files were 100% obviously infected with iframe hacks from a visual inspection, but they were passed as totally clean by ClamAV, F-Prot and Malwarebytes. I know F-Prot at least does definitely find at least some iframe hacks in HTML files etc.

I've even considered writing some kind of search for all infectable files (htm, html, php...) for <iframe... stuff and email me a report to visually check. It's usually easy to spot the non-genuine iframes visually.

Any better ideas? This is very frustrating!

[sparek-3]

Preventing?

The best way to prevent something like this is to insure that all of your users practice safe and secure administration.

If they use scripts, they need to make sure that they are always staying up-to-date.

If they use addons/components/extensions to those scripts, those need to stay up-to-date as well.

They should use strong and secure passwords and practice good password storage. Saving the password for their website in their FTP client's site manager is probably not a good idea.

They should insure that all of the software on their computer stays up-to-date. If a new version of their browser is released, they should upgrade. A new version of Flash is released, they should upgrade. Etc.

They should avoid going to websites with questionable material so as to not infect their system.

They should use quality up-to-date anti-virus and anti-malware software (I have no clue as to what is considered the best in this category).

That is how you prevent attacks like this. All of your users and all of their sub users should practice these things.

An ounce of prevention is worth a pound of cure. Meaning the more steps you take to fix security holes and prevent malicious attacks from happening, the safer you will be.

But from a realistic standpoint, good luck with that. For whatever reason, some users believe they can install a script on their website and then never deal with maintaining the script and they will be secure, but this is just not the case.

[Infopro]

...
But from a realistic standpoint, good luck with that.
...

Isn't that the truth...

All good tips though.

I've looked at ConfigServer eXploit Scanner (ConfigServer eXploit Scanner (cxs)) but it seems to be fairly similar and also gives the impression that it will throw quite a lot of false positives?

I have not found that to be the case here. I'd be interested to know what the eXploit scanner would have found.

[Wallaby]

Hi InfoPro: how many servers do you have cxs runnig on? Does it catch stuff? What proportion of false positives does it get? Cheers!

[Spiral]

I wonder if anyone has found a genuinely effective method for preventing this type of hack.

Yes, I wrote a combination of programs and scripts about a year ago that stops this kind of attack dead cold in it's tracks and combines activity monitoring, file scanning, ftp filtering, and access restrictions combined with administrator alerts on suspected attempts.

If you are using "pure-ftpd", there is actually a way you can additionally detect and hit all of that in real time the moment someone tries to do this which actually really is not all that difficult to configure.

I've looked at ConfigServer eXploit Scanner (ConfigServer eXploit Scanner (cxs)) but it seems to be fairly similar and also gives the impression that it will throw quite a lot of false positives?

That won't do you much good for this issue other than perhaps help you locate hacked files after the fact possibly but that would be about it because those rely on matching known signatures in files.

This type of attack DOES NOT originate as an exploit or compromise of the hosting server but rather is an exploit of the HOME USER'S COMPUTER instead ... IE: Your hosting client themselves are the source of the problem!

(This incidentally is the very reason why most everything you normally do on the server to try to stop this has little effect)

I should note that in the most recent hack the affected files were 100% obviously infected with iframe hacks from a visual inspection, but they were passed as totally clean by ClamAV, F-Prot and Malwarebytes. I know F-Prot at least does definitely find at least some iframe hacks in HTML files etc.

Again, all of those rely on the hack already of taken place and are just simply cleanup tools after the fact.

I've even considered writing some kind of search for all infectable files (htm, html, php...) for <iframe... stuff and email me a report to visually check. It's usually easy to spot the non-genuine iframes visually.

Not much point re-inventing the wheel ---

What you just said is quite literally the very first thing I wrote once these types of attacks first started emerging.

Any better ideas? This is very frustrating!

Well the first thing you need to do is find out from your log files which of your users are the source of the problem. These will be the user accounts "first accessed" and their home computers will need to be thoroughly scanned for viruses and password stealing trojans. Changing their passwords do no good as long as they remain infected unless you just simply don't plan on giving the client the new password.

Next you need to make sure your server is properly security hardened and updated. While the source of this type of attack DOES NOT originate with the hosting servers, any server with inherent vulnerabilities might be further compromised as a by product of the hackers getting into a regular user's account from the first situation. It is much easier to hack a server from the inside than it is to hack a server from the outside.

Regarding the scripts and configurations I spoke of earlier, I'm actually working on a newer version now that CSF has a '-ta' flag as I have an idea how this might be used to strengthen defenses from this further. In any case though, I'd be glad to help get you setup with some of that.

[Spiral]

Preventing?

The best way to prevent something like this is to insure that all of your users practice safe and secure administration.

If they use scripts, they need to make sure that they are always staying up-to-date.

If they use addons/components/extensions to those scripts, those need to stay up-to-date as well.

They should use strong and secure passwords and practice good password storage. Saving the password for their website in their FTP client's site manager is probably not a good idea.

They should insure that all of the software on their computer stays up-to-date. If a new version of their browser is released, they should upgrade. A new version of Flash is released, they should upgrade. Etc.

They should avoid going to websites with questionable material so as to not infect their system.

They should use quality up-to-date anti-virus and anti-malware software (I have no clue as to what is considered the best in this category).

That is how you prevent attacks like this. All of your users and all of their sub users should practice these things.

An ounce of prevention is worth a pound of cure. Meaning the more steps you take to fix security holes and prevent malicious attacks from happening, the safer you will be.

Spot on! .... I wholeheartedly agree with all of those comments!

Everyone reading this thread would be wise to pay attention to sparek-3's words here as security is an issue that is far too often ignored and in my work I see way too much to say these points cannot be stressed enough.

But from a realistic standpoint, good luck with that. For whatever reason, some users believe they can install a script on their website and then never deal with maintaining the script and they will be secure, but this is just not the case.

Sad but true! You get so many that either do absolutely nothing to secure their servers or just slap on CSF (usually un-configured ) and think they are doing great security wise because they "have a firewall".

(To the oblivious masses who don't follow this conversation --- I am not saying anything against 'csf' as it is in fact a fabulous program and I do strongly support it but it is not a security solution in itself and doesn't do anything for you at all if you don't even bother to configure it)