Written by on

Ongoing WordPress Security Attacks, The Details and Solutions

There is a very real, very large ongoing attack against WordPress sites. It has been going on for a while now, but it severely escalated last week.

While there is a lot of chatter about this situation around the web, I thought I should write this post for two reasons: 1) not everyone in our community follows all of the WordPress and tech news and 2) most of the coverage has been either extremely technical or very light on details and recommendations. My goal in this post is to not only inform you about what is happening but why it is happening and what you can do about it.

The Attack

The details of the attack has been covered far and wide. Hostgator was one of the first big names to break the news about the attack with their Global WordPress Brute Force Flood post. The WordPress security team at Sucuri has as series of blog posts about the topic covering how to protect your site, the reality of the attacks, and the consequences of such attacks. Security blog Krebs on Security has a good post covering the topic in depth.

The short and simple explanation of what is happening is that one or more illegal botnets (a network of hundreds, thousands, or millions of compromised computers that are being exploited to perform attacks, send spam, etc) are being used to brute-force attack WordPress sites. The goal of a brute force attack is to try as many username and password combinations as possible in order to find valid login credentials. It’s as if someone was trying to guess the combination on a combination lock, but rather than being limited to a single guess every few seconds, they could make hundreds or thousands of guesses a second while never getting tired.

The Goal

As described above, one or more botnets are being used to perform these attacks. While the actual goal of these attacks is unknown, it is safe to assume that the purpose of these attacks is to compromise more systems, thus increasing the size and strength of the botnets.

As you can see in a description of the types of attacks that botnets can execute, botnets can be used to shut down websites, compromise security of high security systems, be used to commit fraud, send spam, and perform a number of other illegal activities. The simple reality is that botnets are big business these days. In the interest of security of the internet as a whole, it is the responsibility of all of us that run websites to do our best to prevent our systems from being compromised and becoming part of the problem.

The Threat

There are two threats to your sites during this attack: a threat from the login attempts and a threat if a login is successful.

Each time WordPress handles a login attempt, your server’s resources are being used. If the attack starts to send numerous login attempts a second, your site’s performance can suffer. Depending on your hosting, you might even have your service suspended due to the increased load your site is adding to the server. This last scenario is a worst case example and is very unlikely to happen, but it is still a possibility and is worth mentioning in order to clarify the potential severity of such attacks.

If the attacker is able to successfully guess the login to your site, then your entire site and server could be compromised. If the user has a role of Administrator, this opens up the ability for the attacker to modify anything on your site. They could add new files, modify existing files, add additional users in case the password of the compromised user is changed, inject malware into the output of your site, turn your hosting account into a spam bot, and anything else the attacker could possibly desire using a random server for.

The Pattern

The good news is that there is a pattern in these attacks. By finding patterns, intelligent solutions to protect against the attack can be created.

After reading numerous security postings about this issue and looking at my own logs on the attacks, it is clear that the vast majority of these attacks are focused on trying to figure out the password for the “admin” user. Looking at the stats for one of the sites that I’m watching, just shy of 99% of the login attempts have been for the “admin” user. The bulk of the other guesses are for usernames of “administrator” or “Admin”. There have also been a few that try using the main part of the domain name as the username. For example, it would try guessing “ithemes” if trying to log into the ithemes.com site.

Update: After posting this, the bots are now trying some additional usernames with some frequency. The new usernames being tried are “editor” and “moderator”. Each of these now account for more than 10% of the login attempts being tried. It would be a good idea to not have any users with a username of “admin”, “editor”, or “moderator” on your site. If you have any such users, the next section describes how to remove them.

There is also a clear patten in the passwords being guessed. This is natural as people have a very bad habit of choosing very weak passwords. Unfortunately, the things that are easy for us to remember are also quite easy to guess. Looking at the passwords being guessed over the past few days, the following passwords come out on top as the most frequently guessed ones:

  • admin
  • admin123
  • 123456
  • 123123
  • 123456789
  • password
  • 1234
  • root
  • 1234567
  • 12345
  • qwerty
  • welcome
  • pass
  • abc123
  • 12345678
  • 1111
  • test
  • monkey
  • iloveyou
  • dragon
  • demo

As you can see, there is definitely a pattern of basic English words and easy to type letter or number sequences. The reason that these are being guessed frequently is that they are likely to work on the greatest number of sites. In other words, they are being guessed because people still use such passwords.

There are a massive number of computers that are taking part in this attack. Some reports show more than 90,000 unique IP addresses taking part in this attack. Just one of our sites has seen 246 unique IP addresses being used to make login attempts. This is the power of a botnet attack as the attack is literally coming from everywhere.

The Solution

Brute force login attempts are by no means new. Such attack techniques have been used against WordPress sites for as long as WordPress has existed. In the past, I’ve recommended users install and activate the Login Lockdown plugin as it helps protect against brute force attacks. It protects the site by blocking login attempts by a specific IP once that IP has failed too many times in a row. Unfortunately, as the pattern section above shows, these attacks are coming from a huge range of IP addresses. Simply being able to block specific IP addresses after failed attempts will not protect a site against this botnet attack. This means that a different solution is needed.

 Remove the admin Username

Looking again at the pattern details, the first thing that all WordPress site operators must do is remove the username “admin” from the site. By far, this is the biggest vulnerability that is being exploited in this attack. So, if you have a user with a username of “admin” on your site, it needs to be either removed or renamed ASAP.

The easiest way to rename the user is to replace it with a new user. This can be done in the following sequence of steps:

  1. Create a new user with the same role as the “admin” user. This is typically the Administrator role. You may have to use a different email address when creating this user as each user must have a unique email address.
  2. Log out.
  3. Log in as the new user.
  4. Delete the “admin” user.
  5. When asked what to do with the posts and links owned by the “admin” user, select the “Attribute all posts and links to” option, choose the new user from the drop down list, and click “Confirm Deletion”.
  6. Once the user is removed, you can change the new user’s email address if a different one was used to create it.

While there are plugins that allow you to change a user’s username and it is possible to rename the username in the database, I’ve always preferred this method. The primary benefit is that this method is very fast and easy. The secondary benefit is that I’ve seen some WordPress hack scripts that explicitly modify the database records for the user with an ID of 1. Since the “admin” user is likely to be the user with an ID of 1, deleting it means that these hack scripts can’t function. It’s not a hugely important thing, but it is nice to know that some of the simple scripts that are floating around out there will fail on sites that don’t have a user with an ID of 1.

Use a Better Password

I really debated if this should be first or second. The reality is that removing the “admin” username will almost certainly protect you from malicious logins from this attack. However, a bad password makes you very vulnerable to just about any other attack. If you have any users that have a password that is listed above or that have a password that is similar in simplicity to those listed above, go and change those passwords immediately.

The question of “how do I create a better password?” has endless answers. There is the classic go to XKCD comic Password Strength which shows the problem we’ve created by forming hard to remember yet relatively easily broken passwords rather than focusing on easy to remember yet very hard to break passwords. If you search around, you’re likely to find hundreds of different guides on how to create secure passwords.

The problem with most guides you’ll find is that they either help you create complicated short passwords that are supposedly easy to remember, such as “fl1r7“, or very long passwords such as “ComplekspasswordsRsafer2011.” The problem I have with these suggestions is that they are always unrealistic. Today I might find it easy to remember that I need to change every third letter to a number, but in just a week, I could be confused as to whether it was every second letter is a number or if every fourth letter is a number. In addition, really long passwords are 1) not easily remembered at all (sorry Randall Munroe of XKCD) and 2) are even more of a pain to type in all the time.

To compound this issue is that the biggest threat to your passwords is password reuse. If you use the same password all over the place, all it takes is for one of your accounts to be compromised in order for the attacker to gain access to nearly all your accounts. While it is very bad practice, many online services store passwords in plain text or with only very basic modification of the password. Over the past few years, there have been tons of reports of sites having their user database compromised and leaked on the net. Once attackers get these leaked login details, they quickly use the details to try to compromise accounts on other services. So, if you use the same password on twenty sites, a password leak on just one of those sites makes your accounts on all twenty sites vulnerable.

So, we need passwords that are 1) not short, 2) not simple, 3) simple to input repeatedly so we’re not tempted to violate the first and second rules, and 4) able to be unique for every site we use. There are all sorts of tricks I’ve seen to get past the fourth rule. The common one is to use the name of the site in the password, such as “password123youtube“. While this will indeed make the passwords unique to each site, all it would take is someone looking at the password to figure out the pattern and apply it to other sites. So, the fifth rule is 5) ensure that in following 1-4 that we don’t create passwords that can be easily guessed if someone sees the pattern.

While struggling with this myself a while ago in my quest to have better passwords, I found that we humans just aren’t good at this. To make good passwords, we basically need random noise turned into a decently-long sequence of characters. This is not something that we do well at.

The solution I ended up going with was LastPass. LastPass is a password service. It centrally manages all of your passwords and has tools to easily create very complex passwords. It even has browser integration features that allow you to have LastPass automatically fill in the login details for you (no typing required). LastPass also offers apps for mobile and tablet platforms and has a web interface in case you need the password and can’t get it any other way.

Using LastPass allows me to have extremely complex passwords that I could never remember and would hate to type in on every site I use. I vary the length of my passwords that it generates, but they are always more than 25 characters as long as the site allows it. 25+ characters of more or less random characters… Good luck brute force guessing that in my lifetime.

The key to using LastPass is having a good password to authenticate your user there. This is the only password you will need to remember; so make sure that it is a good one. Don’t do yourself the disservice of having your one weak password give full access to all your strong passwords.’

There are alternatives to LastPass. I don’t have personal experience with any of them, so I can’t give a recommendation. The ones that I’ve seen most often are:

  • KeePass – An offline, cross-platform password manager. Basically, this is an encrypted local copy of your passwords as they aren’t stored on any server. I’ve seen people use Dropbox to allow their passwords to sync to different systems.
  • 1Password – A paid password manager with option to sync to the cloud. I know at least one person in the office uses this software.
  • Keeper – Seems to try to compete directly with LastPass in terms of feature set.
  • RoboForm – Another service similar to LastPass.

Protect Against Performance Issues

Now that your site doesn’t have the “admin” user and your passwords are very difficult to guess, you are still left with the problem of bots constantly trying to log into your site. Solving this problem is probably one of the harder ones. Technically, the site is safe, but you don’t want your site’s performance to suffer just because some bots are hammering your server.

My first recommendation is to talk to your hosting company. I’ve seen a number of hosts suggest opening up a support ticket as they can help block some of the attack. I’m not sure exactly what methods these companies are using, but there are a variety available that could be quite effective.

If you are on a self-managed server or have a host that can’t help, I’d first look to see if your site is being hammered with requests. You can do this by looking at the access logs for your site. Simply look to see how often the wp-login.php page is being requested. If you have a very big community, then you might see a lot of requests for that page as just a normal part of site operation. If the number of requests is relatively-low (a few a minute or less), then I wouldn’t worry about taking any action. Such a low number of login attempts is unlikely to affect your site, and adding additional changes just runs the risk of damaging a functional site. If the number of requests is higher (especially if there are numerous requests each second), then I would pursue other options more seriously.

The easiest option to consider after talking to your hosting company is using CloudFlare. CloudFlare is a CDN service that also helps protect your site against attacks of this nature. In response to this situation, they posted details on how they handle such brute force attacks. I’ve used a free CloudFlare account for my personal site for the past few months. While I don’t know exactly how much traffic CloudFlare is blocking, I do see a very low number of requests to my site’s wp-login.php page. There is an official CloudFlare plugin. I don’t use it personally as I don’t make use of the caching feature of CloudFlare, so I can’t speak to the benefits offered by it.

Unfortunately, if your hosting company can’t help you and CloudFlare isn’t an option, the only remaining solutions are quite technical and may require root permissions on your server (something not available to shared or managed hosting accounts). If you don’t know much about server administration and are having issues with the attack hurting your site’s performance to consider moving to hosting that can protect you from the attacks. Make sure that you contact the potential new host beforehand to see if they are prepared to help protect your site from the attack.

The most prevalent technical solution is using ModSecurity rules on Apache to limit the login attempts. Of course, this requires that your server is running Apache and has ModSecurity available or you are able to install it.

Another popular solution is to password protect access to the wp-login.php file and wp-admin directory. A big benefit of this is that the requests won’t hit WordPress at all unless they are authorized, reducing the relative load of the attack to nearly 0.

Update Your wp-config.php Keys

The wp-config.php file contains a series of security keys. These keys are used for different authentication and security methods used by WordPress. The keys should be unique to each site. Unfortunately, old WordPress installs never had these set, leaving a potential security hole. Updating the keys is highly recommended to protect your site against a variety of different attacks.

Note that changing these will cause everyone to need to log in once again. This is a feature really as any compromised login will be invalidated.

The Treatment

What do you do if you think your site was compromised? Unfortunately, the only sure-fire solution is to more or less start over:

  1. Create a full backup of your site.
  2. Delete all the files on your site.
  3. Download a fresh copy of WordPress.
  4. Unzip the WordPress files.
  5. Upload the WordPress files to your server.
  6. Inspect the wp-config.php file from your backup to look for any suspicious code. Comparing the file to the wp-config-sample.php file in the newly downloaded WordPress files will help identify any issues.
  7. Copy the wp-config.php from your backup to the new site.
  8. Download fresh copies of your themes and plugins from the original source. Make sure you don’t download the files from random sites on the net as these frequently contain malware.
  9. Unzip the theme and plugin files.
  10. Upload the themes and plugins to the site.
  11. Run the site to verify that it functions.
  12. Delete any users that you do not recognize.
  13. Change the password of each user. This is important as it is possible that the attack changed passwords and would allow the attacker to compromise your site again. By resetting each users’ password, you ensure that the passwords are what you expect them to be. Of course, when you are doing this, make sure that you apply the above recommendations. Don’t leave an “admin” user and don’t use simple passwords.
  14. Go through the wp-content/uploads directory in your backup and copy the directories to the new server. Ensure that what you are copying are media files (images, audio, video, etc). If you find any PHP files, do not copy those to the server.

Yes, this is tedious, but it is the only way to be sure that modifications put in place by the attacker don’t remain. Even a single file or a single file modification that is left behind could cause your server to be compromised all over again.

You may wonder what this means if you multiple sites. Unfortunately, if you have a hosting account with a large number of sites, you have to treat the entire account as compromised. Limiting your focus to just one site on the account leaves you open to the possibility that other sites were modified.

The Prevention

Okay, the final heading is a bit contrived. It worked well up until now. :)

There isn’t such a thing as full-proof security. It simply doesn’t exist. That doesn’t mean that you should give up. Ignoring all security measures is just asking for trouble. However, going overboard on security is likely to be a waste of time. So, a balanced approach is what you should use.

I mentioned the Login Lockdown plugin earlier. While it won’t save you from this attack, it is definitely still recommended. Until WordPress gets some built-in brute force protection (hint, hint devs), running a plugin such as this one is highly recommended.

A hat tip to James McWhorter who points out in the comments that Login Lockdown has a “Lockout Invalid Usernames?” option. Enabling this option in the plugin’s settings will automatically block login attempts that use an invalid username. This could greatly help in protecting your site from this specific attack.

Some people have asked in comments and tweets about the age of the Login Lockdown plugin (since it does display a notice on its page). I have run the plugin for many years without issue, so I know from personal experience that it works well with current versions of WordPress, including multisite installs. While I could suggest other plugins that have similar features and do not have warnings about age, I recommend Login Lockdown since I can recommend it without reservation.

Follow the recommendations given in The Solution above on all of your sites. They help protect you against much more than just this attack.

Always keep your WordPress sites up to date, including plugins and themes. This is critical as security holes in older versions are found given enough time.

If you have a large number of WordPress sites, and they are becoming difficult to manage, consider using a multisite install to centralize many of your sites. This allows you to more easily keep WordPress and its themes and plugins updated. Another option is to use ManageWP which allows for management of multiple sites from a central location.

While the passwords you use to log into WordPress are important, the passwords to access your hosting account are just as important. If your FTP or cPanel password is easily guessed, you are still vulnerable. In addition, WordPress allows you to reset passwords by email, so if your email account is vulnerable, so is your site. After you finish improving the passwords for your sites, go and improve the passwords used for your hosting accounts and email.

One potential security issue many people don’t think about are the plugins and themes that aren’t in use. It may come as a surprise that inactive plugins and themes can still be used to compromise a site, but it is very true. The Timthumb exploit of a year and a half ago worked just as well with an inactive plugin or theme as an active one. So, rather than leaving a large set of deactivated plugins and themes on your site, back them up somewhere and delete them.

The Conclusion

I hope that this information has been helpful. I really wasn’t sure if I should post this or not since so much has been said about it already. If you would like to see more posts of this nature in the future, please leave a comment saying what part of the post was most helpful to you.

Comments

  1. Another question, when you mention that old WordPress installations never had security keys set, how ‘old’ is old, would you say? If you are updated to the latest version of WordPress should you generally be ok, or would you recommend taking that precaution anyway and resetting the keys?

    • If you look in your wp-config.php, you’ll see a section named “Authentication Unique Keys”. Below that comment, you should see a set of eight defined keys, such as:

      define('AUTH_KEY',         'put your unique phrase here');
      define('SECURE_AUTH_KEY',  'put your unique phrase here');
      define('LOGGED_IN_KEY',    'put your unique phrase here');
      define('NONCE_KEY',        'put your unique phrase here');
      define('AUTH_SALT',        'put your unique phrase here');
      define('SECURE_AUTH_SALT', 'put your unique phrase here');
      define('LOGGED_IN_SALT',   'put your unique phrase here');
      define('NONCE_SALT',       'put your unique phrase here');

      If you only see four, or if you see “put your unique phrase here” (as shown above) rather than a set of random characters, then your keys are outdated and need to be updated.

  2. This is really an excellent article. I’m pleased to have bought Backup Buddy and joined this community. Prompted by this piece, I did a small blog post of my own on this subject, in which I talk about the simplest (and you would think the most obvious) steps – that of deleting Admin and using a decent password and I’ve referred my own site visitors to your article for the full explanation!

  3. Hello,

    I have a question about the Login Lockdown plugin. I noticed it has not been updated in over two years. Do you know of a more recent plugin similar to LL or do you feel this plugin is stil OK to be installed? Thank you for your help.

  4. Thanks for this great article Chris. I’ve been wondering about something…how do these brute force attacks manage hundreds or thousands of login attempts/second when it can take a second (or several) for the WP server to process the login and return a successful or unsuccessful result?

    • I’m glad that you enjoyed it Jacob.

      Not every site will receive login attempts that reach the magnitude of many a second. Some sites may be hit only a few times an hour (if at all). Other sites may get many requests a minute. A few sites may get a surge or consistent flood of many login attempts a second.

      A page load that you see on the browser represents the culmination of many elements:

      • The time taken to send the request to the server.
      • The time taken for the server to generate and start to send the response.
      • The time taken for the web browser to start to receive the response.
      • The time taken for the web browser to parse the response.
      • The time taken for the web browser send requests for additional files, such as stylesheets, Javascript files, images, etc.
      • The time taken for the server to handle those requests for additional files, process any necessary processing to serve those files, and to send them out.
      • The time taken for the browser to get those additional files.
      • The time taken for the browser to render all of those elements as a visible page.

      So, a lot happens in a short amount of time.

      When this attack floods a server with login requests, if the number of requests over a specific period of time exceed the ability of the server to be able to process and respond to all of those requests, they will cause site performance to suffer. There have been numerous reports of WordPress sites being slowed down tremendously due to the large number of simultaneous login attempts. This is why I mention in the article that the threat of this attack is both the compromised security and decreased performance.

      If the number of login attempts is so great that the site literally can’t operate anymore, then the attack can turn into a DDos, a Distributed Denial of Service attack. While I don’t think that this is the goal of the attack, it certainly can have that result if too many requests hit a site that cannot handle them.

  5. Once again, it’s not only the amazing products I love about ithemes, it’s the clear, relevant, helpful information you consistently provide.

    A quick question. I looked in my profiles and noticed only the nickname, which it said is required, said admin, while the actual name (that I login with) is something else. Do I need to change the nickname too?

    Also, I’m wondering about your feel of using a 2-step verification process like google authenticator.

    Thanks again.

    • The nickname is not used for any authentication. It is simply the username that is used to log into the site. So, having a nickname of “admin” is not an issue.

      2-step verification processes are very well regarded in security circles and are widely considered to be the next logical step for most authentication practices. I don’t have any personal experience with Google Authenticator, so I can’t give a personal recommendation.

  6. Thanks for this post, Chris, most informative. I’ve spent the last few hours removing admin id 1 and beefing up Wordfence settings for a whole bunch of sites.

    Would adding .htaccess password protection to the wp-admin folder as an extra login have any merit? Or would that interfere with Backup Buddy schedules?

    • I don’t believe that password protecting the wp-admin directory would have any effect on scheduled backups. I’ve never seen any problems such as those occur due to such changes. If you add such a change to your site and see issues, please make sure you post about it in the BackupBuddy forum.

      As for the merit of such protection, I think it is a great idea as long as you are willing to handle the technical aspect of setting it up, managing it, and dealing with any potential technical issues that might come up from such a setup (again, there shouldn’t be any issues, but I cannot guarantee that).

      If you add such protection, make sure that you protect the wp-login.php file with the same type of protection as it is much more important to block requests to this file than other files.

      I should note that such a procedure should only be used if you know all the users who will be logging into the site and can give them the procedure for authenticating. Such a procedure is likely to be difficult to implement on sites where many users log in to access site resources.

  7. Great post. Didn’t knew about the ID1. Continuing on that.. wouldn’t it be easy for hack scripts to check on the user_register date? The Admin would probably be always the oldest user.

    • Every so often, I come across code that actually powers some of these attacks. They are often very poorly designed and lead me to think, “good thing a person who knew WordPress better didn’t design this.” I’ve yet to see any code that tries to modify user records in the database that are anything other than 1) try to modify every user or 2) try to modify the user with an ID of 1.

      So, it’s not a matter of what is easy or not, it’s a matter of what is actually out there in the wild. In general, what is in the wild is quite simplistic. That doesn’t mean that such code isn’t effective however, as I would wager that most WordPress sites have a user with an ID of 1.

      • How much of a risk would you say the ID1 thing is if I have all the other counter-measures in place (i.e. no “admin”, strong pw, limit login attempts plugin, Bulletproof Security, unique keys, etc)?

        I’m wondering because it sure would be a pain to have to go back to all my client sites and replace the original users with new ones. Do you consider the risk to be worth it?

        • The code that affects user ID 1 is code that an attacker runs on the site once it has been compromised. A site can be compromised in many ways and not just by brute forcing a valid login. So, they are different situations really.

          The information about the side benefit of no longer having a user with an ID of 1 is just an aside really. I don’t think that it is critical or even important to not have a user ID 1 on a site.

          • Good to know. Will probably include it as part of my strategy mix on future sites since it is so easy to do when first setting it up.

  8. Hi

    Interesting.

    I have been recommending Login LockDown, and LastPass, but have also suggested WP-Better Security, and BP Security to help lock down any attempts to get into your installs.

    This has the advantage that you should be covered from other types of hacking too.

    People have been securing their sites following the recommendations, and therefore have helped us all to reduce the power of BotNets.

    I have also noticed several people rushing out to release some products.

    I plan on adding some videos to show how to use LastPass – to show how easy it can be to have really complex passwords from now on, and some other related subjects.

    Good you are sharing this, together we can make all of the WordPress installs hardened, making any future attempts that much more unlikely to get anywhere.

    Posted By Jon Barry of JonBarry.co.uk

  9. I just take full daily backup and store it remotely.

    Last year a host was hacked and they also deleted 4,300 sites from the backup server.

    I think they’d find it hard to crack a password thats between 20-30 digits as well.

    And you probably wouldn’t be targeted as much if your username is 10 digits long rather than using admin.

  10. Hi Chris! A little doubt:

    How do you look specifically for this attempts on you log? Is it a special WordPress log or Apache’s?

    Thanks for you post! Very useful (:

    • I’m sure that there are a number of plugins that log and can report on the types of login attempts and the information they are sending. Looking at the access logs, you can see the requests for the wp-login.php file which includes IP address, user agent, referrer details, and a timestamp of when the request was made.

      I wanted something simple that gave me a timestamp, user agent string, referrer, IP address, and GET and POST variable data. With all of this information, I could really get a sense for how these requests were being made. To do this, I added a modification at the top of the wp-login.php file. It’s not the most elegant solution, but it works quite well and hasn’t shown any noticeable performance issues (since it only runs when the wp-login.php file is requested). The following code was added at the top of the file:

      if ( ! empty( $_GET ) || ! empty( $_POST ) ) { 
          $data = array(
              'timestamp'       => date( 'Y-m-d H:i:s' ),
              'HTTP_USER_AGENT' => $_SERVER['HTTP_USER_AGENT'],
              'HTTP_REFERER'    => $_SERVER['HTTP_REFERER'],
              'REMOTE_ADDR'     => $_SERVER['REMOTE_ADDR'],
              'POST'            => $_POST,
              'GET'             => $_GET,
          );
          file_put_contents( dirname( dirname( __FILE__ ) ) . '/login-attempts.txt', print_r( $data, true ), FILE_APPEND );
      }

      I can then use shell commands to filter through this information. The following command shows me how many times a password has been tried while removing ones that were only tried once:

      grep -o '\[pwd\] => [^ ]*' login-attempts.txt |sort|uniq -c|sort|grep -v ' [0-9] \['

      By looking through the data, I can see interesting trends, such that the 92%+ of the requests use the following user agent string:

      Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko Firefox/11.0
  11. I maintain many WP sites, all of which I use ADMIN as the user so I really appreciate this info! I just added a new user to one of my accounts and then tried to delete the older “admin” user, but its not letting me. I’m getting this error. Any suggestions?

    You have specified this user for deletion:

    ID #1: admin The current user will not be deleted.
    There are no valid users selected for deletion

    • You have to log out of the “admin” user account and log into the new user account before you can delete the “admin” user account. In other words, you cannot delete a user that you are currently logged in as.

  12. Login Lockdown is a great plugin and I used to use it on every site I built. I’ve more recently changed to Wordfence Security http://wordpress.org/extend/plugins/wordfence/ also recommended by Toby Drysdale (above). So far, none of the sites I work on have been exploited so I believe it’s doing it’s job well.

    This is a great and very useful article and I agree with everything Chris wrote. I would like to know if Chris has any take on the Wordfence Security plugin compared to Login Lockdown if you’ve had the opportunity to check it out.

    Thanks for taking the time to better inform the WordPress community on security Chris. It’s often the overlooked component to WordPress as well as many other pieces of software.

      • No problem, thanks. It might be worth checking out when you have time. I think they did a great job with it. I do agree that Login Lockdown is also a fantastic Plugin that does what it’s supposed to do and does it very well.

  13. As the article says the botnet has gathered a range of ip’s to initiate attacks from, so ip lockout plugins are not necessarily very useful… 1 thing we have implemented is to block access to the admin in the .htaccess file, and sepcify specific ip’s for access within it.

    • I’ve seen people report that it won’t try to make requests on an SSL connection, so if you force the login to be on an SSL connection and forward non-SSL requests for wp-login.php to the SSL version, the brute force login attempts never successfully make a login attempt as they aren’t looking for the redirects. I don’t know the details behind all of this, so it could require a specific kind of setup in order for this to be effective at “fooling” the bots.

      While such an approach could be effective against this attack, I wouldn’t count on it long term as the next bot might avoid this limitation.

  14. Thank you for this excellent, in depth analysis of the situation.
    I have seen odd things happening recently and ‘new users’ appearing out of the blue in my e. mails. Will be following your advice to tighten security!
    Best wishes,
    Tony

  15. I installed Login Lockdown and another plugin called Debug Bar [http://wordpress.org/extend/plugins/debug-bar/]reported that it is using function calls that were deprecated many years ago.

    Login Lockdown worked fine on my WordPress 3.4.2 site (yes.. I’m upgrading that too), and has been reported to work on WordPress 3.5.1. However, I think running a plugin that has not been updated in years and has deprecated function calls is asking for it.

    So, I uninstalled it and installed Login Security Solution instead [http://wordpress.org/extend/plugins/login-lockdown/].

    • The portions that are deprecated are of little concern. They really don’t affect anything.

      That said, I sent a patch to the author of the plugin this week as he’s working on an update. So, he should have an updated version out soon (I don’t know exactly when soon will be however) that adds additional features and removes the deprecation notices.

  16. I looked at Login Lockdown but it looks like it is abandoned as it hasn’t been updated in years. Instead I am using WordFence which is doing a job great, and also sends notifications of problems like out of date plugins, security updates etc.

  17. Chris, excellent point on the first user being an ID of 1 in the database. I never thought of that. Having a username that isn’t “admin” is the first step but essentially creating and deleting the initial user on a new WordPress install could be a best practice.

  18. I’ve had login lockdown on my site for several years, and recently deleted it because it hasn’t been updated in two years. The page you linked to says it ‘may’ not be compatible with recent versions of WordPress. Comments??????

  19. Nice article, and some good tips.

    However, if you are doing to delete the admin user, and then replace a new username on all of the existing posts… you are then giving up your new admin username.

    So wouldn’t it be better for that replacement username to NOT have an administrator role? That way you are never exposing the admin username at all and a brute force attack would be nearly impossible to figure out what username to even begin with.

    • possible solution-Create a new admin without the admin username and with another email that you have, create an author user role for the posts and attribute the old admin posts to the author user instead of a user with an admin role

        • Chris,

          is there a way around that so that the author archive does not show the username, but instead the name that I have chosen as the ‘display name as’?

          this seems like a security flaw on the part of WordPress

          • The short answer is that you really shouldn’t worry about it. Usernames are not meant to be hidden or unknown. Relying on hiding your username means that your password is likely weak, which is the real issue. I suggested that people remove the “admin” username not because this is the best practice in terms of security but since I can’t ensure that everyone will use quality passwords, it was the best advice I could give to a general audience.

            Technically, the link is generated off of the user’s nicename and not the username; however, depending on your username, the nicename and username may match. Basically, WordPress generates the nicename by running the username through the sanitize_title function which does things such as changing spaces to dashes, changing the text to lowercase, and removing special characters. So, if your username contains spaces, uppercase characters, and/or special characters, your username will be different from the nicename. You also could use a plugin such as this one to change the link.

            Again, I think that “hiding” your username in this way is unnecessary as a secure password is much better security than hiding the username. I provide this information not as a recommendation but just to provide a complete picture.

    • As Ann suggests, to do what you are suggesting, you would need two new accounts: one to be the new administrator and one with a role of Editor that will inherit the content of the deleted user.

      In security, there are things that are considered secrets that need to be protected, and there are things that are considered not secret and do not require protection. In a username and password login, the password is the secret, not the username.

      Just look at Twitter. Everyone knows your username. The security is offered by a robust password. If you don’t use a good password, the game is up. The same can be said of email or even your bank account (assuming that the account number on all your checks works as your username).

      In WordPress, there are many ways to figure out usernames. As you point out, ensuring that none of the administrator level users author content can obscure the username of the administrator account, but if the administrator account has a poor password and the username is guessable (or able to be found in other ways), then you still have failed to adequately secure the site.

      This means that the key to security is good, solid passwords.

      Even in this botnet attack, if your site has an admin user and the admin user has a sufficiently-strong password, then the bots can try to break into the site all day, every day for years and not gain access.

      Case in point, a password that has 15 characters that are a mix of lowercase letters, uppercase letters, numbers, and symbols would statistically take 1.5 million centuries to crack, and that’s if the attacker could guess one hundred trillion guesses a second). Use a tool such as LastPass to generate and store per-site, unique, complex, long passwords, and brute force attacks are going to be a nuisance rather than a security threat.

      In this blog post, I recommended that people remove the “admin” user not because you can’t secure that user with a good password, but because I have to assume that even if I tell people to use good passwords, that many are likely to choose bad passwords. Thus, the best recommendation that I can give that will actually make a difference is to have them remove that user while also trying to get them to think about using better passwords that are unique to each site in a way that is easy to implement.

      • Yes, a strong password is critical. I use LastPass for that. But why not make it even tougher by not using an easy-to-guess admin username? That’s got to significantly decrease the likelihood of a brute-force breach.

        • There are many ways that WordPress, a theme, or the multitude of plugins may leak valid usernames with or without your knowledge. Thus, it is safer to assume that knowledge of valid usernames is known and that the complexity of the password is what is keeping the bad guys out. Assuming that your username is unknown simply sets you up for believing that you have security in a place where you possibly have none.

          Another thing to consider is that the WordPress database stores the username in plain text while the password is a salted hash. This means that if someone gets your database backups or can otherwise access the data somehow, they still have to crack your password in order to gain site access. This goes back to my prior comment where I indicate that a complex password of just fifteen characters would arguably be uncrackable except for those that are extremely determined and have a huge amount of resources at their disposal.

      • When I saw that I was getting brute-force attacks on my admin account on several of my sites, another strategy occurred to me. I’d like to run it by you and get your feedback.

        I have an administrator account with a different name on each of my sites, but I still have a user named “admin” with ID of 1, which has a *very* long password generated by LastPass, and requires two-factor authentication. And it has no role or access to the site.

        I also use the “Limit Login Attempts” plugin with a an initial lockout of an hour, and a lockout of 8000 hours after 3 one-hour lockouts.

        I have found one problem with this approach. In the last 3 weeks, I have had three brute-force attacks on one site that continued after the lockout, and came so fast that they brought my site down by using up all my allotted resources. I was able to recover by adding the IP address to the deny section of .htaccess, except for one that was so big that I had to get the hosting service to put it in their firewall iptable because I couldn’t even access the cPanel.

        I’ve thought about perhaps writing a plugin (or hiring it written) that detects any attempt, even an successful one, to login as “admin” and just enter the first 3 octets (I noticed that some of the earlier attacks just switched to the next sequential IP after I put it in the .htaccess) of the attacker’s IP into the .htaccess, since I already know that any attempt to log into “admin” has to be an attack. I don’t even keep a record of the “admin” passwords anywhere.

  20. Great article, which I intend referring some of my clients to!

    It is sad that we live in a world where there are so many people intent on harming others, whether it be online or offline :-(

    I use Symantec (Norton) Identity Safe tool bar for password management. It is not the best tool, but since I have in excess of 800 usernames and passwords it does the job.

    From a WordPress Security point of view; I have recently installed the ‘Better WP Security’ plugin on one of my sites and whilst it took a little while to set it up, it seems to work wonders. There are too many features to list here, so have a look at the plugin directory
    See: http://wordpress.org/extend/plugins/better-wp-security/
    (it has a 4.8-star rating & almost 600’000 downloads).

    I am most definitely going to install this on more sites as I was shocked to see how many login attempts are being attempted & then ‘locked out’ by this plugin.

  21. Thank you – I love this article. I’m relatively new and could easily understand the issues. I appreciate it!

  22. This is a thorough list of tips to help increase the security of a WordPress installation. Of course, the biggest weakness is the human element and choice of passwords. This is a challenge in most cases because the stronger a password is, the more difficult it becomes to remember so we have to compromise on one or the other. I recently wrote about how to achieve both a memorable and strong password recently on my blog… and, no, you don’t need to be a freak to achieve both.

    Agreed, having a password vault is a great solution to reduce the number of passwords that need to be remembered, but there is still a need to remember one strong master password to enter the password vault.

  23. It might be of interest that we have recently published another plugin for strong authentication. It prefers usability to security so you can either login with a password or with one-time code.

    If you’re on a secure network, you may want to use just your password but open your smart phone when connected through an insecure WiFi (cafe, train, …).

    We tested it with a few smart phone apps: Google Authenticator, Pledge, DS3 OATH, AWToken so you don’t have to rely on Google completely.

    Try to search for S-CRIB OTP Authenticator in the list of WordPress plugins or directly http://wordpress.org/extend/plugins/s-crib-otp-authentication/

  24. […] Even the latest hack attempts were not targeted to the software itself. It was an attack by sending brute-force password hack attempts for default users names and weak passwords. So make sure you don’t use admin as your administrator username and have a good strong password. If you want to learn more about those attacks, read WordPress Security Attacks and Solutions. […]

  25. […] In April 2013, there was a kerfuffle with hacking attempts on WordPress blogs. Weak passwords, and the username “admin” were the key vulnerabilities. If you blog with WordPress — and especially if you have a username of “admin” or “editor” or “moderator” — make sure to read this article which gives simple instructions for how to fix it. […]

  26. […] information regarding this ‘botnet’ attack and what you can do to safeguard your site, this is a good blog post that covers most of the info you need. We will continue to update and monitor all sites that we […]

  27. […] This blog post describes the attacks on wordpress sites as run by ‘botnets’ – automated programs that try to log into wordpress accounts to gain control of the account or the user’s computer. To do this, they need to crack the username and password, and they start with the most obvious ones, as the article explains. http://ithemes.com/2013/04/15/ongoing-wordpress-attacks-details-and-solutions/ […]

  28. Another thing you can do to secure your WordPress website from these type of attacks is to use two factor authentication. This way in the event that they brute force your username and password they still will not be able to login to your site without that code. The plugin I recommend for setting up two factor authentication is Duo Security.

    • Limiting attempts on specific user accounts is an interesting approach. The reason most plugins don’t do this is that it would be trivial for someone to consistently block you from logging into your own site by doing periodic login floods on that username.

      The original plugin code had the simple_login_lockdown_allow_ip filter which was a way to whitelist an IP address. While the simple_login_lockdown_should_die filter could be used to add similar functionality, it would be difficult for most users to know how to utilize that filter to prevent them from being permanently locked out of their own account while their username was being attacked. Even with an easy-to-use IP whitelist feature, it would still be a hassle as not everyone has a static IP that they can rely on.

      In other words, if it works for you, that’s great, but I would not recommend it for anyone but advanced users as advanced knowledge would be required to regain access under these conditions.

  29. First of all, thanks for the post Chris,

    I personally have tried the above as well as other techniques (mainly the ones on the WordPress codex site). I think they are a good starting point and an essential one. I would also add ensuring a good backup service. I used to use BackWPUP but now I use VaultPress. As for security, I would advice ensuring the basics like password (as you wrote here). Then, when you reach a plateau, you can get a free or paid service. I use Sucuri and, in fact I have blogged about they whys (http://usabilitygeek.com/wordpress-security-sucuri). There are of course other great services. Login limiting is also essential (although bots use different IPs) so a good password and username is always good. Another good solution that I found is using Google’s 2-step authenticator. There is a good plugin for that.

  30. I’m not seeing nearly the activity I was back when this post went up. Have the bots come to the conclusion that some sites are locked down (mine for example LOL) via a central database, and they’ve moved on to other prey? Or has it just died down period?

    • It’s hard to say. Attacks like this tend to come in waves.

      It’s possible that the bot code that was spreading around had a timeout period where it only functioned for a specific duration. Some of the bots I’ve seen take commands from IRC channels or Twitter feeds. So it is possible that those communication channels have been shut down or are not actively sending commands right now.

      While it might seem odd to have the attacks cease after a time, it makes sense when you consider that many people would not know that their site was compromised if it weren’t for the attacks it runs against other sites. So, having the scripts go dormant after a certain amount of time helps keep compromised systems more covert.

  31. Chris,
    What about those of us on the receiving end from comprimised wordpress servers?

    we’ve been getting HAMMERED with an attack where almost all the malicious traffic

    shows up with HTTP_USER_AGENT containing WordPress/(randomversion#); http://random.wordpresssitehackedhere.com

    we’ve tried taking to .htaccess and just outright deny anything containing wordpress in the user agent string but still getting hammered.

    any tips? also, our site isnt even running wordpress

    • I recommend talking to your hosting company. Since you will want to block the attacks from reaching your site, your hosting company would know what options are available for your specific server and hosting environment.

      Best of luck.

  32. Great article.

    Lots of great tips here on WordPress Security. Definitely recommend using all of these techniques to increase the security of your blogs. A couple of quick things to also keep in mind.

    Plugins: people need to make sure the plugins they are using are “trusted”. Not every free plugin you download has your best interest at heart. People do spend time hacking and then distribute fake or malicious plugins.

    Themes: same goes for themes. If you install a hacked theme, then many of your security measures may not make a difference at all. It is not that hard to program malicious code that can send login credentials out to a hacker.

    Responsibility: people need to take their blog security seriously. I don’t mean just installing a plugin and saying “oh I use that plugin and I am secure”. That’s not enough to cut it in this day and age.

    Hope for the best, Prepare for the worst: Security is a multifaceted discipline. Understand that if a hacker truly wants to break into your site that they will. It may take them a while, but any programmer worth their salt can do it. Assume your site is not secure and work towards keeping it “as secure as need”.

    Note, not as secure as possible, as that would just mean taking sites offline, but keeping up to date with the WordPress core files, making sure plugins are up to date, installing basic security such as a firewall, anti-virus, login limiter, general security plugin and understanding at least the basics of editing your htaccess files should be mandatory to anyone taking blog security seriously.

  33. I am a recent joiner to this scene. I set up my website in February and have been adding content. I use the Limit Login Attempts plugin, and get notified when there has been a lockout. This happens at least 3 or 4 times a day. I am starting to get concerned.How do I ensure that my theme and other plugins are secure , are the other plugins better, or do they have similar functions???

  34. Hi, one of my wp websites was recently converted to a spamserver and this is solved now but made more aware of vulnerabilty of your business. The question I have know is that I had build a wp site for a customer and I lost the password. Then I gave a guy on FIverr a gig and within an hour I could login again. Can you tell how this was possible?

  35. Posted above elsewhere about the security issues surrounding WordPress and while it’s NOT a gratuitous plug for the new(ish) security plugin from iThemes (http://ithemes.com/security), I have been testing with it and it’s been effective. Right off the bat, by rolling up the renaming of the wp-login.php and /wp-admin folder into this among many OTHER great features – well, if they can’t find it, they surely can’t hack it. Gotta love that. If it’s not this plugin here, there are others that have similar functionality. While security through obscurity isn’t going to win every time, the other features in this plugin REALLY do wonders. Installed it on a test site about a month ago – and am now in the process of rolling it out to at least half my sites. I prefer a non-homegenous environment just in case… Thanks iThemes – it DOES look like a winner.

    But, STILL getting banged on by bots on a daily basis – and now we have the awesome “heartbeat” issues from WordPress as if our servers weren’t already stretched for resources handling the bot thing.

  36. Wow!!! It is a very in-depth and extensive article on the security issues related to wordpress. I am seeing a lot of emails from Wordfence in the last two days that someone is trying to login into my wordpress for one of my websites and it brought a lot of concerns to me.

    Although, I made sure that my username and password are very strong but still there isn’t any security which is fool proof, as you rightly pointed out.

    I think I should try Login Lockdown plugin and receive its benefits.

    Thanks a ton, Chris, for sharing your insights on the WordPress security issues. They will help me a lot, I must say. :-)

Respond

×

Ends Today! Save 35% off BackupBuddy with coupon code BACKUPWP35