Mary has a site that she really cares about called mycoolsite.com. She has learned how to monetize her blog through the use of ads which allows her to make her living. She uses WordPress and always keep it updated. She also keeps her plugins updated, uses strong passwords, accesses the admin panel via SSL, and takes all the security recommendations very seriously.
She uses a shared server and her host offers her unlimited domains. Over the years, she has taken advantage of this offering, adding a few sites here and there. One such site was mytestsite.com for trying new themes and plugins.
It has been at least a year since she has touched one of her other sites – mytestsite.com hasn’t been updated and houses a plugin that has since been removed from the WordPress repository. Little does Mary know that it was removed from the repository for having a very serious security vulnerability.
Part 1: The Bad Guys Came…
Like in any story, the bad guys wasted no time in finding and exploiting this vulnerability.
They had a list with millions of sites that they were scanning daily (based on Alexa). They found Mary’s mycoolsite.com (which was ranking very well) and tried to exploit it without success. They looked for any potential attack vector; things like the WP version, vulnerable plugins, weak passwords (making use of brute force and dictionary attacks). They used a slew of tools in their arsenal, nothing worked. She won that battle.
A few days later after using a number of techniques, they found that on the same server she had another site, mytestsite.com. Unlike mycoolsite.com, using the same techniques as before, they were able to gain access. They quickly found the vulnerable plugin and leveraged its vulnerability to gain access. Oh, well that’s cool, it’s only her unimportant site, mytestsite.com. Who cares, right?
Part 2: How Did My Site Get Hacked?
The next day, she wakes up to emails from her users complaining that mycoolsite.com is causing their local anti-viruses to set off alerts and are blocking her site. The first thing she does is go to her site to see what’s going. She is greeted with a scary warning, “This site may harm your computer”!
“EEK!! What is going on? How did my site get hacked? I did everything right!! I followed all the recommendations!!!
Part 3: Website Cross-Contamination
In part 1, we left you with a question: “Who cares, right?”
Yes, Mary did everything correct to protect her mycoolsite.com. What she didn’t do is apply those same principles to all her sites. She forgot that because the other sites are on the same shared account (and can be managed by the same user), any vulnerability on them can be used to compromise her whole account.
Once on the server the attacker was able to introduce all kinds of malicious code, from backdoors to actionable code. Like any virus, it replicated itself, inserting itself into every PHP file it could find. This spread across every directory on her site without remorse.
That folks, is all she wrote…
Part 4: Fixing the Problem
Like you would expect, Mary contacted a company to fix mycoolsite.com. The company went through and removed all the malicious code to include backdoors. Phew! It was now showing correct again, all warnings were gone.
She even took a few more steps this time around. She blocked wp-admin access by IP address and installed all security plugins she could find. Victory?
Part 5: Website Cross-Contamination and Reinfections
Nope. Not even close. Within an hour everything Mary thought she had cleared had reappeared.
Why did this happen when she had done everything by the book? Even hired a company to get it fixed.
The answer is simple, it’s a concept known as cross contamination. It’s actually very easy to understand. We all know how viruses work, they spread. No point in having a virus that doesn’t spread. Where is the fun in that?
Mary did what most people do. She fixed the infection but not the root problem. She spent a week cleaning her little site day in and day out, looking for some relief to the problem. Demanding someone fix this problem for good!
She finally took the additional steps recommended, scrubbing her server. She was dismayed at what was found. She was elated, yet heartbroken at the amount of energy she had put into the effort. After a week of work, lost sleep, significant impact to her Alexa ranking, and many other effects – some monetary, some not – Mary finally had control of her server again.
Pulling it Together
This very real tale is meant to better articulate, by providing an example, the concept of website cross-contamination and how serious an issue it is.
The point is very simple. If you have many sites on the same account (running under the same user), anyone of them can be used to compromise the others. The attackers don’t care how important a site is to you, they just want an access point.
It’s unfortunate, but we see this all the time. It’s why one of the first things we do is scan the server, if allowed, for software versions and known vulnerabilities. It’s sad to report that too often we find things like this:
/mycoolsite.com (WordPress 3.3.1) /mycoolsite.com_backup_1 (WordPress 3.1) - Out of Date /mycoolsite.com_backup_2 (WordPress 3.2.1) - Out of Date /mycoolsite.com_backup_3 (WordPress 3.2.1) - Out of Date /myplaysite.com (WordPress 1.5) - Not even kidding about the version. - Out of Date /myunimportantsite.com (Joomla 1.4) - Out of Date
Action item: Check your server today. When you do, ask yourself –
- Did you ever install test sites, plugins or themes that you might not use anymore?
- Do you have old domains running on the same server/account that you don’t care about anymore? Delete them all (clean your garage) to avoid this issue.
- Feel free to use our free scanner to see if your sites are up to date: http://sitecheck.sucuri.net.
- Watch this video to gain a better understanding of end-user security.
- Read this article as well: https://blog.sucuri.net/2011/10/remove-unsused-testing-debug-software-from-your-site.html
Only keep the minimum necessary files, themes and plugins that allow your site to function perfectly. Everything else should be disabled or moved to a separate server. While you can never say your risk is zero it doesn’t mean you can’t work to reduce it.