RSS Twitteer Facebook linkedIn YouTube foursquarePinterestGoogle

List Of New Vulnerabilities Leads To More Website Hacks: Be Prepared

May 4th, 2015

It’s been a while since I last wrote about websites getting hacked. But that does not mean it’s been quiet on that front: In fact, quite the opposite is true.

We have successfully cleaned a number of infected websites since then; some infections were minor, some were absolutely horrendous. On some sites we found the “usual suspects”, on other site the infections were extremely wide-spread, well-hidden and even quite elaborate.

In most cases the front-end of the website was not defaced or visibly altered

(at least not in the beginning), allowing the hackers to do their evil deeds undetectedly and uninterruptedly for a very long time; until somebody gets sloppy or too cocky and finally breaks the site.

Obfuscated-Code-PHP

How Infections Start

Bot networks check thousands of random websites per minute for known security holes and/or weak (FTP) passwords and – if they find a vulnerable site – upload malware to the server and report back.

Meaning somewhere, in some database, there now is a record that this (your?) website now contains said malicious code – all the bad guys need to do now is to access it.

It often starts with a dormant secret backdoor: Everybody who knows it exists can open it at any time – which also explains why we typically see more than one cluster of suspicious events – sometimes months apart.

Depending on the type of backdoor a hacker can either gain access to your website’s database (which allows for the insertion of users with administrator permissions), upload other files for e.g. the purpose of sending SPAM emails, remotely administer and control your webspace to add, remove and alter files, insert spammy code, steal sensitive information, redirect all visitors to another website – anything is possible.
During all this time of course the website owner has no idea he’s been hacked.

The hack only becomes apparent when:
– Google blocks the website / issues a warning that the site might be unsafe to visit
– The Hosting Company shuts the website down
– The website (or parts of it) stop working properly (or stop working altogether), you see an error message or other strange code on the site
– When upon entering the website’s URL you get redirected to another website
(Incomplete list. Pick any or all of the above)

Malware Warning Google

From Exploit To Hack: Who’s To Blame?

Probably the biggest exposure a security exploit recently got, was the Revolution Slider Vulnerability (one of the most popular plugin-ins for WordPress) in September 2014.
But due to the fact that a lot of developers, theme designers (and of course not a single website owner!) never paid any attention to this, this security hole led to another huge wave of new infections in December 2014.

Themepunch (Revolution Slider’s Developers) had released a security update (v 4.2) on February 25, 2014 – 6 months before the exploit was made public. And almost 10 months (!) before the second wave of attacks.

It’s The Developer’s Fault! It’s WordPress’ Fault! It’s Magento’s Fault!

Does the discovery of the initial vulnerability in Revolution Slider mean their product is bad? Absolutely not. It’s a great product.
Like others that followed, including the WordPress XSS 0day Vulnerability or the Magento Shoplift Vulnerability, these security holes can happen to the best, similar to security recalls issued by car manufacturers.

It’s in the developers’ best interest to provide security fixes as soon as possible to keep the threat level at a minimum and to keep a potential infection from spreading. In most cases patches are being released very quickly, sometimes on the same day an exploit becomes known.
Unlike car recalls however, which are generally announced via TV, radio and in any paper around the world; these software security notifications get a lot less publicity and go mostly unseen and unheard by the very people who should be the most concerned: The website owners themselves.

Yes, you heard me right: Website owners need to be more vigilant. They need to learn that a website is an investment, and that they need to protect it, just like they take care of any other part of their business, their homes or their cars.

I don’t mean everybody needs to become a server administrator or a webmaster overnight (please don’t!).
But everybody can read Google Webmaster Messages regarding the health of their website or recommended updates (BTW, the article is from November 2009!).

WebmasterTools-Revolution-Slider-Update

And if you’re really too busy, consider paying somebody to do it for you. Invest in a security package for your website or a maintenance contract that includes security updates – like car or homeowner’s insurance.

But Wait, Isn’t The Hosting Company Responsible?

Most likely not.
Given the fact that most people choose their hosting company by price and not by quality of service, the hosting company’s terms & conditions usually state that you as the account holder are solely responsible for the content of your allotted disk space and that they reserve the right to shut down your website in case they detect malware or other potentially malicious or illegal content or even charge you a mandatory cleanup fee.

There are many very good hosting companies out there offering special WordPress or Magento secure environments, or who include security monitoring in their hosting packages.
Bad news for cheapskates: Those packages are more than $2.99/month. You get what you pay for.

Then It’s My Web Designer’s Fault!

Uhm, no.
This would be like blaming the car dealership if you got in an accident 2 years after buying the car (and failed to get insurance).

On top of that, most web designers have no idea how to spot or clean an infection.

In the end, it’s nobody’s fault but the hacker’s. Like when your house gets burglarized, it’s the burglar’s fault. The discovery of an exploit also does not mean your website was hacked.

What NOT To Do When There Is An Infection

1) Nothing

For obvious reasons doing nothing is the absolutely worst thing to do.
The infection won’t go away on its own, it will only get worse as new about your “hackable” site spreads, potentially endangering other accounts (on the same server) and other websites.
You might even compromise the security of your customer’s data (Personal Information, even Credit Card Numbers), or your website visitor’s security (if the hack injected malware on your website), so you have an obligation to clean an infection on your website as soon as possible.
Unfortunately (and impossible for me to understand), some (irresponsible!) hosters choose this route.

(This is a true story) Although notified multiple times about infected websites on his server, this one hoster shut down some of the affected sites but refused to give us (or anybody else for that matter) access to perform a cleanup.
In addition, he made a few very questionable comments regarding the security (or lack thereof) on his server(s), implying that SSH access to one account would give us access to all accounts on his server.

2) Install More Plugins

This is generally what webdesigners do when they find out a website they’ve created or worked on has been hacked and they are in panic mode.
They are trying to control or mitigate the scope of the security breach by downloading and installing anything and everything that promises a quick fix. Stop it! You are only making it worse.

I have nothing against security plugins (although I won’t endorse any of them), as they can be an early indicator of suspicious activity or unusual events – if configured properly and monitored correctly.
But they can only find what they’ve been destined to find – most infections we’ve seen consist not only of the aforementioned “usual suspects” (which most of the plugins do find) but many, many more files containing polymorphic code with varying payloads that’s almost impossible to spot.

3) Try To Clean It Yourself

Malicious Files FoundSo you just installed one of the above plugins and got a lot of messages indicating malicious files were found?

Don’t jump over to your FTP program and frantically start deleting everything in the list. Typically scans by these plugins trigger a bunch of false positives, simply because they look for known patterns which can be part of a legitimate file. If you delete this file, something, somewhere on your website (or maybe the whole website) could stop working.

Maybe you even read somewhere that “eval” is evil (which it sorta is), but deleting all files containing the string “eval” has very unexpected consequences (because it would also match “evaluate”, “revalidate”, “retrieval”, etc).
All the recent files we found hardly contain the dreaded “eval(base64_decode())” string anymore, instead everything inside those files is completely obfuscated, reversed and compressed (not necessarily in this order) to prevent detection at all cost.

Trying to clean a website infection yourself is like trying to cure cancer with a band-aid.

What To Do When You’ve Been Hacked

First and foremost – try to keep cool. Don’t panic, don’t make decisions you might regret (see above).
Next, call a professional as soon as you can. Don’t touch anything. Please. It makes our job a lot harder.

Depending on the type of website (think e-commerce!) the hack might have severe consequences – not just for the website owner – in which case all actions taken need to be well-planned and documented.

Preventive Measures

Plan ahead.
Sounds simple? It is. Again, it’s very similar to car insurance or homeowner’s insurance.
– Have a backup. And then make another one.
– Keep an (up-to-date!) list of all users with (backend) access.
– Keep an (up-to-date!) list of all passwords (including FTP/SSH, Hosting Control Panel, etc).
– Keep an (up-to-date!) list of everybody who worked on the site (designer, developer, etc).
– Keep the server clean. It’s not your grandma’s attic or a storage unit. Anything that doesn’t belong on there or isn’t required for the day-to-day operations of your website needs to go.
– Delete unused plugins.
– Delete test accounts.
– Delete test databases.
– Delete test websites or installations (we know you have them).
– Make another backup.
– Repeat all steps.
– Keep an eye on everything. Always. Or talk to us about our website security packages.

Talk To Us Today!
About the author:

Nina Khoury is a computer scientist, software engineer, data and information junkie and online marketer. She taught at various universities for more than six years and worked on projects for Fortune 500 companies including cisco, Intel and HP.

Leave a Comment