GET /xmlrpc.php

Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

[keyplyr]

XML-RPC is a remote procedure, among other uses, is part of Wordpress installs which creates a file named: xmlrpc.php.
If found, it can be used to exploit account access using HTTP as a transport mechanism..

"GET /xmlrpc.php HTTP/1.1" 403 1567 "-" "Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"

This actor always uses the same UA, always requests this file, but uses hundreds of compromised ISP accounts. IMO block with extreme prejudice.

[blend27]

I have seen bunch of them from Portugal and Iran recently from ISP accounts.

There are also these from Ukraine`s Kyivstar GSM:

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

to

/xmlrpc.php?rsd

There were also a large outburst of requests to these back in first half of 2009 to:

/adxmlrpc.php
/phpads/adxmlrpc.php
/phpadsnew/adxmlrpc.php
/phpAdsNew/adxmlrpc.php
/adserver/adxmlrpc.php
/Ads/adxmlrpc.php

...where all requests were made via site`s IP and not the domain, UA was either Blank or bunch of random characters.

by various UAs from ISPs accounts from all over the world as well

[Pfui]

Thanks for mentioning this new plague, keyplyr.

Before last Friday, I'd never seen just the solo request for "xmlrpc.php" + FF 4.0.1 combo. The hits started up that evening, then seemed to double every 12 hours. (Aside: I already block both the URI and the UA.) A week later, I'm seeing 30 or so unique, compromised IPs an hour on my largest site, but fortunately the rate's no longer doubling.

FWIW, I thought about hunting around for an old script here that automatically writes IP addresses to .htaccess based on specified conduct, e.g., types of files requested, etc. But I couldn't figure out how to get the script to work way back when, so I decided to wait and see how awful this new botnet spawn might become.

Bottom Line: YIIIKES. The ongoing visible proof of sooooo many infected, newly awakened zombies gives me the willies.

Maybe I will look around for that script after all...

[keyplyr]

@ Pfui - except these are compromised accounts, most of which will presumably be discovered by the host/user and fixed so in the long run you'll be blocking real humans.

You can say, ahhh they're just Russians, or just Chinese that would never legitimately come to my site, but things change. I found that out when launching mobile. Now 20% (or more) of my legit visitors are from Asia, where just a few months earlier I blocked all those IP ranges. Ukraine, Russia and other Easter Euro regions also send me a little traffic where I once blocked.

[lucy24]

IMO block with extreme prejudice.

I've got a generic block on php requests ([NS] flag) on any but the tiny number of pages that really have ".php" in their URL.

[keyplyr]

Yeah, Lucy yours is an easy one since you don't have visible php extensions. You can just block "php."

I don't know the exact number, but it seems a huge percentage of the internet is WP nowadays. My OP was more of a heads-up for those that have WP sites, but it should also be of concern to everyone who uses shared hosting since we are only as secure as our neighbors.

When I was at a former host, a bad actor gained access through a PHP vulnerability at one site, then moved laterally across 900 other sites planting a trojan script that, when later awakened, infected a very big number of visitor's browsers/machines. That one made the news.

[keyplyr]

More... that was a few years ago and one would think that security has greatly improved since then, and it may have but as we know, when technology moves forward, so does the exploits.

My personal site sits on a popular shared host in So. California; good & fast, never any down time. However, not a week goes by that I don't find dozens of hack attempts in my logs from other IP ranges assigned to my host. I report them, sending in log data, but it gets old.

And I once *accidentally* accessed another account on my server by mistyping a path using a well-known FTPS software. So IMO, not very secure at all.

[lucy24]

since you don't have visible php extensions

But WP itself doesn't normally use ".php" in URLs, does it? I'm always seeing questions about "friendly" URLs where the choice seems to be between extensionless and trailing slash, nary a php to be seen. So you can still block by THE_REQUEST. I've got some rules in that format for the /includes/ directory (which I now realize I should have called something else, but too late now) which of course does have php filenames.

I know one site-- hand-rolled-- where almost every URL ends in /index.php. It gives me the fantods every time I visit ;)

[keyplyr]

But I couldn't block "php" since I have a few pages using the php extension and I remembered you didn't, that was me point. The file itself "xmlrpc.php" is still present in all/some out-of-the-box WP installs AFAIK.

I've got some rules... for the /includes/ directory (which I now realize I should have called something else

Ain't that the truth

[aristotle]

seemed to double every 12 hours

That sounds pretty ominous. If it continued growing at that rate, in ten days or so it could be in the millions.

[keyplyr]

seemed to double every 12 hours

That sounds pretty ominous. If it continued growing at that rate, in ten days or so it could be in the millions

fortunately the rate's no longer doubling.

Well, as much as I would have liked to see that monumental event, alas it appears the anticipation was for naught :(

[Pfui]

The zero-to-60 appearance of this specific plague intrigues me. But watching the first few days' hits increase was indeed worrisome because there's no way our server's equipped to handle mass traffic, denied or otherwise.

(I loved and miss our old WatchGuard Firebox, but I'm not wild about suddenly having to buy a new one.)

Thankfully this single-file probe's apparently limited to Linux boxes right now, but an awful lot of them: In the last hour, seven out of eight Linux (box, not phone) hits were these new zombies.

Surprisingly, it's not a new exploit. [perishablepress.com...]

[Pfui]

Sixty-two hits in the last 12 hours. A new high. Are y'all seeing lots of these? Is the hit rate steady or increasing?

[keyplyr]

Just block it and forget about it :)

[aristotle]

These requests are still showing up quite often, but with a lot of new variations, such as different UAs, various combinations with other requests, and even fake referals from Google search.

[Pfui]

Are the requests just for /xmlrpc.php or are other files requested, too? I ask because I'm still seeing loads of just the single file request and always only using:

Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

(Other .php requests are typically for multiple files/exploits and reflect a mix of UAs.)

[aristotle]

Well here are a couple of examples from overnight. I haven't had time to look at my other sites yet, but if you want some more, I can probably find them later.

Host: 110.86.167.45
/
Http Code: 403 Date: Jun 30 02:12:18 Http Version: HTTP/1.1 Size in Bytes: 13
Referer: -
Agent: -

/xmlrpc.php
Http Code: 403 Date: Jun 30 02:12:19 Http Version: HTTP/1.1 Size in Bytes: 13
Referer: -
Agent: -

/wp-login.php
Http Code: 403 Date: Jun 30 02:12:19 Http Version: HTTP/1.1 Size in Bytes: 13
Referer: -
Agent: -

Host: 37.115.187.54
/robots.txt
Http Code: 200 Date: Jun 29 23:35:22 Http Version: HTTP/1.1 Size in Bytes: 260
Referer: -
Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

/xmlrpc.php?rsd
Http Code: 403 Date: Jun 29 23:35:22 Http Version: HTTP/1.1 Size in Bytes: 13
Referer: -
Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

/
Http Code: 403 Date: Jun 29 23:35:22 Http Version: HTTP/1.1 Size in Bytes: 13
Referer: -
Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

[aristotle]

Well now that I look more closely, those may be bad examples, since they're probably not from the botnet that produces the others.

[lucy24]

:: detour to raw logs ::

:: twiddling thumbs as TextWrangler does its thing ::

This one's interesting:

195.211.155.156 - - [02/Apr/2015:07:13:50 -0700] "GET /xmlrpc.php HTTP/1.1" 403 3301 "http://example.com/xmlrpc.php" "\"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0\"" 
195.211.155.156 - - [02/Apr/2015:07:13:50 -0700] "GET /directory/xmlrpc.php HTTP/1.1" 403 3301 "{autoreferer as above}" "{same UA}" 
195.211.155.156 - - [02/Apr/2015:07:13:50 -0700] "GET /directory/page.html/xmlrpc.php HTTP/1.1" 403 3301 "{autoreferer as above}" "{same UA}" 

That makes it look as if it's some kind of trackback, doesn't it? Not all requests look like that; some are on-offs while some are POST instead of GET. But I found some others of this pattern, always using real pages,* most of them with a full autoreferer (that is, including the "xmlrpc.php" part).


* That includes interior pages-- generally the more popular ones-- and it's never a systematic list of all directories.

[aristotle]

Here's one with a fake referal from google.by search

Host: 5.45.64.77 
/xmlrpc.php 
 Http Code: 403 Date: Jul 01 06:29:13 Http Version: HTTP/1.1 Size in Bytes: 13 
 Referer: https://www.google.by/search?q=example.com
 Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130405 Firefox/22.0 

[lucy24]

Hey, I got a fake google.by not long ago. I think it became the first Belarus range to get added to my bad_russia environmental variable.

But free lookup says that 5.45.64-71 is Serverius (Netherlands) so that seems a safe lockout.

:: wandering off to find out whether Belarus is exceptionally poor or just very small, because I practically never see them ::

[dstiles]

> whether Belarus is exceptionally poor or just very small

I have over 300 BY IPs blocked, mostly belpak. Admittedly most are at least a year old; not too many this year: 11 in the past 100 days, again mainly belpak.

[Pfui]

Seeing slight changes in the "/xmlrpc.php"-only hit pattern:

- Blank UA; on my machine that logs as: "-"
Seen 5 times in last hour; the 'usual' Linux FF 4.01 seen 6 times.

- Repeat hits; e.g. from a Vietnamese IP (only one multi-hit seen):

07/08 07:51:03 /xmlrpc.php
07/08 12:09:15 /xmlrpc.php
07/08 12:30:32 /xmlrpc.php

All of the above get 403'd in numerous ways, but if anyone doesn't automatically block blank UAs, here's a head's up.

[aristotle]

Pfui -- What about fake referals from Google.by search? Have you seen any of those yet

As I mentioned earlier, I think that the original flurry of requests came from a botnet, but these newer cases probably not.

[Pfui]

Have not seen any Google.by referrers, real or otherwise, but have not really been on the lookout, sorry. FWIW, none of the solo "/xmlrpc.php" hits I've seen have referrers.

[aristotle]

Here's one from this morning:

Host: 91.200.12.138 
 /xmlrpc.php 
 Http Code: 403 Date: Jul 09 09:15:30 Http Version: HTTP/1.1 Size in Bytes: 13 
 Referer: http://example.com/xmlrpc.php 
 Agent: \Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0\ 

[Pfui]

Wow, that's a particularly bad one from an already yucky Ukranian cess pool: [projecthoneypot.org...]

At least the backslashes in the UA (sloppy!) are a sure-fire tip it's a bot.

aristotle, it's interesting that you keep seeing so many variants, different UAs, different referrers, etc. I forget -- do you even see the OP 'standard' one, single hit, ostensibly using FF 4.0.1, with no referrers?

[aristotle]

do you even see the OP 'standard' one, single hit, ostensibly using FF 4.0.1, with no referrers?

Yes that's probably still the most common one I see.

[aristotle]

Maybe word has spread among hackers that this is a relatively easy vulnerability to find and exploit. I don't know if that's true or not, but some hackers or hacker wannabes might think it is. So that could explain why new variations of the request keep appearing.

A week or so ago I started using FilesMatch to block all requests for xmlrpc.php. In this case I like a 403 better than a 404.

[blend27]

They do seem to pass a Cookie as a part of the headers:

Host: mydomain.tld.
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=0
Content-Length: 0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cookie: wordpress_test_cookie=WP+Cookie+check
X-Original-URL: /xmlrpc.php
Connection: keep-alive