Bojan Zdrnja has published a post on the SANS Internet Storm Center blog today highlighting a distributed WordPress admin account cracking script. The script was discovered by one of the sites readers on a virtual private server (VPS). The acquired script is written in PHP and performs brute force cracking attempts to WordPress admin accounts.
While this particular version is relatively simple, the power behind the script and the MySQL database allows the attacker to distribute the attacks not only by sites, but also by passwords tried as well.
The article goes into detail explaining how the script works and suggests the typical security precautions such as using strong passwords, changing the admin username and limiting the admin login page to only your IP address. Brute force attacks on WordPress are nothing new but it’s interesting to see this approach using a distributed technique.
Hat tip to WPVibe.
I recommend to install User Locker (my plugin :)) – it locks account after given number of incorrect login attempts. Locked accounts can be later unlocked by admin or using “lost password” option.
Interesting. Might explain why some of my sites are running insanely slow lately.
A quick check on the redirect_to variable in your wp-config.php can reject these sorts of attacks instantly, without breaking anything (usually):
if (!empty($_REQUEST[‘redirect_to’]) && strpos($_REQUEST[‘redirect_to’],’example.com’) === false) die;
That basically says to look for example.com in the redirect_to variable (if one exists), and if it’s not there, just stop processing any further. You’d change example.com to your own site, of course. That’d stop this particular attack (and similar ones) from getting anywhere.
That’s why I always recommend using the Login Lockdown plugin as one security measure, as it will lock out anyone trying to brute force their way in.
Author plugin page at http://www.bad-neighborhood.co.....kdown.html
WordPress plugin download page at http://wordpress.org/extend/pl.....-lockdown/
I installed a plug-in called “Peter’s Login Redirect”. On the Login Redirect setting page, I updated the URL field in the section “All other users” to point to “http://mydomain.com/wp-login.php”. This page does not contain the word “Log out” which is what the script looks for to see if it was successful. Therefore, the script will always think it has failed. (Assuming I have not made some horrible mistake and am totally not understanding this attack.)
HTH,
David
Also, for those who aren’t that savvy at making up strong passwords, or hate doing it because it generally means that they are inherently difficult to remember, this is a nifty little tool that generates passwords that are both strong and memorable:
http://www.bad-neighborhood.co.....erator.htm
User Locker works better for defending against this attack over Login Lockdown (From what I read about LL, not used myself) because this is a distributed attack. LL will put an IP address restriction, but this is coming from multiple computers. Now it will only give them each a limited amount of attempts, User Locker will stop all after the first few attempts.
Otto – That could be faked if needed. This attack it would stop but future smarter attacks would probably get around that.
David – It would probably be better to stop them from getting through at all then just giving them something different then what they are expecting to see because later attacks may look for something different. Obfuscation is great but shouldn’t be the only defense.
Wrote up a piece myself on what I’m doing through IP limiting and going through the other methods.
http://www.mustudios.com/2009/.....ce-attack/
Thanks
Richard
Richard: Only if you found a way specific to the site in question. The code I gave forces the redirect_to do go back to your site. So they’d need a customized script for the site or an XSS bug to exploit for detection.
Sorry I misread and thought it was a referrer check, not the redirect to.
But really, there is no reason they would need to set the redirect like they are. Your change works for this attack but this attack wasn’t really that smart in handling it that way. All it takes is using the default wp-admin location for your site or even leaving the redirect off completely since it will do it on it’s own.
It’s better to use a solution that will stop all brute force attacks then a specialized solution for this one specific (and poorly thought out) attack that you would then have to update once a proper one comes.
Richard
Bad Behavior already blocked this script.
This is an interesting post which in part prompted me to write a post on my blog about how to dumb down the admin account making it harder to hack and invariably pointless anyway because I have created a new user account with the Administrator role and changed the role of the admin account to Subscriber.
The post can be found at http://blog.ianroke.co.uk/2010.....allations/ if anybody is interested.
Cheers, Ian.
Wanted me to login to comment on your blog so I will comment here. Why reduce the privs and change the password when you can just delete the account? Obivously you aren’t going to use it so why even leave it there?
Thanks for bringing that to my attention Richard. I have recently moved my blog to another host and got some of the settings crossed up. It has been rectified now.
I don’t suppose there is really a right or wrong way of doing things I just chose that particular method because I come from a data warehouse background where we don’t delete anything just hide it from view.
Your method is perfectly adequate too as a way to secure a WordPress installation.