Share

So, yesterday, I got a few emails from Wordfence with messages that said:
A user with IP address 77.50.79.254 has been locked out from the signing in or using the password recovery form for the following reason: Used an invalid username 'test' to try to sign in.
User IP: 77.50.79.254
User hostname: 77.50.79.254
User location: Russia

This happens a few times each month, so I checked settings in Wordfence to see what else I should be doing.

And I found this:

wordpress_exploit_attempt

Wordfence usually emails me whenever there are login attempts, but not something like this. So I found attempts going back for at least a month that I didn’t know about.

Time to get to work.

A quick look at Google for “WordPress WPTF” told me it was a plugin with a vulnerability. Fine. Time to block that string in wordfence. I found other things in the logs referencing other vulnerable plugins, so I had a few strings to block. I did not have any of these plugins installed, but I wanted the attackers’ IPs to be blocked immediately just by trying to use a URL.

Done.

Time to check the logs.

I kept seeing this:

125.176.6.55 - - [03/Jul/2016:00:02:35 -0400] "POST /xmlrpc.php HTTP/1.1" 200 446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

The only thing using xmlrpc.php is Jetpack and the mobile app, which I haven’t used in a while.

I searched for any other instances of xmlrpc.php in the logs and found about 2000 hits in just a couple of hours. Someone was trying hard to get in, but no other login attempts were being reported.

So, I searched some more, and I found this article where the author experienced a similar attack:

Huge increase in WordPress xmlrpc.php POST requests

I don’t have the postdata for each attempt, but the byte count indicates it’s not that large. (around 447 per hit).
Line 296: 122.53.228.216 - - [03/Jul/2016:00:09:49 -0400] "POST /xmlrpc.php HTTP/1.1" 200 448 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
Line 297: 41.68.172.36 - - [03/Jul/2016:00:09:52 -0400] "POST /xmlrpc.php HTTP/1.1" 200 446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
Line 512: 103.196.137.134 - - [03/Jul/2016:00:10:43 -0400] "POST /xmlrpc.php HTTP/1.1" 200 449 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
Line 670: 46.161.106.19 - - [03/Jul/2016:00:10:57 -0400] "POST /xmlrpc.php HTTP/1.1" 200 447 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

I searched the logs for that user agent string, and these attempts are the only thing that would come up in my logs. I didn’t want to block xmlrpc.php and lose access from the mobile app or Jetpack, so I had to find another way. Blocking the string seems to be the only answer right now, so I set up a block in Wordfence.

But that quickly spiraled out of control with the number of hits the plugin was logging in my database, and the dramatic increase of IP‘s in my .htaccess file. In fact, it triggered a block of the database user account twice. So I had to stop it, clean it up, and find another way.

In the article linked above, a commenter redirected all of the attacker’s traffic back to themselves with a rule in .htaccess. So I decided to try something similar.

Thanks for posting this although for me the attacks still seemed to be coming somehow.
What worked for me was to add the following line to the .htaccess file:
Redirect 301 /xmlrpc.php http://127.0.0.1

I found the information here:
http://www.linuxbabu.net/2014/07/wordpress-xmlrpc-PHP-attack/

This stopped the attack with the added bonus that the attackers are now attacking themselves as 127.0.0.1 redirects back to the requester.

The commenter is redirecting every call to xmlrpc.php to the attacking machine’s loopback address, but I wanted to narrow it down to just the userstring. I found this post in WordPress forums:

https://wordpress.org/support/topic/resolving-xmlrpcphp-ddos-attack-with-htaccess-redirect

This was exactly what I wanted to do. The last comment shows a rule that redirects to the attacker’s public IP, but I was more interested in them directly attacking their own machine’s local loopback address. The last comment in the post showed how I could do exactly that.

# Block attackers by agents
RewriteCond %{HTTP_USER_AGENT} ^.*WinHttp\.WinHttpRequest\.5.*$
RewriteRule .* http://%{REMOTE_ADDR}/ [R,L]

I just edited the string and the rewrite rule, and the attacks were redirected back to the attacker’s machines.

# Block attackers by agents
RewriteCond %{HTTP_USER_AGENT} Mozilla/5\.0\ \(Windows\ NT\ 6\.1;\ WOW64;\ rv\:40\.0\)\ Gecko/20100101\ Firefox/40\.1
RewriteRule .* http://127.0.0.1/ [R,L]

I went back to watch the logs. The POST calls to xmlrpc.php  then showed 302 (temporary redirect) for each attempt. The attacks slowed, and finally stopped.

Line 11049: 103.232.129.166 - - [03/Jul/2016:05:19:32 -0400] "POST /xmlrpc.php HTTP/1.1" 302 207 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
Line 11056: 103.232.129.166 - - [03/Jul/2016:05:19:54 -0400] "POST /xmlrpc.php HTTP/1.1" 302 207 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
Line 11256: 197.167.11.196 - - [03/Jul/2016:05:34:03 -0400] "POST /xmlrpc.php HTTP/1.1" 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

While it is more likely the attacking machines are part of a botnet, and I haven’t actually stopped the people pulling the strings, it did stop the flood for now, and it isn’t putting a load on the server this way.

Barnes & Noble
Tagged with:
 

Comments are closed.