Sophos Cloud Optix
A recent investigation has concluded that 73% of the 40,000 most popular websites that use WordPress software are vulnerable to attack.
The research, carried out by vulnerability researchers EnableSecurity and reported by WordPress security outfit WP WhiteSecurity, was conducted between Sept 12 and Sept 15 shortly after the release of the WordPress 3.6.1 Maintenance and Security Release.
WordPress is the most popular blogging and Content Management System (CMS) in the world and, according to WordPress founder Matt Mullenweg, it powers one in five of all the world’s websites.
As with any research of this kind we should apply a big pinch of salt.
In fact in this case we don’t need to supply our own salt because the research actually comes self-salted thanks to this hilarious rider at the bottom of the article:
The tools used for this research are still being developed therefore some statistics might not be accurate.
You have been warned.
So if the numbers might be wrong why am I bothering to reproduce them here? Because (in my opinion) they are probably true (well true-ish) and even if they aren’t they still highlight an important security issue which isn’t diminished one iota by their sketchiness.
As long as we go into this with our eyes open we’ll be fine.
The research did no more than set out to discover what versions of the popular CMS are in use by the top 1 million websites.
This singular focus is with good reason: the first rule of WordPress security is always run the latest version of WordPress.
If you aren’t running the very latest version of WordPress then the chances are you are running a version with multiple known vulnerabilities – bugs that criminals can use to gain a foothold on your system.
EnableSecurity’s scan of Alexa’s Top 1,000,000 discovered that 41,106 websites were running WordPress, a little over 4%.
They then determined that of those websites at least 30,823 were running versions of WordPress that have known vulnerabilities. From this they concluded that
73.2% of the most popular WordPress installations are vulnerable to vulnerabilities which can be detected using free automated tools.
Add your salt now.
Even if we take it as read that 73% of the sites are running vulnerable versions of WordPress we still can’t conclude that 73% are in fact vulnerable. There are common security strategies that the researchers didn’t test for, not least using a Web Application Firewall (WAF) that can put up a protective shield in front of vulnerable websites.
By the way, the first rule of WordPress security, always run the latest version of WordPress, holds true even for sites running behind a WAF. They are not mutually exclusive and should be considered as separate parts of a strategy of defence in depth.
In addition to skipping over reasons why the 73% might be a little on the high side the study also leaps acrobatically past a totally different set of reasons why it might be a bit on the low side.
The limited scope of the research meant that it didn’t account for other forms of automated attacks against WordPress installs such as targeting weak passwords or flaws in popular plugins.
As diaphanous as the study’s precision might be, the broad thrust is correct and it contains a useful message; users of WordPress need to be diligent about security because they are using software that is popular enough to be of interest to criminals who conduct large-scale automated attacks.
10 ways to keep your WordPress site secure
If you are running a website that uses WordPress here are 10 suggestions to help you avoid ending up in the 70% (or whatever large number it is) of vulnerable sites.
- Always run the very latest version of WordPress
- Always run the very latest versions of your plugins and themes
- Be conservative in your selection of plugins and themes
- Delete the admin user and remove unused plugins, themes and users
- Make sure every user has their own strong password
- Enable two factor authentication for all your users
- Force both logins and admin access to use HTTPS
- Generate complex secret keys for your wp-config.php file
- Consider hosting with a dedicated WordPress hosting company
- Put a Web Application Firewall in front of your website
For more on the subject of patching WordPress have a listen to Sophos Security Chet Chat 117, the latest 15 minute installment in our regular podcast series.
But what about changing you database prefix from _wp to something else? Or not using a user with ID=1. Or even hiding you wp-admin to evade bruteforce attacks?
Absolutely, do those too. I didn't not include them because they aren't worth doing, only because I had to stop my list somewhere and they didn't get into my top 10.
Changing things like the db prefix is perfectly fine as one more additional step in a defense in depth approach but by the time it matters your attacker has already got through whatever protection you have in place against SQL injection and you are in trouble because they're through the front door and in your living room already.
If an attacker can inject SQL they may be able to use it to find out what the structure of your database is anyway – I certainly wouldn't want to rely on them _not_ being able to do that – and if they can't discover your database structure they will probably have all the time in the world guess at it or they can give up and run a fairly nasty DOS using their database access.
SQL injection should be prevented by input sanitisation in both the PHP code and the WAF and then by escaping the sanitised input correctly before it's included in any SQL queries. Getting those things right is much, much more important than changing the table prefixes but there's no harm in changing the prefix too.
There are different ways to 'hide' wp-admin. If you just mean renaming it to something obscure then that's OK but a mystery name can be guessed in the same way a password can. it certainly makes things more difficult but not nearly as difficult as, say, restricting admin access based on client certificates.
The report concluded that "…73.2% of the most popular WordPress installations are vulnerable to vulnerabilities…"
One wonders how being "vulnerable to vulnerabilities" is different from simply being vulnerable. 😉
The most common attack I get is a brute force / automated attempt at the password.
Just use a plugin to limit login attempts (and record/block IPs)
I allow 3 attempts followed by an hour timeout
If there are three further login attempts, then that becomes a 72 hour lockout.
Nobody has ever come back after that.
This is another good idea that only didn't get into the article because we have to draw the line somewhere.
The approach is perfectly sound and a lot of people like Fail2Ban which can do the same thing across many public facing services, not just your website.
I would introduce two factor authentication (2FA) before doing this because this approach has a few drawbacks.
The first is that it is reacting to an attack that has already happened. Being a brute force attack it's unlikely to succeed but if the attack is coming from a botnet then it may have many tens of thousands of IP addresses with which to take a swing at you – chances are they won't all come knocking on your door but these things change without telling you in advance.
Also IP addresses are in short supply so they are shared and you could end up locking out an entire company, part of an ISP or a geographic region. How serious the consequences of that might be probably depends on what your site does and where it sells to.
And finally it's limited to brute force attacks – if your password is compromised it doesn't help.
A very strong password and two factor authentication gives you resilience to brute force attacks. If one of your two factors is a client certificate then the bad guys don't even get to try guessing your password once, from anywhere. And perhaps most importantly if one of your users' passwords is compromised you're still OK so it gives you more than brute force protection.
None of which is to imply that this is a bad thing to do – it's not – and as I said in my previous comment I'd certainly consider this as part of a defence in depth strategy.
Add sleep(2); before password checking – no problem for real user but big problem for brute force.
Some very interesting points about WordPress Security.
"A recent investigation has concluded that 73% of the 40,000 most popular websites that use WordPress software are vulnerable to attack."
Makes you wonder the real extent of the potential problem.
You can probably draw all the conclusions you need about the extent of the problem from the fact that criminals find it's worthwhile creating automated scans and attacks against WordPress.
Hey Mark, got a question for you. My pictures on my site are not showing up whenever I share them on social media etc. I use AIO SEO and set a picture there AND a featured image (and the dimensions are fine). This happened to me before, but I can’t remember what I did to correct it. Could it be a plug in? I recently installed a few. Any assistance would be awesome. btw, the pics are showing up on the blog just fine, but my custom header is showing up as the picture. grrrrrrrr And sorry for asking you the question here, I can’t figure out how to post on your google+ page.
Hi Jeff,
This isn’t really the place for general WordPress questions – we like to keep the conversations on-topic and security related so I wish you the best solving your problem and respectfully commend you to the WordPress support forum http://wordpress.org/support/ and the AIO SEO support pages http://wordpress.org/support/plugin/all-in-one-seo-pack
All of the above ideas are useless if a plugin is compromised. WordPress is a security nightmare, don’t install it!
Correct. The article is about vulnerabilities but the author does not seem to mention vulnerability/code scanners and/or anti malware/viruses. These tools should actually come at the top of the list of defence lines as running the latest version of a software does not mean it does not have vulnerabilities and/or that it is not already infected by malware, this is specially true for plugins and themes.
It’s good advice but for the majority of generic or specialist WordPress hosting installing your own anti-virus, or any kind of server software at all, isn’t an option.
I didn’t mention firewalls or disabling services that your server doesn’t use either but that doesn’t mean they don’t affect the security of your WordPress site, that they aren’t good advice or that I don’t endorse them.
If I were to include them I would need to include a lot more advice besides and this would become a very, very long server security howto rather than an article specifically about WordPress.
Hi Mark,
Thank you for your answer.
In terms of vulnerability / malware scanners I was thinking WordPress specific ones i.e. taking the shape of a WordPress plugin and aimed at scanning WordPress code (core, plugins, themes, …) .
You are right that most hosters wouldn’t allow customers to install operating system-level security software (except maybe on advanced/expensive dedicated server hosting packages) but I guess most WordPress hosters would allow people to install security-related WordPress plugins (tell me if I’m wrong here).
Anti-vulnerability/malware WordPress plugins are far from being infallible (as any other security measure) but should nonetheless help make a WordPress install less vulnerable to attack IMHO.