Brute Force Attacks On WordPress Underway

[vangogh]

If you run a WordPress site and haven't yet heard, there's a brute force attack being coordinated against WordPress sites the last few days. I was alerted to it sometime last week by my web host who started putting things in place to help prevent the attack, but could potentially slow down the server at times. A client of mine received a similar email from a different web host.

The gist of what's happening is a bot net is attempting to login to any WordPress site it finds. The attack is using the knowledge that the default admin username on WordPress sites is admin. It's then using brute force to try as many passwords as possible.

If you run a WordPress site there are a couple of things you should do at a minimum.

1. Change or remove any accounts on your site with the username admin. If admin is your only admin account you'll want to create a new admin account with a different username first.

2. Make sure your passwords are secure. Then make sure they're even more secure than that.

Here are a few links to information about what's going on and a couple of methods for how to change the admin username

Brute Force Attacks Build WordPress Botnet (http://krebsonsecurity.com/2013/04/brute-force-attacks-build-wordpress-botnet/)
WordPress and spam: How to protect yourself (http://blog.lynda.com/2013/04/15/wordpress-under-attack-how-to-protect-yourself/)
How to Change Your Admin User Name in WordPress (http://www.irishwonder.com/blog/2013/04/15/how-to-change-your-admin-user-name-in-wordpress/)

You might also want to search for security plugins (wordpress.org/extend/plugins/search.php?q=security). I usually hear good things about Better WP Security (http://wordpress.org/extend/plugins/better-wp-security/)

Lockdown those WP sites.

[WebEminence]

Thanks for the warning Vangogh.

I was doing some reading about this last week. I was looking at the security plugins and did also hear good things about Better WP Security.

I ended up installing WordFence mainly for it's limit login feature which limits the number of unsuccessful login attempts and locks out a user. This may help prevent or discourage the attempts at login that may cause server issues. It's important to realize that it's not just the successful break-in that is problem but also the DOS effect when a bot tries to login millions of times.

I think most of these security plugins have a limit login feature.

[vangogh]

I forget which plugin I added, but I did include a limit login type of feature. The most immediate thing people should do is get rid of the admin username and make sure they're using strong passwords.

Some of the plugins do things like change the default URLs for some common WordPress pages like the login page. That way automated attackers won't find it easily or at all. Automattic offers a full security solution with Vault Press (http://vaultpress.com/). It's subscription based so will cost something. At the low end they backup your site and can restore it should something go wrong. On the high end they security scanning.

[patrickprecisione]

Very helpful! Thanks for the heads up, VanGogh.

[vangogh]

I haven't seen as much news about the attacks the last week or so. They might have slowed down. Still it's always a good idea to be conscious of security.

[Harold Mansfield]

Funny thing happened to me last week that made me think of this thread.

I woke up one morning and had like 40 email alerts that some a**hole in the Ukraine from the same IP address found my log in screen, and was intent in guessing my password.
At first I banned the IP address, and he just came back with another one.
Then I banned any IP after 3 attempts, but he just kept coming.

So finally I banned any IP address after one bad attempt and that stopped him. And I just left it like that.

Couple of days ago, I was staging my log in screen to take some screen captures and accidentally hit the "Enter" button, which of course didn't let me in.
But then when I wanted to log in, I couldn't and got a white screen with an error message that I don't normally ever see. I kept trying to log in and I kept getting the white screen of death.

I was freaked out for about 10 minutes, before I realized that I still had it set to ban every bad attempt and had inadvertently locked myself out of my own site.

But man, I was pretty happy when I finally figured it out.

[billbenson]

Funny, they never attack my oscommerce version 1.0 :)

[Harold Mansfield]

Funny, they never attack my oscommerce version 1.0 :)

Here's my Archie Bunker "Whoop-dee-doo" face :rolleyes:.

Hope you knocked on wood.

[patrickprecisione]

Does this affect Wordpress.org, .com or both?

[Harold Mansfield]

Does this affect Wordpress.org, .com or both?

Self Hosted (.org). WordPress takes care of security for WordPress.com. But common sense precautions are always a good idea.

[vangogh]

Funny Harold about locking yourself out of your site. I'm not afraid to admit I've done the same thing. In fact early on here I was blocking an IP address through the admin side of the forum, but I had accidentally copied my own IP address and so I blocked myself. I was going to dig through the database and fix things, but instead I just restarted my modem and had it assign me a new IP.

With the guy trying to break into your site, did you try blocking the entire C-Block of IPs?

[Harold Mansfield]

Funny Harold about locking yourself out of your site. I'm not afraid to admit I've done the same thing. In fact early on here I was blocking an IP address through the admin side of the forum, but I had accidentally copied my own IP address and so I blocked myself. I was going to dig through the database and fix things, but instead I just restarted my modem and had it assign me a new IP.

With the guy trying to break into your site, did you try blocking the entire C-Block of IPs?

No, I didn't feel the need to do that. Besides, he started bouncing around probably with proxies. Some coming from Israel, Turkey, Georgia, and then San Francisco.
Although I could probably block Russia, Afghanistan, Pakistan, India (maybe), Sri Lanka, Tajikistan, and The Ukraine completely and not miss one lick of legitimate traffic.

[Brian Altenhofel]

A lot of those proxies (like known Tor exit nodes) end up on RBLs really fast. I've got one site that somehow got targeted for spam (services like Mollom and Recaptcha caught 99+% of it, but still had 40+ comments/emails get through per day... on a site that has a normal traffic rate of only 1,500/mo). Finally ended up taking the super-aggressive approach and making the server invisible to any IP that has a certain score or higher. And yes, the client was made aware of the potential side effects of such an aggressive approach.

[Harold Mansfield]

I had to learn the hard way how malicious it can be on the web. It's amazing to watch someone from the other side of the world target your site for hours. Trying over and over to basically guess your password or find a way in. Or to backtrack a relentless comment spammer to the country they're sending from.

People that try and tell me that they use a particular kind of publishing software, or coding and therefore no one ever tries to gain access to their site aren't exactly being 100%. There is no publishing software that is going to scare a hacker in Russia, or be something that he's never seen before so he gives you a pass.

Small time hackers, spammers, and people looking for places to do malicious installs are all over the internet by the thousands and they try every site they see...like a robber that turns every door knob he walks past. Everyday. All day long. It's non stop. Malicious bots roam the web freely looking for weak spots like pigeons in a park full of statues.

Depending on what security software you have installed, you may not SEE every attempt, but it's happening. If it's not your site specifically, it's the server that your site is hosted on which they're targeting through one of the hundreds of other sites on that same server.

I've talked to my host and other hosts for years that tell me that it's constant. Sure, most hosts block or thwart 99% of the Amateur stuff so that you, the site owner, never see any of it...but to have a live website on the World Wide Web and think that no one, or nothing has ever tried to gain access to your website is living in fantasy land. It's the World Wide Web. That's what they do. And much of it is automated.

Now, if your site is not known by anyone, hosted all alone on a dedicated server, uses no 3rd party scripts, not linked to from anywhere, and gets no traffic...then maybe you've managed to get lucky up until now. But it's luck. It's not the Joomla Gods protecting your site with a magical invisible shield that keeps all attempts at bay.

If they see you, they will try you. They may move on because it's not easy, but don't walk around thinking that you are immune or one day you'll be like those people on TV that always get on the news after something bad happens with, "This is such a safe neighborhood. We never thought something like this could ever happen here.".

[MyITGuy]

You know, people that try and tell me that they use a particular kind of publishing software, or coding and therefore no one ever tries to gain access to their site aren't exactly being 100%. There is no publishing software that is going to scare a hacker in Russia, or be something that he's never seen before so he gives you a pass.

Small time hackers, spammers, and people looking for places to do malicious installs are all over the internet by the thousands and they try every site they see...like a robber that turns every door knob he walks past. Everyday. All day long. It's non stop. Malicious bots roam the web freely looking for weak spots like pigeons in a park full of statues.

Depending on what security software you have installed, you may not SEE every attempt, but it's happening. If it's not your site specifically, it's the server that your site is hosted on which they're targeting through one of the hundreds of other sites on that same server.

I've talked to my host and other hosts for years that tell me that it's constant. Sure, most hosts block or thwart 99% of the Amateur stuff so that you, the site owner, never see any of it...but to have a live website on the World Wide Web and think that no one, or nothing has ever tried to gain access to your website is living in fantasy land. It's the World Wide Web. That's what they do. And much of it is automated.

Now, if your site is not known by anyone, hosted all alone on a dedicated server, uses no 3rd party scripts, not linked to from anywhere, and gets no traffic...then maybe you've managed to get lucky up until now. But it's luck. It's not the Joomla Gods protecting your site with a magical invisible shield that keeps all attempts at bay.

If they see you, they will try you. They may move on because it's not easy, but don't walk around thinking that you are immune or one day you'll be like those people on TV that always get on the news after something bad happens with, "This is such a safe neighborhood. We never thought something like this could ever happen here.".

Agree with this! Even if your site has no links and is not found anywhere on the web, people run port scans across IP Blocks all day long and they will find you eventually.

My web servers see thousands of port scans (I'm looking at 1,189 alerts from the past 12 hours alone) and people trying to guess passwords to random accounts on a daily basis, and I have my servers set to block IP addresses after 3 failed login attempts or a certain # of ports being scanned in a certain timeframe. I'm just a small time hoster so that hopefully gives people a sense on the volume that we see.

[Harold Mansfield]

Agree with this! Even if your site has no links and is not found anywhere on the web, people run port scans across IP Blocks all day long and they will find you eventually.

My web servers see thousands of port scans (I'm looking at 1,189 alerts from the past 12 hours alone) and people trying to guess passwords to random accounts on a daily basis, and I have my servers set to block IP addresses after 3 failed login attempts or a certain # of ports being scanned in a certain timeframe. I'm just a small time hoster so that hopefully gives people a sense on the volume that we see.

So happy to hear someone in the industry and who deals with this stuff all of the time, confirm. I've been trying to tell people I know this for years, but since they don't see it, they think I'm just being paranoid and their website is the fortress of solitude.

I have a lot of respect for a good host. Sure, we all just worry about our sites, but the crap that a real hosting company deals with hourly 24/7 to keep our sites secure is amazing. The web can be a nasty place. You guys pretty much keep it away from us so that all we see is Ponies, and Stickers, and My Space, and sparkly things.

[patrickprecisione]

Self Hosted (.org). WordPress takes care of security for WordPress.com. But common sense precautions are always a good idea.

Thanks, Harold. Org seems to be more likely to have trouble since it allows javascript (I think, don't quote me on that). But yes of course, always better safe than sorry.

[Harold Mansfield]

Thanks, Harold. Org seems to be more likely to have trouble since it allows javascript (I think, don't quote me on that). But yes of course, always better safe than sorry.

No, it's not that it's more trouble. It's just more responsibility. You are in control of your own website, so you have to act like an administrator. It's not the Javascript.
The problem with allowing people to use Js on WordPress.com is that people can be malicious and Js is how a lot of Ad programs and install scripts run.

WordPress.com's decision to not allow Js is not about the code language itself. A few of the themes that they make available have Js in them, as well as the software itself and some of the plug ins...all have Js in them. And since WP.Com doesn't allow ads or allow you to run your own scripts, they block it.

It's about what people can do with it when they can add their own. And when you are hosting millions of blogs and websites for free, you have to be careful what you allow people to do on your network.

When you host your own site, it's your site. You can do what you want. Js is everywhere. It's nothing to be scared of like it's an old pork chop back in the 1800's before refrigeration. Just be careful as with anything else.

[Brian Altenhofel]

Yep, we see thousands of port scans and brute force attempts on our edge servers. We have various tools in place for monitoring and response at each tier, both for security and performance. Right now, I collect 45-50GB of logs per day that are analyzed, indexed, and stored. My office has a 24" monitor that is dedicated to showing reporting from everything we have running for monitoring.

Important things like your website's database and files should not be allowed to reside on an Internet-facing server. Very, very few reasons for an Internet-facing server to have more than :80 and :443 accepting connections.

And if your servers are remote, they should only be able to be accessed over a VPN or a very limited shell (as in "if you're not on the VPN, you can only do these certain things").

[vangogh]

I think it's a good reason why someone always needs to be paying attention to your website. I work on my sites all the time, whether it's just posting here like I am now or making a quick change to my design site. Both sites are set up to send me email for certain things and I check on their stats and see who's commenting etc. By paying attention everyday it helps me recognize something out of the ordinary, which when it happens gets me to look around more for why something unordinary is going on.

It doesn't always lead me to a security issue and I'm sure I wouldn't recognize every potential security threat as one of those unordinary things, but I think keeping an eye on the usual helps alert me to some potential danger.

[Harold Mansfield]

Last year I got like 3 phone calls in the same month from people who's website were getting redirected FROM the Google serps. You could see the site in the search results, but when you clicked the link, it took you to a Chinese knock off pharmaceutical site (which they presented as a Canadian site. It was even on a .ca).

It was the damndest thing. After about an hour with the first one, I decided to check the theme files since you never know where people get themes from.
Finally found a small piece of js code in the sidebar.php file. Just sitting there. Completely out of place. From a dirty, rotten, "die all you spammers and hackers" stand point, it was pretty simple and pretty ingenious.

I removed it and all was well again.

I don't want to disparage the host because it probably wasn't their fault. But all 3 people were on the same host. None of them had a security plug in installed, or their log in screens redirected, and they all used the default username. And with that, the hackers installed the script. Probably from the administration editor. It's just that easy. For ANY website, if you don't take basic security precautions.

Follow up. Recently the DOJ, Interpol and some other international agencies shut down about 100 of those pharm sites on the same day, and that one was on the list.

[Brian Altenhofel]

That's one of the reasons that I don't use shared hosts. Too many issues with privilege escalation or bypass that results in every site on that same server being compromised even if there wasn't a flaw in the site itself. It's also why all of my clients' sites are on separate cloud servers. If one does get compromised, whether directly or via a script on their site, the others aren't affected.

That's also a reason that, in most jurisdictions, government agencies or entities receiving government funding are not allowed to use shared hosting.

[MyITGuy]

That's one of the reasons that I don't use shared hosts. Too many issues with privilege escalation or bypass that results in every site on that same server being compromised even if there wasn't a flaw in the site itself.

As long as the host is security conscious, implements the correct features/functionality and monitors things...there shouldn't be an issue. Unfortunately, this is not the case with allot of hosts....they try to maximize the number of clients they can have on a single server with the least amount of issues/support calls...which results in old/outdated software and lax security.

And honestly, if I were in your position I would likely prefer a shared server, or semi-dedicated. If you have more than a dozen clients, then keeping everything up to date and secure is a full time job in itself. I.E. How long did it take for you to patch your clients servers against the recent CentOS zero day exploit (Assuming your using CentOS or a Redhat derivative)?

[Brian Altenhofel]

And honestly, if I were in your position I would likely prefer a shared server, or semi-dedicated. If you have more than a dozen clients, then keeping everything up to date and secure is a full time job in itself. I.E. How long did it take for you to patch your clients servers against the recent CentOS zero day exploit (Assuming your using CentOS or a Redhat derivative)?

Don't run CentOS/RedHat (except for Zenoss because *It just works*). I'm a Debian guy.

But it doesn't take long at all. Anytime I push an update to my Puppet configs, Jenkins deploys ~15 cloud servers (bare minimum for my deployment - includes file server cluster, MySQL cluster, Elasticsearch cluster, Logstash, monitoring tools, message queues, web app-only servers, and Internet-facing servers), applies updated Puppet configs, and runs a series of tests both on how the servers perform and react to failure scenarios as well as with a Drupal site with several common modules, and then kills the servers. If everything passes, then I know I can push into production. Jenkins tells each server to do a git pull on the repo and then applies the new configuration (and performs a reboot if necessary due to a kernel upgrade) in the proper order. The thorough tests take a few hours to run - final application across my current deployment is ~10 minutes +/-.

Jenkins even handle upgrading and testing Drupal modules and deploys those changes into production if they pass all tests. On the more complex sites I do, I have the client verify the cloned and updated version works before putting the change in production, but on the more simple sites I just let it go ahead and deploy on it's own.

Jenkins is the best investment I've made in my business. When I first started running it, I had several other freelancers tell me they couldn't justify spending $80+/mo for something like that. My first week running it, it freed me up for 4 more billable hours. I'd say it's somewhere in the neighborhood of 15-20 hours per week now.

Because of automation tools like Jenkins and configuration management tools like Puppet, the industry standard sysadmin:server ratio has increased from 1:10 to 1:100 (or more depending on how homogeneous your deployment is).

I believe in automating everything as much as possible, and Jenkins helps me do that. Applying a config update to 30+ servers is as simple as "git push".

And of course, I believe in thorough testing - that's why I take the extra time upfront to write tests in most cases on custom dev work. Even if all tests technically pass, it's not a "pass" unless there was also 100% code coverage.

[vangogh]

Not every attack enters through the host or site. One I've had to clear from a number of sites would infect your desktop or laptop and from there it would gran FTP credentials assuming you used FTP to access a server at all. The attack would then install itself in the form of .js code all over Wordpress on every site you stored login information for.

It was a nasty thing. You could clear out most of it, but if you missed even one file it would be back in full in a few days. In addition to adding .js code it created new files that looked like they belonged, but didn't. I remember it would add an index.php file inside every images folder. The easiest way to clean it out was to save your theme and delete everything else. Then reinstall WordPress and any plugins. You'd have to clean out the theme or ideally have a clean backup of it, which wasn't usually the case. On the bright side the database stayed clean so once the files were replaced and you changed every username and password across the site and hosting account you were back in business.

More common though is people not upgrading WordPress of plugins and something getting in through an old exploit. WordPress and/or the plugins had usually fixed the issue long before, but not everyone upgrades.

[billbenson]

Does anyone know of a program or script that will alert you to new files or recently altered files on your site?

[vangogh]

Automattic created VaultPress (http://vaultpress.com/). It's a plugin that's part of a monthly service with 3 plans. The lite plan $5/month backs up your site daily and can restore it from a backup if something happens. On the other end, the premium plan scans your site daily and alerts you to security threats and suspicious code.

There are probably scripts that do alert you to changes, but those might have issues of their own. For example if you or someone is legitimately working on the site you're going to get a lot of alerts. Similarly when you update WP or any plugins you'll probably be getting alerts too.

[Harold Mansfield]

There's also Better WP Security. It has a ton of security features, and you can also set it to alert you of any file changes or bad attempts to gain access.
WordPress › Better WP Security « WordPress Plugins (http://wordpress.org/plugins/better-wp-security/)

[MyITGuy]

Does anyone know of a program or script that will alert you to new files or recently altered files on your site?

You have some programming experience, so I'm sure you can create something similar to the following:

Step 1 - Get a listing of files in your home directory and load them into an array
Step 2 - Look through your array get the MD5 SUM of the file being evaluated
Step 3 - Compare the MD5 SUM of the current file to the previous value if one is present (I.E. 2 Variables in an SQL Table, File Path/Name & MD5 Sum....or just a text file with .MD5 as the suffix that contains the value).
Step 4 - If the MD5 Value is not present - Send an alert and store the new value
Step 5 - If the MD5 Value has changed - send an alert and store the new value.

I setup something similar to monitor a website that was getting hijacked and it worked pretty well. I did it from the client side though, the process above should be server based to catch everything.

[billbenson]

@Steve - Are those only wordpress options? Remember, I have a lot of my own scripts as well as the wordpress scripts.

@Jeff, how long does it take to run? It's a pretty big site.

If the MD5 value is not set, I'm assuming that's a file that is a possible hack if I'm not working on the site.

[vangogh]

VaultPress is a WordPress only solution. Your own scripts are custom so I think you'll need to create something custom for them or find a script that does something on the generic side. Keep in mind the more generic something is, the more likely it will have false positives.

Jeff's idea above should work, but again keep in mind that any time someone legitimately changes a file you're going to get an alert. Maybe you'd want to limit how often the script runs or have a way to turn it off when you know work is being done. Or better have it selectively check files so if you know your theme is being worked on you can ignore alerts on those changes (though you'd still want to store the changes for a latter comparison).

[Brian Altenhofel]

You could have everything under version control and have a script that checks for changes and sends a notification (as well as checks back out the known good code). Fairly trivial - just use Git, a cron job, and a shell script. Bonus points for using Jenkins and Fabric.py.

You could also put everything under a configuration management tool like Chef or Puppet and have the deployment to servers take place every few minutes. Difficult, but worth it if your application is spread across multiple servers.

[billbenson]

VaultPress is a WordPress only solution. Your own scripts are custom so I think you'll need to create something custom for them or find a script that does something on the generic side. Keep in mind the more generic something is, the more likely it will have false positives.

Jeff's idea above should work, but again keep in mind that any time someone legitimately changes a file you're going to get an alert. Maybe you'd want to limit how often the script runs or have a way to turn it off when you know work is being done. Or better have it selectively check files so if you know your theme is being worked on you can ignore alerts on those changes (though you'd still want to store the changes for a latter comparison).

It's sounding like jeffs solution is the best and not that hard to do. The only issue I would have is if my partner uploads an image to an image directory (I know shopp stores images in a db). I haven't done a script for that yet, but I want him to be able to upload images. That way we can both upload the most current / best images.

Oh, and and another thing. This should be transportable to any platform. That wouldn't be true of a WP plugin.

[MyITGuy]

@Jeff, how long does it take to run? It's a pretty big site.

If the MD5 value is not set, I'm assuming that's a file that is a possible hack if I'm not working on the site.

It shouldn't take too long for the script to run....but I'll see if I cant create a simple task this weekend and do some testing.

Yes, if an MD5 value is not set then that would be some cause for concern (As long as your ignoring temp files).

[billbenson]

It shouldn't take too long for the script to run....but I'll see if I cant create a simple task this weekend and do some testing.

Yes, if an MD5 value is not set then that would be some cause for concern (As long as your ignoring temp files).

Thanks, I appreciate it.

[vangogh]

You could have everything under version control and have a script that checks for changes and sends a notification

That's a good idea and has plenty of advantages beyond just being alerted to changes. I'm still slowly wrapping my head around version control. I get what it is and why use it. I have Git set up locally and a GitHub account. It's more incorporating it into my workflow that's taking time. Little by little though I'm moving in that direction.

[Harold Mansfield]

Woke up this morning to 400 email alerts that someone tried to gain access to one of my sites overnight between 12-2 am.

I saw a few attempts yesterday afternoon that seemed to be coming from the same person, so I had already moved my log in page and set unauthorized lock outs to 1 attempt before banning the host completely yesterday. Host said that really helped and it worked just as it was supposed to.

Host also said the same happened on a few other sites on my server and I had him install extra security across my entire server for any attempted access.

I can't say it enough, if you are running WordPress move your log in page, and monitor attempts to access your site. All it takes is a little extra security to save you a big headache down the line.

The security vulnerability is that everyone knows where the default log in page is, and that the default username is "Admin". So that's what they try to hit and brute force thier way in.
If you move that page to an obscure URL that only you know, and use a different username the BS hackers are lost and tend to move on.

[vangogh]

Glad nothing happened to your site. It seems like you're doing a good job locking it down. Oddly enough I read a post earlier with some tips for blocking attempts to brute force author page scans (http://www.wpbeginner.com/wp-tutorials/how-to-discourage-brute-force-by-blocking-author-scans-in-wordpress/). Two plugins and a bit of .htaccess. The plugins are Limit Login Attempt, which you wouldn't need since you have it set up and Google Authenticator to set up 2 step verification. The .htaccess code blogs robots from author pages, but you should be able to tweak it so they can't access any page.