xmlrpc.php revert back pre 3.5

  • diabolico

    (@diabolico)


    11 years ago

    Before 3 days i decided to test new security for WP with addon “WP fail2ban” so i can take advantage of f2b and prevent bruteforce attacks. I set 2 WP sites on my VPS (fresh install) and once done with everything i notice the huge amount of failed logins as f2b start to ban all those IP’s. So i went to the next step and use htaccess and try to block the bots to directly hit login page. And here is where all the “fun” start.

    Even with htaccess blocking login page there was decent amount of bots trying to bruteforce login detals. As i didnt know for the WP changes first thing i suspect that something is wrong with my Apache. So i start to dig into Apache conf files then WP theme and addons until i went back to access log files and made another check. After i spent quite some time comparing the results from f2b and access logs i notice many strange connections directly to xmlrpc.php. At that point everything become more clear, bots were exploiting this file to flood my WP in attempt to bruteforce login details.

    So if you are not using some addon to keep track on your login attempts (still not sure if this could work) or you are on VPS/Dedi where you have better control of log files average user doesnt even know what is going on. I can imagine there is some WP users who used htaccess thinking how they blocked direct access to login page. If not htaccess then there is for sure huge amount of users with installed captcha. All this is for nothing, no impact or change on security at all. In reality this is just an illusion as the bots continue to flood your WP site exploiting xmlrpc.php file what, funny but true, makes the job even faster and easier then classic login page.

    Who was thinking in his right mind that enabling this option as default and making it hard to disable was the right choice. This is a joke and WP should go back as it was before 3.5 and leave this or any other similar option for the user to decide to turn it on.

Viewing 11 replies - 1 through 11 (of 11 total)
  • petermolnar

    (@cadeyrn)

    10 years, 11 months ago

    https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html

    And yes, this needs to be addressed FAST.

    Thread Starter diabolico

    (@diabolico)

    10 years, 11 months ago

    After 2 weeks no answer. Is there any chance to get any kind of answer to this subject?

    petermolnar

    (@cadeyrn)

    10 years, 11 months ago

    As far as I can tell, the official answer is to use Jetpack Protect.
    Unacceptable for me though.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    10 years, 11 months ago

    Note: opinions expressed here are mine and mine alone. I’m not on the core development team and I do not have any special insight to the development process.

    As far as I can tell, the official answer is to use Jetpack Protect.
    Unacceptable for me though.

    That’s not the official answer and you can disable XMLRPC if you choose.

    https://wordpress.org/plugins/search.php?q=disable+XMLRPC

    There is no official answer, everyone here is a volunteer including people from WordPress.COM. Their themes and plugins are just another option available in the WordPress repository.

    The XMLRPC interface isn’t turned off by default for the same reason that the wp-login.php isn’t deleted or renamed. If you have a good password on your user ID then those login attempts don’t matter, they’re not getting in that way.

    By good password I mean something along the lines of FiiqLGvrGkv9DAg8RoLN courtesy of my 1Password app.

    When they can’t get in that way then the problem shifts from a bruteforce login attempt to a denial of service problem. That DoS problem will exist if XMLRPC is enabled or not.

    Yes, I use Jetpack’s BruteProtect and do not disabled XMLRPC. But in my case I use that feature because I like participating in anonymous data collection efforts. When someone attempts to brute force login my site then that IP is logged and they’ll get denied when they attack someone else. The same goes with IPs that are already logged and collected.

    Jetpack is not the only option. I don’t use any security plugins but there are many to choose from and I am pretty sure that most of them provide protection against repeated attacks as well as an option to disable XMLRPC if you choose.

    petermolnar

    (@cadeyrn)

    10 years, 11 months ago

    Thank you for the answer Jan. Since there is a ‘board’ releasing the software, there could be an official answer, but I see that my assumption was false, and sorry for that.

    As for the topic: XMLRPC is essential for the JetPack plugin, for the WP Android app, and to accept pingbacks, therefore it’s not really and option for many to disable it. In my case, I’m not using JetPack for various reasons, but I still want pingbacks. So current solution will probably be disabling all allowed methods apart from receiving pingbacks.

    However this is not the first case when XMLRPC is used as an attack surface. It’s too separated from core, not even logging login errors with ‘wp_login_failed’ – this should not be the case and it should have been secured as much as possible, with a priority. Yes, I’m aware that I could contribute, and from this point I may as well try to.

    One more thing: a good password will not save you from brute-force forever and will not prevent the loss of computing power spent on rejecting these.

    Thread Starter diabolico

    (@diabolico)

    10 years, 11 months ago

    Sorry Jan but i do not agree with you. I dont see any logic in enabling something because its nice or convenient and in the same time open the door for bruteforce attacks.

    Actually WP didnt only enabled an open invitation for this attacks but make it quicker and easier than how it was “back in the days” by hitting wp-login. Before the bots was able to make single request on wp-login and then retry again with another request but with xmlrpc they can literally make hundreds request in one single hit. So single attempt could contain 50, 200 or even 500+ different login combinations. Some people going deeper in scanning what is going on have reported even several thousands usernames/passwords per single attack. Scary? It should be. How many WP users know for this? Not many.

    I can bet good part of entire WP user base is thinking how blocking direct access to wp-login or using captcha helps anything. I didnt know how bad is the situation until i moved few WP sites on VPS and dedicated server and at that point fail2ban just went crazy. Two WP sites had huge flood of bots directly on xmlrpc.php, first was more than 1.100-1.200 hits per day and second around 700. Just to know this numbers are based on 2 failed attempts and f2b banning them but there was more than half hits who tried only once and f2b didnt react.

    While i agree that options like xmlrpc.php are good to have or even essential for someone the security should be always main concern. It would be nice to turn it off and let the user activate if needed with a clear warning what that means. Another option would be to change the way how it works and by using htaccess open that file only for some IP’s (or domains) and make it available to set from the interface (easier for everyone). Or, both solutions combined.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    10 years, 11 months ago

    first was more than 1.100-1.200 hits per day

    Hah. My own site gets in excess of 3000 bot hits per hour. Best of luck to them, they’re never going to guess my random 40+ character password.

    Bot attacks are commonplace and have been for ages. Preventing the attack is really a simple matter of using good security measures. It really does not matter how many passwords they try. Only one will work. So make sure it’s not the ones they’re trying.

    If you’re having load issues from the repeated hits to the site, then that’s another matter entirely, and in that case, measures like Jetpack Protect are great because they block the requests before they even happen, thanks to the distributed nature of the detection and blocking. Fail2ban is another great measure, block the attempts before they happen.

    But these are not WordPress specific issues. Any system you put online will have brute force attacks waged against it. You can’t have a login form that is invulnerable to somebody sending it a request every second. Spammers have been doing this for years. And they still are. Who do you think pays for these botnets to run these attacks? Answer: spammers, wanting to get access to your site to post their spam links on there. Simple.

    Practice safe computing, as always. Use strong passwords. If you have load issues, address those as such. That’s all that is really needed.

    Thread Starter diabolico

    (@diabolico)

    10 years, 11 months ago

    Speaking of WP and domain who was active less than 2 months i find 1.000+ too many as we all know the number will only go up how the time go on.

    While i agree with strong password and personally i’m using f2b this doesnt change the current state of WP or to be more specific with xmlrpc.php.

    But these are not WordPress specific issues.

    Well i didnt enabled this “feature” but it comes enabled by default with every WP installation. It could be easily changed to disabled and then leave to the user to enable. The amount of bots hitting this file is there for a reason. Another bad side is hard to see what is going on especially on shared hosting and the human factor, because not many know for things we are talking here. I think your statement doesnt reflect current situation as for my opinion have everything to do with WP.

    Any system you put online will have brute force attacks waged against it.

    True but most of them are trying to make it harder not easier.

    You can’t have a login form that is invulnerable to somebody sending it a request every second.

    Again true, but you (WP) change it so now every single attack can carry several thousands login request not one request per hit.

    Spammers have been doing this for years.

    So lets make it easier for them?

    Who do you think pays for these botnets to run these attacks?

    Rarely anyone pays anything as most of botnets run from hacked servers and/or computers.

    If you have load issues, address those as such.

    Because the software what i’m using (WP) have devs who think how all this mess around xmlrpc.php is perfectly fine even there is easy solution how to prevent all those problems (at least some good part of them).
    But WP its free so who cares for security or how much pressure will be on the server without any justification aside of lack of understanding who created the problem in first place.

    It would be good to have this option off by default or even better, make it as separate installation like we have with “Import” in “Tools”.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    10 years, 11 months ago

    Again true, but you (WP) change it so now every single attack can carry several thousands login request not one request per hit.

    First, that’s not new. That’s always been that way.

    Second, doing attacks like that don’t save the attacker any actual time. It’s a rather weak amplification effect, at best. Arguably, because the number of hits is much reduced, it’s better than having one hit per guess because it is the speed and number of hits that kill your server by tying up all the PHP processes. Reduced hits mean your site is likely to stay alive longer.

    Finally, if you use a strong password or pretty much any of the existing “security” methods that already exist, then them trying to do thousands of tests with one request makes no difference anyway. They get blocked just the same.

    Rarely anyone pays anything as most of botnets run from hacked servers and/or computers.

    Believe it or not, botnets cost actual money. You don’t typically create your own. You buy time on it from some other hacker. Welcome to the wonderful world of the underground.

    It would be good to have this option off by default or even better, make it as separate installation like we have with “Import” in “Tools”.

    While it is likely that the xmlrpc.php code will be going away in favor of the REST API in future versions, the notion that you should need to install something separate in order to get things like mobile connectivity to your site strikes me as a bit silly. Like it or not, more than half of the web’s users now use it exclusively from their phones. Dropping support for that into some kind of add-on is not a great idea if you want to continue to be relevant.

    Thread Starter diabolico

    (@diabolico)

    10 years, 11 months ago

    All what you said sounds so nice but still doesnt change the fact that xmlrpc.php was a huge mistake in design and execution. You now want to shift the talk to hackers and whatever else still this file is part of WP and the base of one of the biggest problems you created.

    In all your replies you mentioned only in one tiny part that WP is going to change this in some future releases (?) but all the rest looks more like stepping on chewing gum on a hot road.

    You got criticized from all sides because of this problem still refuse to acknowledge the mistake. It say more then enough in what state WP come and even more important where it could go in the future.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    10 years, 11 months ago

    https://core.trac.wordpress.org/ticket/34336

Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘xmlrpc.php revert back pre 3.5’ is closed to new replies.