WordPress brute force attack via wp.getUsersBlogs
Now that the XMLRPC "pingback" DDoS problem in WordPress is increasingly under control, the crooks now seem to try brute force password guessing attacks via the "wp.getUsersBlogs" method of xmlrpc.php. ISC reader Robert sent in some logs that show a massive distributed (> 3000 source IPs) attempt at guessing passwords on his Wordpress installation. The requests look like the one shown below
and are posted into xmlrpc.php. Unfortunately, the web server responds with a 200-OK in all cases, because the post to xmlrpc.php actually WAS successful. The expected "403 - Not Authorized" error is part of the XML message that the server returns as payload. Hence, to determine what is going on, relying on simple HTTP web server logs is not sufficient. One of the problems with this is that "traditional" means of curbing brute force attacks in WordPress, like using BruteProtect, are less effective, because most of these add-ons tend to watch only wp_login.php and the associated wp_login_failed result, which does not trigger in the case of an xmlrpc login error.
If you are seeing similar attacks, and have found an effective way of thwarting them, please share in the comments below.
Comments
Anonymous
Jul 22nd 2014
1 decade ago
At least, I think it's a different attack because the POST payload is 10 times larger in bytes.
Anonymous
Jul 22nd 2014
1 decade ago
Anonymous
Jul 23rd 2014
1 decade ago
^.*\[.*\] 200 - <HOST> - .* \/xmlrpc\.php.*HTTP.*$
to a fail2ban filter. In my fail2ban jail.local file, that filter is triggered when
maxretry = 2
findtime = 120
bantime = 86400
Easy, and the server is now even more zen-like.
:-)
Anonymous
Jul 24th 2014
1 decade ago
I did the following:
In Apache, I locked down xmlrpc.php, since it's my own website and I don't use any of the features supported by xmlrpc.
# Restrict access to xml-rpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from xx.xxx.xxx.xx
</Files>
That causes an authorization error to be logged in Apache's error.log, which then is picked up by the apache-auth fail2ban filter, which is tied to an IPSET line in my firewall, sending a "port unreachable" ICMP.
Finally, I have some custom software that scans Apache's access.log for virulent signatures every hour, and adds those IPs to an IPSET in my firewall. I merely added a signature for POST xmlrpc.php. Packets from these attackers are unceremoniously dropped and are added to a more-or-less permanent blacklist.
So, three layers of protection. Since it's my own private webserver, I can do some things that sysadmins for more public servers can't.
Anonymous
Aug 3rd 2014
1 decade ago
Anonymous
Aug 5th 2014
1 decade ago
iptables -I INPUT -p tcp --dport 80 -m string --string "POST /xmlrpc.php" --algo bm -j REJECT --reject-with tcp-reset
You could also block only requests that include the "<methodName>wp.getUsersBlogs</methodName>" string, just to make sure that you're not blocking legitimate use of /xmlrpc.php if you want.
You can get fancier and use iptables's --recent and blacklisting capabilities, but you don't really want to punish the poor victim of a botnet by blocking all their traffic, do you? That's why we're doing at the iptables level and not the fail2ban level. A legitimate user at the site you just fail2banned may want legitimate information from one of your wordpress sites.
Anonymous
Aug 22nd 2014
1 decade ago
I wish I was keen on ModSecurity :(
Anonymous
Aug 23rd 2014
1 decade ago
The general description is that I'm looking at the XML payload (if one exists) delivered in the post to xmlrpc.php. If I determine to not be a valid post (exercise left to the reader) I utilize syslog() to write a log message alerting of such. Then I have an added jail in fail2ban that looks for these log entries and bans as appropriate.
Should this attack morph into a more sophisticated one I plan on adding further logic to my assessing the XML payload to log successful use of the XML-RPC interface so that excessive posts can also trigger further fail2ban action.
I currently know that the XML-RPC interface supports 30+ actions, so I understand the last paragraph potentially represents a bit of work. But for now it's jailing the attackers.
Anonymous
Oct 10th 2014
9 years ago
Add the following code to the top of your Wordpress Theme's functions.php file:
add_filter( 'xmlrpc_methods', 'remove_xmlrpc_pingback_ping' );
function remove_xmlrpc_pingback_ping( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} ;
add_filter( 'xmlrpc_methods', 'Remove_Unneeded_XMLRPC' );
function Remove_Unneeded_XMLRPC( $methods ) {
unset( $methods['wp.getUsersBlogs'] );
return $methods;
}
Anonymous
Jan 8th 2016
8 years ago