Limiting what attackers can do via xmlrpc.php
-
I have had strong server-based protection on wp-login.php for ages. Any IP address failing to get the username/password right in a couple of attempts is banned for a significant time.
Users have moaned about this, but I have always gone ‘Tough, it’s kept all the sites secure.’
Last month, it didn’t.
That’s because some bot used xmlrpc.php to find all users* and then hammered it with hundreds of username / password combos per request until they found one that worked.
And used it.**
Doing some searches here, I can see some staggering complacency about the xmlrpc ‘feature’, despite it featuring in several security holes in the past decade. (Literally: see the release notes for 1.5.1.3 back in June 2005.)
So when someone reported a year ago that “Our hosting company has recently seen a new kind of attack on the WordPress xmlrpc.php file: a password guessing attack that uses the wp.getUsersBlogs feature” the response from a moderator was “It’s really not that big of a deal, to be honest.”
Well, it is.
At the moment, users have a choice between blocking access to xmlrpc.php or being vulnerable. The simplest ways of blocking it stop the WordPress apps and much of JetPack from working. You can get around the latter (there’s an interesting plugin that looks for Automattic’s IP addressess and whitelists those.. if it’s on Apache 2.2) but not the former if you want to use them at random locations away from home.
On a server level, you can slow down accesses to the file, but a) a huge proportion of the userbase does not have the ability to do that, and b) the ‘La la la, it’s not a problem’ attitude doesn’t inspire those of us who can to do it until – in my case – it’s too late.
What should amaze me (but sadly doesn’t: there’s a long track record of prioritizing convenience over ‘out of the box’ security) is that looking at make.ww.wp.xz.cn, I can’t spot any efforts to stop this.
Even something as simple as limiting the number of username / password attempts in a single request would be good.
Have I missed something or is this attack going to be allowed to continue in the same way that there is still no limit on how many times someone can access wp-login before the core code slows or blocks them?
.
* I have also not had users called ‘admin’ for years – as soon as WP allowed you to pick the name of the first admin account, and long before it stopped stupidly suggesting it as a good name.
But the effect of that change has been that instead of going after ‘admin’, bots do this.
** I don’t post with admin accounts, so the names have not been visible to site visitors, but xmlrpc allows anyone to get them and it’s a pretty good guess that the first user has admin rights.
The topic ‘Limiting what attackers can do via xmlrpc.php’ is closed to new replies.