A Little Tale About Website Cross-Contamination

Mary has a site that she really cares about, its called mycoolsite.com. She has learned how to monetize her blog through the use of ads, this 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, it’s used to try new themes and plugins.

It has been at least a year since she has touched one of her other sites – mytestsite.com, it 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 her 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, 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, its 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 or blocking her site. The first thing she does is go to her site to see what’s going. She is greeted with an  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: “Oh, well that’s cool, its only her unimportant site, mytestsite.com, who cares, right?”

WRONG!!

Yes, Mary did everything right 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 her site, 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 simple 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.

Same applies to web malware. It duplicates itself, injecting itself in little dark directories you never check, or care to check. Places you would not even think of. You might have a directory for all your JavaScript files, in there you might find a PHP shell file. You might have a directory for images and one of those PNG files might be masking itself as an executable.

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 heart broken 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, all they want is 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. Its 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:

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 0 it does not mean you can’t work to reduce it.

 

Scan your website for free:
About Daniel Cid

Daniel is the Founder & CTO of Sucuri and also the founder of the open source project - OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development.

You can find more about Daniel at his site dcid.me or on Twitter: @danielcid