How secure is your WordPress site?

One of the main problems with technology is the frequent lapses in security we experience; a lot of information is stolen daily and used to steal more information, send spam messages, open backdoors to systems and sometimes even do damage to our computers.

None of these issues unknown to WordPress, a staggering number of sites have become victims of unpleasant criminals exploiting the community for their own personal gain.

In order for you to beat this threat we’ve put together a roundup of some good tools and tips on how to avoid being the next victim. Or if you’re unlucky enough to already be a victim, how to fight back and fix your installation.

 

Exploit attacks

You may have heard about it, you may even know the details, but for those who haven’t here’s the problem: an exploit is a piece of malicious code distributed to exploit a weakness in existing code.

TimThumb was susceptible to an attack of this kind; one its functions, which allows users to upload images from different sites and access them freely, stored images in a cache directory so that Timthumb doesn’t have to reprocess them again. This function could be exploited by a hacker uploading files to the server, allowing them access to as many resources from the WordPress installation as they wish.

Exactly the same problem affected Uploadify, a plugin allowing users to upload files. When not properly controlled the plugin allowed hackers free access to the site by uploading PHP scripts to grant access permissions.

 Maintenance

Maintenance image via Shutterstock.

The problem in these cases, as with the majority of exploit attacks, was not WordPress but rather the plugins themselves. The solution is simple, keep your plugins up to date and report any bugs that you encounter to the developers to help them to patch potential issues.

 

SQL injections

The WordPress installation itself is not immune to problems. Depending on the version, SQL injection can be a major headache. An SQL injection is a process by which an attacker seeks to pass SQL code via a website form or script in the hope that the SQL code will parse ‘correctly’ and retrieve data from the database. That data might be email addresses, but more likely, it would be usernames and passwords that would then give the user more access for other attacks.

The reason SQL attacks can be so irritating is that to combat them you need to frequently backup your database. Preferably at least once per day.

Mainenance

Maintenance image via Shutterstock.

To avoid that, you can try to secure your files using Apache with a code like this in your .htaccess file:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

This will put off an amateur, but a professional hacker will find another security hole to exploit. Fortunately most attacks are perpetrated by newbies or spammers, using scripts like PHP r57 or Shell. Reducing these attacks will greatly reduce the amount of problems you have to deal with.

 

Default user

The biggest security hole in every system is the end user. It doesn’t matter how complex a password you create. In fact the more complex the password, the worse the security risk; because very complex passwords have to be saved somewhere. Users frequently save passwords in .txt or .doc files on their computer and that leaves the system open to phishing attacks using virus files like trojans.

The only safe place to store a password is inside your own head.

However, even if you only ever store your password in your own memory, you’re still not safe from brute-force attacks. A brute force attack will simply attempt to ‘guess’ your password with repeated attempts to log in. It may start with ‘aaaaaa’, proceeding to ‘aaaaab’ and so on until it reaches ‘000000’. This process isn’t limited to a single computer, commonly hundreds of machines run through potential passwords looking for access.

One way to handle brute-force attacks is to install a login limiter that will only permit a few login attempts before blocking access for that user for an hour or so. This reduces the number of chances the attacker has to get in. There are several WordPress plugins that can help you with this: Limit Login AttemptsBetter WP Security and Login Security Solution.

Finally, pay attention to usernames. The default username for WordPress is ‘Admin’ and if you leave it as such you’re halving the amount of work the hacker needs to do to access your site. If you didn’t change your username while you were installing WordPress do it now. Just log into your account, create a new account with the username you want, give it administrator permissions and then delete the admin account.

Cleanup

Cleanup image via Shutterstock.

 

Direct Access

Another problem our WordPress sites may have is providing direct access to the login page, simplifying the process of hacking your site.

Whilst securing your passwords is the most pressing issue, a malicious user won’t be able to make use of anything they’ve stolen if they can’t find the login page. The simplest solution to this is to use a plugin like Hide Login to obscure the login page’s location.

Certain files in our WordPress installation can also be accessed if not properly secured. We can clear up these loose ends by adding some more rules to our .htaccess file, like so:

Options All -Indexes
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>
<files fantastico_fileslist.txt>
Order allow,deny
Deny from all
</files>
<files fantversion.php>
Order allow,deny
Deny from all

 

Default prefix

It should be clear that the more information we give our would-be hacker, the easier it is for them to succeed.

The default WordPress table prefix is ‘wp_’. Why would we want to give them that? Let’s change that prefix to something harder to guess, like ‘oijrr58_’ for example, it will make their lives much more difficult, and increase the chances that your site will remain secure.

For new installations, this is a no-brainer because the installation script asks us for a prefix. For older sites you have two options, you can either make the change manually (only attempt this if you have lots of time and are sure you know what you’re doing) or use a plugin like Better WP Security which will take care of it for you.

 

Too late…

It’s never too late. You can always combat hackers, and prevent yourself from becoming a perpetual victim.

If you’re unsure whether your site has been infected there are tools that will tell you. Sucuri SiteCheck for example will scan your site and if you’re infected, will advise you on what steps to take to correct the problem(s).

Hazardous

Hazardous image via Shutterstock.

Basic fixes

Here are some basic steps to take:

  • Backup the site and database, hacked or not, you don’t want to lose your content.
  • Make copies of items that aren’t in your database, like images.
  • Download the latest version of WordPress.
  • Ensure all plugins are up to date, check which versions solve known problems.
  • Ensure any templates are up to date, check which versions solve known problems.
  • Use an FTP client or cPanel to delete everything in the WordPress directory.
  • Upload the new files you downloaded.
  • Run the database upgrade.
  • Change your password, you don’t want to let the hackers straight back in.
  • Finally, check every post, correcting any damage that has been done.

Fighting r57 scripts

r57 is a PHP script that gives an attacker a wide range of capabilities, although the attacker has these capabilities, these won’t work until the shell is on our web server, consequently we can prevent it from working using the following commands:

find /var/www/  -name "*".php  -type f -print0  | xargs -0 grep r57 | uniq -c  | sort -u  | cut -d":" -f1  | awk '{print "rm -rf " $2}' | uniq

This command will look for PHP files located on your WWW folder, then within the found files it will look for any mention of r57 in the filename and contents. Then it will delete the infected file(s).

find /var/www/  -name "*".txt  -type f -print0  | xargs -0 grep r57 | uniq -c  | sort -u  | cut -d":" -f1  | awk '{print "rm -rf " $2}' | uniq

This code does the same, except for TXT files instead of .php files.

Note that these codes are for Linux, don’t try them on Windows or MacOS and be aware that they are potentially very destructive as they’ll delete files without asking for permission.

Obscured code

A major cause for concern within themes is obscured code, because malicious code tends to be harder to find within themes. All sorts of damage can be done, from redirecting users to other sites, to sinking your SEO.

A key weapon in fighting this kind of problem is Theme Authenticity Checker. This plugin will not only check code for suspect lines but will detect static links and obscured code like code generated in base64 that is hard to spot by eye.

 

Fool me once, shame on you…

Just because you’ve been caught out in the past, doesn’t mean you have to keep being played.

Consider taking these steps to secure yourself further:

  • Only permit PHP where strictly necessary.
  • Ensure that your web server does not allow clients to modify the .htacess file.
  • Implement a firewall that will restrict the mail outbound in the port 25 to just the root and email server ID.
  • Monitor uploads to your site with an application like ConfigServer eXploit Scanner.
Repair

Repair image via Shutterstock.

 

Finally

WordPress security is as important as any site security. You must ensure that both you and your users are protected from spam, malware and phishing attacks. But remember that the first line of defence is actually the anti-virus software on your desktop machine.

Have you run into problems with WordPress security? How did you solve the issue? Let us know in the comments.

Written exclusively for WDD by The Shock Family: a team of web professionals and creators of  WordPress Themes Shock (Premium wordpress themes), WP Theme Generator (A great wp theme creator), and DesignShock (useful design sets).

0 shares
  • Mary Brose

    Thanks
    for such a perfect website and informative one .You’ve made some really good
    points there. I looked on the net to learn more about the issue and found
    most individuals will go along with your views on this website.

  • http://www.neogrey.com/ Ivan Filipov

    well, adding first block of code to my .htaccess resulted once in unstyled site, the second resulted in Internal Server Error 500

  • http://twitter.com/psdcovers PSDCovers

    Here are a few more rules to add to the top of your htaccess file:

    # Protect the .htaccess file Order Allow,Deny Deny from all
    # Protect wpconfig.php Order Allow,Deny Deny from all
    # Disable directory browsingOptions All -IndexesAddHandler php5-script .php
    # prevent hotlinking of content RewriteBase / RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(www.)?YOURDOMAIN.com/.*$ [NC] RewriteRule .(gif|jpg|swf|flv|png)$ /feed/ [R=302,L]

  • http://about.me/evanjacobs Evan Jacobs

    Why are you blocking HEAD requests? There’s nothing wrong with those, and they’re frequently used to verify the browser cache.

  • http://www.wahinfo.com/ Work At Home

    Thanks for this post. Very informative and it has helped me a lot. I actually moved my blog from Blogger to WordPress because I felt that is was more secure. I actually thought that I wouldn’t have these types of security issues with WordPress, but there is always something or someone lurking and looking to steal your information. After reading this, I will definitely take more precaution with my blog. It would crush me to lose everything I worked so hard for.

  • http://twitter.com/mercadder Mercadder

    Yeah, I use Cloudflare.

  • ConstantStrategies

    This is important for any site, with or without WP…

  • http://www.sm4good.com/ Timoluege

    I used Sucuri to clean my site after it had been hacked. Worked like a dream.

  • JeroSystems

    Would this bit of code do the same trick?

    RewriteEngine On

    RewriteBase /

    RewriteRule ^index.php$ – [L]

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

black friday 2014