Same problem here. So many requests it was lagging our server.
I edited xmlrpc.php and put die() at the top. As far as I know we don’t use any of the xmlrpc functions on a day to day basis.
This is a nice way of bypassing login captcha / other checks.
I am seeing this on multiple sites now, so it appears to be a widespread attack.
I had this happen to a clients site earlier this month and have had little luck in finding any way to stop it without potentially breaking anything else.
Hopefully the current popularity of this attack will spawn some solutions.
Hey David,
When XML-RPC authenticates a user (see class-wp-xmlrpc-server.php:182) it calls the “wp_authenticate” function. If you refer to that function (see pluggable.php:521), you can see that the wp_login_failed hook is called.
When an xmlrpc login fails, it ALSO calls xmlrpc_login_error, but this is in addition to wp_login_failed
Am I missing something?
Best,
Sam
Hi Sam,
Sorry about this – what you say is correct, but I think that I got confused when describing what I was seeing, because I’ve described the wrong thing, wrongly. Not sure what I was doing there.
What I should have said was about the actual IP check, rather than logging the result.
BruteProtect hooks the wp_authenticate action, which is called by wp_signon() in wp-includes/user.php.
However, xmlrpc.php doesn’t call that. Instead, it calls wp_xmlrpc_server::login() in wp-includes/class-wp-xmlrpc-server.php, which in turn calls wp_authenticate() in wp-includes.user.php – which, confusingly, does not (AFAICT) call the wp_authenticate action. Instead, it calls the authenticate action (i.e. no wp_ on the front). And BruteProtect does not hook this action. So BruteProtect cannot prevent a successful brute-force login attack through xmlrpc.php.
I may have missed something else. But I think I’ve explained it without suddenly switching track and talking nonsense this time. 🙂
David
Looks like you addressed this in 2.0.9…
Hi David
It seems you should be all set. If you need anything else please open a new ticket or email me at jesse [at] getparka.com
There’s a variant of this attack that results in a PHP warning, which was cluttering up my error logs with:
PHP Warning: array_unshift() expects parameter 1 to be array, string given in /../wp-includes/class-wp-xmlrpc-server.php on line 518
I tracked it down to a <edit>similiar</edit> xmlrpc post to the one in David Anderson’s report, but with an empty password. WP parses that as a singleton array and then treats it as a string (see line 455 of class-IXR.php). The credentials that end up going through wp_authenticate at line 223 if they try ‘admin’ are:
username: d
password: m
Those are the [1] and [2] elements of the the string treated as an array. In my case they had a different username.
Hi Kitchin,
If I’ve understood you rightly, then you should report that in the WordPress core Trac – posted in a support forum for a specific plugin, nothing would be likely to happen with it.
David
It’s more or less a bug. I think WP allows PHP Warnings for some malformed data. Anyway, it alerted me to the attack.
As for the plugin, the devs may want to know where single letter tries are coming from – xmlrpc.
Thanks for reporting this, I had no idea where it was coming from and had to debug on a live server to figure it out. I though it was some wanky plugin or theme function.
I added some tags so other people can find this. I’ll file a bug and see what they say. That’s another place people look to figure out Warnings.
I am from time to time still reciving this attacks (WP 4.0)
=> “1.0”?>wp.getUsersBlogs admin “some password”
one somekind of solution is to add this code in funcions.php
<php
function Remove_Unneeded_XMLRPC( $methods ) {
unset( $methods['wp.getUsersBlogs'] );
return $methods;
}
add_filter( 'xmlrpc_methods', 'Remove_Unneeded_XMLRPC' );
timjony60: this thread is obsolete. A subsequent BruteProtect update hooked the right thing and now blocks brute-forces via this method. Also, your method will only block one particular XMLRPC method, whilst leaving many others open.
+1 David
Thanks for bringing that to our attention timjony60. I’m going to keep this thread as resolved.
Feel free to start a new thread with any other issues that come up.
