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!
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