Support » Fixing WordPress » Recent new xmlrpc.php brute force password-guessing attack details

  • 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. This is different from the usual spam or denial of service XMLRPC attacks.

    There’s [link moderated – keep support on this site] for anyone interested.

    As usual, the best cure for these is a strong password. But this may provide an extra boost to those who feel that xmlrpc.php should be completely disabled.

Viewing 15 replies - 1 through 15 (of 22 total)
  • Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    That’s not really a new method, rather an old method gaining popularity again. It’s really not that big of a deal, to be honest.

    XML-RPC still requires a username and password to post, so if you think that’s insecure, you might as well just stop using anything that only requires a username and password. 🙂

    If you’re concerned about security, here are a bunch of recommended things: http://codex.wordpress.org/Hardening_WordPress

    That’s not really a new method, rather an old method gaining popularity again

    I think there’s perhaps a misunderstanding. This botnet isn’t using it to try to post blog entries, comments, and so on, as I think you’re referring to (that is indeed something seen often before). The use of “wp.getUsersBlogs” seems new; I can find no references on the Internet to botnets using it before this month.

    Rather, they’re now using XML-RPC solely to test and stockpile valid passwords for later use (because their POSTs to xmlrpc.php have no other effect). It appears they’ve switched from wp-login.php username testing to xmlrpc.php testing, perhaps because so many hosting companies are blocking or rate-limiting wp-login.php attempts.

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    If a botnet can “test and stockpile valid passwords” from XML-RPC, you need a better password. In general, barring any new technology that shadowy entities have been hiding from us, a password of 15 random alphanumeric characters can take over a week for the strongest known technology to crack, not to mention that they’ll need the username too, which if you’re following all the recommendations (even present during install) is not “admin”.

    Yes, the time estimates have always been debatable, but you can see here that if the estimate on 15 random alphanumeric characters is even anywhere close to 1 week, you probably have a terrible password if “testing and stockpiling valid passwords” via XML-RPC is your primary security concern.

    Anyway, now it’s getting confusing since we apparently have the same conversation going in two threads now, so for anyone else tuning in: https://wordpress.org/support/topic/is-wordpress’s-xml-rpc-functionality-a-security-vulnerability

    Two small bits from the other thread:

    1. http://wordpress.org/plugins/login-security-solution/ will rate-limit both wp-login.php and XML-RPC.

    2. Stay secure with the official recommendations: http://codex.wordpress.org/Hardening_WordPress

    you probably have a terrible password if “testing and stockpiling valid passwords” via XML-RPC is your primary security concern

    I absolutely agree.

    My original post was more in the context of companies that host large numbers of WordPress blogs for “strangers” (and so was the other thread), where you end up being responsible for their site security but can’t control what passwords they choose or what plugins they run. In that case, the companies do have to consider XML-RPC rate limiting, etc.

    The moderated link above was intended to provide technical details of the attack XML contents for people who are responsible for other people’s blogs, so they can set up rules in mod_security, etc. to block it. I won’t repost any links, but you can search for “wp.getUsersBlogs attack” to find technical details from several prominent sites posting about this in the last couple of days. There just wasn’t any mention of the attack yet here in the support forums (the other thread got posted simultaneously).

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    Indeed, and thanks for bringing it up. 🙂

    JosephN

    (@josephn_fan)

    This attack is growing in popularity lately. A site I manage was attacked a few weeks ago (over the holiday weekend) and I could find little or no info about it via searching, at the time. Now, a few weeks later, and I get a lot of search results when checking up on it. (including this support page)

    That is by no means statistical evidence, but it is easy to grasp that people are talking about it more.

    @macmanx, I would like to note that your statement “not to mention that they’ll need the username too” is of little use because usernames are somewhat trivial to gather on even some of the largest and most well known WordPress sites. (I won’t point fingers, but I checked a couple and it was easy) You can simply scan the author pages/URLs and you should find the username of every author is either shown in the URL (author enumeration) or is shown in a class name inside the page itself. There is no more guessing at that point.

    I found that out when a site I manage suddenly had a bot attempting to access it by using a list of popular passwords in conjunction with all the usernames associated with the site.

    Now it is simply a matter of passwords, and for those of us who build and update sites for clients we can only advise them about their password choices and hope they listen.

    Strong passwords was the only thing that saved me, and I hope that doesn’t remain that case forever because hackers are getting smarter about guessing passwords.

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    I would like to note that your statement “not to mention that they’ll need the username too” is of little use because usernames are somewhat trivial to gather on even some of the largest and most well known WordPress sites.

    Oh, I know, but I doubt anyone will refine such a blunt instrument as an XML-RPC brute-force bot to scrape the site for usernames first. In 10 years of doing this, I’ve never seen that. It’s much more effective for the hackers to run common passwords against common usernames, and to move on when the list is exhausted.

    Simply put, use a strong password, don’t use a common username, and follow all of the recommendations: http://codex.wordpress.org/Hardening_WordPress

    JosephN

    (@josephn_fan)

    That is a good point. Using strong passwords is absolutely what saved me. But the more paranoid among us won’t be satisfied with that.

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    For sure, that’s why we have http://codex.wordpress.org/Hardening_WordPress 😉

    Oh, it is actually very common to scrape valid user names (and we are seeing it often).

    Good example: http://www.acunetix.com/blog/web-security-zone/wordpress-username-enumeration-using-http-fuzzer/

    We posted some details on this type of brute force here:
    http://blog.sucuri.net/2014/07/new-brute-force-attacks-exploiting-xmlrpc-in-wordpress.html

    But I agree with James, good web masters with good passwords do not have to worry about it. The issue is that many users have weak passwords and get easily compromised through it.

    thanks,

    JosephN

    (@josephn_fan)

    Another XML RPC brute force attack for me this weekend; on a different site this time.

    @daniel, username scraping certainly DOES happen, I have seen it. Luckily for now I haven’t seen anyone combine these two attacks. Although, if they did, a strong password would still be the best defense.

    I know my passwords are not easily guessed, but I worry about my clients, I don’t know how much they are listening to me when I tell them to pick strong passwords. I’m not sure scaring them by telling them someone tried to guess 20,000+ times this weekend is exactly the right move either (although it is true).

    We implemented some mod_sec rules to deal with this. Before we had them in place, we recorded 100 hits a second across our server on the XML RPC file.

    Fortunately, our server is pretty well resourced, but I can imagine that this new attack must have brought down quite a few sites because this kind of traffic will simply behave like a DDOS.

    So happy to see a new WP update today that will help to mitigate this issue.

    JosephN_FAN there are plenty of “force strong password” plugins available – although I am not sure why this is not part of the core WordPress code – perhaps it will be in a future version?

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    We implemented some mod_sec rules to deal with this.

    Would you mind sharing those with the community? 🙂

    there are plenty of “force strong password” plugins available – although I am not sure why this is not part of the core WordPress code – perhaps it will be in a future version?

    WordPress has a password strength indicator built in. Beyond that, the folks behind WordPress are generally not interested in forcing users to do anything. People should be free to make their own decisions, and consequently their own mistakes.

    The password strength indicator is there to encourage better passwords, but I highly doubt that WordPress will ever force a user into a password they don’t want.

    Actually if you look at trac, it seems there will be a password generator feature in 4.1 – which will be better than a rather useless “strength indicator”

    People should be free to make their own decisions, and consequently their own mistakes.

    Unfortunately for those of us who manage “humble and rather unaware” clients, this is not helpful. It’s a bit like saying just leave that old lady to cross the busy road on her own – surely you’d be happy to help just a bit – then both parties will be happy 🙂

Viewing 15 replies - 1 through 15 (of 22 total)
  • The topic ‘Recent new xmlrpc.php brute force password-guessing attack details’ is closed to new replies.