300,000 WordPress hacking attempts and 5 observations | Hacker News Reader

300,000 WordPress hacking attempts and 5 observations

simonfredsted.com

40 pointsfredsted45 comments

DO NOT automatically IP blacklist offenders. I ended up with a .htaccess list of 3,000 banned IPs which took my site down.

Use the highly loved, 5 star rated, 5+ million downloaded "iThemes Security Plugin" for Wordpress (formerly Better Wordpress Security). https://wordpress.org/plugins/better-wp-security/

● Use the "Change Admin" feature to change your admin username to anything other than "admin".

● Hide your backend so that "yoursite.com/wp-admin" doesn't even lead to the login screen

● Use "Away Mode" so the backend is completely disabled during certain days or times of day. (10pm - 8am overnight)

● Enable "Brute Force" protection for logins, after 3 bad password attempts the host should be locked out.

● DO NOT enable "Blacklist Offenders" feature. If you do, this will add the IP address of offenders to your .htaccess file and eventually take your site offline when the list reaches thousands of IPs. It doesn't scale and you can quickly reach thousands of IPs in just a few days depending on the popularity of your blog.

● Use "Immediately ban host who tries to log in as Admin"

Personally this is what I've found to work for me and my blog. Some days I get 220 hacking attempts and other days it dies down.

That is some really good advice for keeping security tight, I'm going to link this from my blog post if you don't mind.

Personally, since I basically use WordPress as a static HTML generator, I'm wondering if there is a solution out there that can just decouple the administration interface and put it on a while different domain, port, or server – I really like WordPress for managing my content.

> The top 1 IP address that have tried hacking my blog, 54.215.171.123, originates from a location you wouldn’t suspect: Amazon.

Really? That's basically exactly what I would expect.

Most of the attacks are performed from other, already infected sites.

I would expect Amazon to have some automated abuse controls; the rest of their infrastructure is pretty impressive.

What you're talking about requires deep packet inspection. I don't see why AWS would do that on a platform that has the potencial to generate an enormous amount of HTTP traffic.

The costs of operating something like this would have to be passed on to the client making them less competitive. No way AWS would do this.

Good point - I've not been involved in this kind of deep packet inspection required to do this – in my mind, all it would require is a filter on "wp-admin.php" and the resulting status code.

Automated? Not sure they can tell nefarious from normal traffic.

I would expect they would block the offender very quickly if notified though.

To my mind, that's a shocking number of attacks on a relatively small target. It makes me wonder what sort of numbers the really famous sites are seeing, and if they track the data in this way as well.

It's amazing that in nearly-2015, enough people still use passwords like '123456' and 'password' such that they're still at the top of the guessing list in hacking attempts. Some of us will never learn, I guess...

We used to have to take care of the wordpress sites of a few friends of the CEO. One of them, a middle-aged tech naif, had an admin login that was the same for the username, password, and domain (effectively www.johnsmith.com, johnsmith:johnsmith). I had to 'crack' it to log in to apply an update, as we didn't have a record of what he'd set it to...

For future reference, it'd be easier to just add a new administrative user to the database. I've had to do that a few times.

(Alternatively, you can just update the password hash for the existing user account.)

I changed the password and emailed him (Well, I emailed 3 times - twice for a polite 'can I change it' and once for 'I have changed it'). No response. 3 months later, the CEO comes along and says "John Smith can't get into his wordpress website, he thinks it's been hacked" :)

I run a wordpress site for a friend with the work "anonymous" in the domain name. I run WordFence on it with 30min lockouts for failed password attempts from the same IP address. I get ~60 locked out messages a day from it, the vast majority attempting to log in as "admin" (and account which doesn't exist). I have no doubt that it's _continuously_ under attack from several botnets, and that without Wordfence in the way it'd be dealing with thousands of login attempts per day.

Like this article closes with though, non "admin" accounts and strong passwords foil all these lame automated attempts. (I suspect one day it'll get attacked by someone with a Wordpress zeroday, and I'll have to reprovision the vm from scratch - Yay Ansible! - come at me scriptkiddies!)

I don't run a WordPress site, but it seems to me that failed password lockouts should be a standard feature. Even a lockout of say five minutes makes brute-forcing all but the most useless passwords implausible.

I looked up Wordfence. The way it preemptively blocks attacks from all domains that attack any Wordfence user's site is pretty clever.

> It makes me wonder what sort of numbers the really famous sites are seeing

Not exactly a famous site, but I thought a larger sample size might be interesting...

We [1] provides shared hosting for about 500 WordPress installations, of widely varying sizes. The sites are mostly static "blogs" for student groups or individual students, with about half on a single domain (www.ocf.berkeley.edu/~something) and others on different subdomains of berkeley.edu.

In the past week, the webserver handled 3,527,157 requests (about 814 MB of uncompressed access logs). 111,409 of those were WordPress login attempts [2].

I was going to compare the list of top IPs with the list in the article, but was surprised to find that there were no shared IPs between the lists. For context, we had 435 unique IPs, 9 with > 1000 requests, and 32 with > 100 requests.

The top ten requestors in the past week are from (cities from whois data):

    56742 Kiev, Ukraine
    19302 Novosibirsk, Russia
     7645 Sofia, Bulgaria
     7641 Moscow, Russia
     7190 Kiev, Ukraine
     6748 Kharkov, Ukraine
     2160 Roubaix, France
     1041 Kharkov, Ukraine
      967 Kuala Lumpur, Malaysia
      894 Putian, China

[1] https://www.ocf.berkeley.edu/

[2] POST requests to wp-login.php. I don't have accurate numbers on how many failed, but to say that less than 250 were legitimate user logins is probably accurate.

A small point here: Roubaix is the town where OVH has its datacenter and exchange point, so this is most probably people renting VMs or VPS in there (like Amazon).

Ah, so that's why Roubaix, France always shows up on my list of hacking sources! Thanks for the explanation.

How can Kiev be #1 and #5? Similarly Kharkov.

Sorry, I should have clarified. That list is the top 10 IPs by number of requests, not the top 10 cities. I just replaced the actual IPs with the cities in their whois (since I'm not sure I want to post the IPs publicly).

AH, of course; thanks.

2 diferent IP's from the same city? I get what you mean, but it's easy to understand also.

.edu domains are still popular targets in Western Europe, and access to webservers in .gov and .edu TLDs is the most priced there.

The cause for this is the belief that Google gives more weight to content and backlinks from these TLDs.

That IP address should be reported to Amazon so they can either cut off the owner from AWS or inform them someone has cracked their system.

*Edit: here: http://portal.aws.amazon.com/gp/aws/html-forms-controller/co...

I use the following in my nginx configuration (inside the "server" block) to restrict access to the WordPress login page from two IP addresses (one is my static IP at home and the other is the IP address of a VPN endpoint):

  location = /wp-login.php {
    allow x.x.x.x/32;
    allow y.y.y.y/32;
    deny all;
  }

Was just about to recommend this. Supporting Wordpress everyday, I find this is the best way to combat the problem. Another option would be to add an additional password for the directory. For you apache guys,

  AuthType Basic
  AuthName "Authentication Required"
  AuthUserFile "/etc/htpasswd/.htpasswd"
  Require valid-user

This is the approach I used to take also, before moving my site to Jekyll. You could also use fail2ban to prevent hammering of that URL.

Good tip. The other two changes I recommend are:

1. Disable PHP execution in the uploads directory (hmm, wonder if it'd work if I disabled it in the entire wp-content folder?).

2. Run PHP as a different user to the file owner.

Both of these are to minimise damage when an extension is exploited by a hacker (if it hasn't happened to you yet, it will do) and to reduce the damage done to the server/site.

A bit of a pain if you need access from a mobile device. However, I guess it shouldn't be too hard to set up a secret page on a custom URL http://example.com/0f53c140-76da-11e4-9b73-0800279cfd99 that would temporarily add the requesting IP to the white-list.

Or set up a VPN to your home address, probably safer than trying to log in via a possibly unsecured channel (most WP installations don't have HTTPS enabled, or maybe that's just mine)

There's a Wordpress plugin that I used to use.

It sets up a hidden Wordpress admin page on the following URL:

http://www.youramazingblog.co.uk/wp-admin/?key=value

So you need to enter a key/value of your choosing in the URL before you can access the admin page.

Works pretty well especially if paired up with a decent key/value.

Interesting addition to the plugin: check admin login credentials with the passwords on the list. If found, notify the admin and disable his account until he resets the password to something better.

Of course, you would have to accumulate the list across many computers and distribute it to WP servers... And be careful NOT to include misspelled passwords (invalid login followed by a valid login). :)

I am also not sure "top X passwords" list would be enough - you should probably check against the whole list, which could be huge.

When you set up a new WordPress site, or you can do this for an existing site as well, create a new user and give this new user the Administrator role. Then log out and log in as the new admin user. Now, don't delete the original "admin" user but instead change the password to something super strong and give the user no role. This way, bots will think that the admin user exists and will try to brute force the super strong password you gave it, which obviously will be futile.

Unfortunately this is of limited helpfulness.

At my job (small web host), many of the WordPress brute force attacks we see across our shared hosting fleet use the '?author=\d+' trick in WordPress to find the usernames of admin-like users before starting the actual attack.

Totally idiotic of WordPress to reveal usernames this way.

We have moderate success in slowing/blocking these attacks using a WAF such as mod_security (after a certain number of HTTP 200 responses on wp-login, aka login failed, block the IP).

On the bright side, our load averages went down a non-trivial amount once we introduced these rules (a few customers would get effectively and inadvertently DoS'd by these brute forces LOL)

Hmm. The your ?author=\d+ trick doesn't seem to do anything on any of my WordPress websites, just get a 404.

the \d+ is regular expression that means, use: ?author=1 ?author=2 ?author=3 ?author=4 ...

Right.

e.g. http://en.blog.wordpress.com/?author=1 http://en.blog.wordpress.com/?author=2

Pointless information disclosure

I usually change the 'admin' username to something different, so the dumb bots that try to bruteforce their way in would give up altogether.

I'm not sure about WordPress revealing whether it's the username or password that's incorrect though. It's a compromise between security and UX that should be left to the admin (of course, there are plugins to remedy this).

I'm not sure how effective this is, but I've recently started settin up wordpress in it's own directory. It's a simple procedure, which defends against fishing for example.com/wp-admin hits. All my WP sites are in example.com/example/wp-admin.

Regular users never see the example/ directory.

Adding Two-Factor Authentication to the login doesn't stop the hacking attempts but ensures they will fail.

Just in case someone wants to check "their own" wordpress deployments, there is a free, friendly wordpress security scanner here: https://suite.websecurify.com/market/wpscanner

I use Login Security Solution plugin and IQ geo block plugin. I block all users from problem countries like China, Russia and Ukraine (to name but a few). I whitelist my own country and IPs to access the backend. Has worked well for me so far. I also use Cloudflare.

Could you also just alter the login page irk? I.e. Are the boys all directly targeting /wp-admin - if so could you change the url to /secret - and then they won't even be able to attempt to login in the first place?

Yeah that should be possible. In addition to that, change the default username to something nonstandard, and if you have SSH run it on a non-standard / random port too.

OP does this plugin also monitor brute forcers that attempts that try to pass credentials through POST strings? I see this shit often... annoying..

It works by using the WordPress login hook, and that uses POST, so I'd say so.

Reply on news.ycombinator.com