Informational Extremely Large WordPress WP-Admin Brute Force Attacks

[Michael D.]

There is an ongoing WordPress brute-force attack that is affecting a large number of providers. CloudFlare has made a blog post about the issue and has reported that the attack is coming from upwards of 100,000 individual IP addresses or systems. Many providers have had entire servers taken offline and accounts compromised as a result of this ongoing attack.

While we haven't had any servers go offline as a result of these attacks the larger issue comes as a result of any compromised WordPress installations that may result from this attack. Should your WordPress installation be brute-forced successfully, the attacker could upload malicious files to your account to include your account in this attack, future attacks, or worse. They could view all of your data, delete your data, modify your data, etc.

One basic step that can be taken to protect your WordPress installation and your account with us, is to make sure that you are not using the default username of 'admin' for your WordPress administration. This is the default username for a new WordPress installation. WordPress does suggest changing this username as a method of security through obscurity.

As a result of this attack we've chosen to take a step that we would not ordinarily take, and that is to change the log-in username of any WordPress installation where it is currently 'admin'. This not only will help keep your account secure from this attack, but also from all possible future brute-force attacks on your WordPress installations while still allowing you full access to your WordPress administration via the new username. Keep in mind that if you've already changed your administration username to something other than 'admin' or you use an alternate username to log-in to your WordPress administration - this change will not affect you.

In the interest of keeping your WordPress installation secure, and keeping the username obscure from potential attackers we are not going to include the new usernames into this post. We are going to be sending out a mass mail to all of our customers advising you of the change and what the new usernames are. We are making this post on our forums as well as cross-posting it on our FaceBook Page, and our Twitter Feed to help ensure everybody is aware of this change.

If you have any questions about this, you are welcome to ask them here if they are generic in nature. If your questions are specific to your account, do please open a support ticket and a member of the senior staff will answer your questions concerning this.

Update regarding WordPress Network/MultiSite:
An issue has come to our attention regarding WordPress Network Installations (formerly WordPress MultiSite). If you were previously using the default 'admin' log in to access all of your WordPress network sites and can no longer access other sites in your WordPress network with the new username, please open a support ticket so can verify the issue and correct it for you. When opening the support ticket, please be sure to include the URL to access WordPress, and if possible, the WordPress database name.

Do not reply on our forums to request assistance with this issue. A support ticket is required to protect the privacy of your information.

Edited June 20, 2013 by MikeDVB
Added updated regarding WordPress Network

[frankacter]

And, as suggested in the linked article, CloudFlare is acually mitigating the issue for all of their users (free & pro) automatically by detecting the signature of the attack and blocking it.

 

The nice thing about this is that it prevents the traffic from ever hitting your server in the first place versu just being immune to the attack by absense of an admin account.

[Michael D.]

While that sounds ideal on the surface, it's up to the end user to sign up for CloudFlare and enable it on their site. It's not a bad idea regardless but we would never sign any of our customers up for a third party service without their express consent. CloudFlare, obviously, has a vested interest to push their service and obtain new users so their blog post is obviously going to have that slant to it.

 

Our senior staff did discuss how we would handle this for quite a while before taking any action. Some providers I'm aware of are disabling access to wp-admin entirely [which is something we discussed, but decided was not acceptable].

 

As an example, here is an excerpt from another provider's message to a potential customer of ours:

There is a an active brute force attack against WordPress sites accross the internet and this is creating issues with the network and servers. If your website and email is not working please visit http://myipdetails.com and let us know your IP address so that we may check any firewalls on our end.

 

We have managed to resolve the issue on most of our servers by disabling access to the WordPress administrator areas in order to prevent these bruteforce attacks to WordPress sites.

 

If you have a WordPress site and you wish to access your administrator area please navigate to your WordPress installation directory through FTP or cPanel File Manager and add these lines into your .htaccess file:

 

We felt it best to simply tell you a new username, rather than to force you to modify a file to grant yourself access - not everybody has a static IP and a large enough portion of our client base are not very technically inclined (i.e. asking them to do this would put a fairly large burden on them).

[Heather]

Doesn't seem like my admin account changed names, but I had a secondary login already so I'll just use that (kept 'admin' for now but it's no longer an administrative account). Thanks for the heads up. A shame that this kind of thing goes on.

[Michael D.]

Doesn't seem like my admin account changed names, but I had a secondary login already so I'll just use that (kept 'admin' for now but it's no longer an administrative account). Thanks for the heads up. A shame that this kind of thing goes on.

The change is in-progress on all servers, we wanted to give the heads-up prior to the change so people don't go from being able to log into not being able to log in without reason or explanation. Additionally due to the current time, we anticipate a large portion of our client base will not see the email message for several hours.

 

We plan on sending at least one additional message, in case the first is overlooked.

[Juan]

Thank you for the heads up Mike!

 

MDD hard at work as always, I've notified all of my clients.

[Vortexmind]

Thank for that, appreciated. Either way, I definitely suggest using Cloud flare to anyone not using it already

[SarisIsop]

Thanks for the info, that's what I like about MDD they keep you informed and offer good support especially to someone like me who doesn't understand the tech side.

 

Ref Cloud Flare: I have dial-up (yes I know, but I have no choice where I live) and cloud flare usually makes loading a site far to slow for me, I have also had the experience being rejected from one website. Like Mike said "not everybody has a static IP" so for me it would be useless.

 

I've started using "Limit Login Attempts" plugin and set it to 720 hours lockout which seems to bee helping. I have also added "Login Alert" which sends me an email as soon as anyone logs-in.

 

Mike I have one question out of curiosity. How did you manage to go through everyone's WP and change the Admin username ?

 

Thanks.

[billhector]

Before I totally lose it, let me ask this one question: why is this brute force attack a problem if the response to a failed WordPress login is noncommittal? The error response doesn't tell you whether the user name OR password was the problem. So, changing the user name gives an attack the same information as not changing the user name, thus it doesn't stop the attack.

 

Please explain.

[Scott]

I've started using "Limit Login Attempts" plugin and set it to 720 hours lockout which seems to bee helping. I have also added "Login Alert" which sends me an email as soon as anyone logs-in.

 

This kind of plugin may not be able to mitigate this type of attack. Because the attack is coming from such a huge number of IPs, it is very difficult for a single site to detect and block one of the malicious IPs. It may be possible for it to disable the username being attacked, but that would seem somewhat unusual and would interfere with your ability to access the site.

 

These kinds of plugins also tend to be very resource intensive and are regularly responsible for slowing down a clients website.

 

Before I totally lose it, let me ask this one question: why is this brute force attack a problem if the response to a failed WordPress login is noncommittal? The error response doesn't tell you whether the user name OR password was the problem. So, changing the user name gives an attack the same information as not changing the user name, thus it doesn't stop the attack.

 

Please explain.

 

The attack is attempting to brute force / guess the password for the admin user of any WordPress installation it can find. Since the admin username is the default in all new WP installs, many users make use of it or have not removed it from their site. Changing the username forces the attack to guess the username (which it isn't trying to do, to our knowledge) AND the password, which makes it much, much harder for your access details to be guessed when they do not already know a username that possibly works.

[billhector]

The attack is attempting to brute force / guess the password for the admin user of any WordPress installation it can find. Since the admin username is the default in all new WP installs, many users make use of it or have not removed it from their site. Changing the username forces the attack to guess the username (which it isn't trying to do, to our knowledge) AND the password, which makes it much, much harder for your access details to be guessed when they do not already know a username that possibly works.

 

Thank you. This is exactly my point. The attack will continue whether the user name is changed or not. It makes no difference. The attack probably makes x number of attempts, and since WP isn't returning any useful information, the attack continues until the x number has been reached or the login has been successful. So, changing the user names was a pointless exercise.

[Scott]

So, changing the user names was a pointless exercise.

This is absolutely incorrect.

 

Changing the usernames may not stop them from trying to guess a password, but it will go a long way in stopping them from actually logging in as an admin. The end goal of this attack isn't to guess a password, it is to get in, add malware, or otherwise compromise the account. If they get in, they could easily install a plugin that lets them take over your entire account to send spam, participate in a DDoS attack, access your files or databases, etc.

 

Changing the username absolutely will save many accounts from being compromised.

[billhector]

 

Changing the username absolutely will save many accounts from being compromised.

 

So, MDD changed every hosted WP site to protect the people that had a user name of 'admin' and a password of '123456', right?

 

You said it yourself, changing the user name in and of itself will not stop the attack. The password is the issue.

 

Sorry, I don't see how protecting nimrods from themselves is good for anyone. They've still got the password '123456'?!

 

Now that we've confirmed that in fact the password is the real issue, it makes me wonder why even the word "password" was missing for Mike's email. I have a reseller account. They email I sent to my clients quoted Mike, but I also went over password security and mentioned the great product LastPass.

 

Finally, this latest WordPress on MDD apocalypse has pretty much confirmed to me that Mike hates WordPress and would love for every last install to leave. He won't say that ever, but it's clear as rain. Too bad.

[Scott]

So, MDD changed every hosted WP site to protect the people that had a user name of 'admin' and a password of '123456', right?

 

No. Our change did not consider the password of any given user. Not only is this technologically impossible due to how WordPress protects passwords, it is unrelated to the problem in this case.

 

You said it yourself, changing the user name in and of itself will not stop the attack. The password is the issue.

 

Yes, they may continue trying to guess the password for the 'admin' user. But if this user no longer exists, likelyhood of an account being compromised in this attack is mitigated.

 

Sorry, I don't see how protecting nimrods from themselves is good for anyone. They've still got the password '123456'?!

 

Guessing the password is only half the battle when they have to guess the username too. Having a known username means they only have to guess the password. We've fixed this problem, at least for this specific attack.

 

It also does help everyone on our servers/network when other sites aren't compromised:

 

One site being compromised and being used to launch a DDoS attack could impact others on the server or network, and would certainly contribute to increased support/administrative costs for us.

Also consider if a compromised account sends spam, this harms the sending reputation for everyone.

This certainly wont fix every problem that exists, and weak passwords are a serious issue, but it will help to mitigate this specific attack, which is very dangerous due to the massive scale of the attack.

 

 

Now that we've confirmed that in fact the password is the real issue

 

I would not agree with this statement. With regard to this attack, the default 'admin' username is the main problem.

 

I have a reseller account. They email I sent to my clients quoted Mike, but I also went over password security and mentioned the great product LastPass.

 

Promoting good security is always a good idea, and we appreciate you helping your clients to use strong passwords. That said, we chose to keep the email notice simple. Many of our users aren't very technical and can easily get lost in too much detail. That's why we referred people to this forum topic, in the email, if they wanted more detail. If they can understand that they now log in with the username and not 'admin,' then that is enough. If your clients or market is different, you should certainly adjust the notifications you send to them and only quote us when you feel it is a good fit for your clients.

 

Finally, this latest WordPress on MDD apocalypse has pretty much confirmed to me that Mike hates WordPress and would love for every last install to leave. He won't say that ever, but it's clear as rain. Too bad.

 

WordPress is an interesting topic in terms of security. It's very easy to use, and has a great plugin/theme system. For these reasons, many love it, but as server administrators, it is also frustrating to see how many issues result from the (mis)use of the WordPress software. We have nothing against it specifically, but outdated installations, plugins, and themes probably account for 75% of the abuse issues we deal with on a day to day basis.

 

If you have any further thoughts on this topic, please open a support ticket so we can continue to discuss this privately. I would prefer to not derail this forum thread and risk confusing the issue for others who are just reviewing this issue.

[SarisIsop]

This kind of plugin may not be able to mitigate this type of attack. Because the attack is coming from such a huge number of IPs, it is very difficult for a single site to detect and block one of the malicious IPs. It may be possible for it to disable the username being attacked, but that would seem somewhat unusual and would interfere with your ability to access the site.

 

These kinds of plugins also tend to be very resource intensive and are regularly responsible for slowing down a clients website.

 

 

 

The attack is attempting to brute force / guess the password for the admin user of any WordPress installation it can find. Since the admin username is the default in all new WP installs, many users make use of it or have not removed it from their site. Changing the username forces the attack to guess the username (which it isn't trying to do, to our knowledge) AND the password, which makes it much, much harder for your access details to be guessed when they do not already know a username that possibly works.

 

Thanks Scott.

[Leah]

Some of my clients Cpanels were disabled and I am getting a login is invalid message.

 

3 clients had the default "admin" - 1 did not.

 

I cannot access all 4 Cpanels. I have verified that all the account usernames and passwords are correct. However, I can access 2 via FTP.

 

Anyhoo, I will be opening up tickets for all 4 but I wanted to give a heads up that maybe MDD should send a followup message for everyone to verify their Cpanel logins.

 

Thanks!

[Scott]

Some of my clients Cpanels were disabled and I am getting a login is invalid message.

 

3 clients had the default "admin" - 1 did not.

 

I cannot access all 4 Cpanels. I have verified that all the account usernames and passwords are correct. However, I can access 2 via FTP.

 

Anyhoo, I will be opening up tickets for all 4 but I wanted to give a heads up that maybe MDD should send a followup message for everyone to verify their Cpanel logins.

 

Thanks!

 

cPanel access was not modified or affected in any way by this change. We will assist you further in troubleshooting this in your support ticket.

[Scott]

Update regarding WordPress Network/MultiSite:

An issue has come to our attention regarding WordPress Network Installations (formerly WordPress MultiSite). If you were previously using the default 'admin' log in to access all of your WordPress network sites and can no longer access other sites in your WordPress network with the new username, please open a support ticket so can verify the issue and correct it for you. When opening the support ticket, please be sure to include the URL to access WordPress, and if possible, the WordPress database name.

 

Do not reply on our forums to request assistance with this issue. A support ticket is required to protect the privacy of your information.

[Leah]

cPanel access was not modified or affected in any way by this change. We will assist you further in troubleshooting this in your support ticket.

 

Pretty big coincedence - especially since I was in the backend of 2 within the past 48hrs & unless I was in a fugue state... I did not change the passwords.

 

 

Just thought I would give a heads up Have a great weekend.

[Michael D.]

Thank you. This is exactly my point. The attack will continue whether the user name is changed or not. It makes no difference. The attack probably makes x number of attempts, and since WP isn't returning any useful information, the attack continues until the x number has been reached or the login has been successful. So, changing the user names was a pointless exercise.

As indicated in our original post, we're not having issues keeping servers or accounts online [at this time] so our goal isn't to stop the attempts, but to simply help ensure that the attempts are not successful. In the event that the attacks cause server-wide issues we may need to take additional steps.

[Michael D.]

Pretty big coincedence - especially since I was in the backend of 2 within the past 48hrs & unless I was in a fugue state... I did not change the passwords.

 

 

Just thought I would give a heads up Have a great weekend.

Coincidence is coincidence, correlation does not imply causation.

[Lightpix]

@billh--I have been using WordPress for several years; love it. In the past few months, however, I have noticed a definite trend of hacker attempts against my account. At first, my ego was boosted because I noticed several of my accounts had hundreds or thousands of hits I could not explain. The increase was so dramatic that I was sure that my efforts at SEO, etc. were being rewarded. I was thrilled that people were paying attention to my work!

 

However, I began to carefully investigate the "hits." It soon became clear that the increased traffic had nothing to do with my accounts, and usually were of such short duration as to belie any interest in my web domains. After I installed WordFence I began to see that I was being systematically attacked by hackers trying to get access to my site. "Brute force" is exactly right, as the number of attempts was in the thousands, all to the UserId of "admin." I already knew not to use "admin" but I also made sure that my UserID was not the same as the name that might appear in any postings. On the domain that I allowed Wordfence to reveal that a userid was not valid, I noticed that the bots began plugging in alternate UserIDs: "administrator," "aaa," "user," "Admin," ... So it's not just the password.

 

I think that Mike's (and the administrator's) response was measured and intelligent. It is a known fact that one of the greatest vulnerabilities of WordPress is the use of the standard UserID: admin. [This is also true for joomla, which is also being subject to these "brute force" attacks.]

 

In fact, for the past 3 months I have systematically investigated every email I receive from a friend's email account, that has a suspicious link. In each case, a hacker has gained access by using "admin" as a UserID, always in a WordPress or Joomla web site, and has established a subdirectory in which they have placed a Trojan Horse. I have looked up the web site (usually legitimate) and contacted the web designer (usually listed at the bottom of the page) and let them know they have a Trojan Horse.

 

This activity is not a small operation. I suspect that this is a major, major (government-sponsored) operation (confirmed to me by the posting here) that could culminate in a major attack on the Internet, of which the recent record attack is just the beginning. I applaud MDDHosting's action, and it lets me know that they take this threat seriously, so much so that they want to prevent all of us from being affected by the negligence of a few.

 

To the folks at MDDHosting: Thank you!

[roadmon]

Very nice to get this update.

MDDHosting not only busy taking subscription fee (LOL) but also taking steps forward to secure their customer's website.

Bravo MDDHosting.

[Scott]

More information and advice regarding this attack from LastPass:

http://blog.lastpass.com/2013/04/wordpress-blogs-attacked-what-you-need.html

 

And the original CloudFlare article in case you missed it in our first post:

http://blog.cloudflare.com/patching-the-internet-fixing-the-wordpress-br

[T0M]

Mike, I am curious as to how you notify the clients of resellers. Do you notify accounts directly or notify the reseller account of the changed user names and passwords for the affected domains? Thanks.