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.

[lucy24]

They do seem to pass a Cookie as a part of the headers:
<snip>
Cookie: wordpress_test_cookie=WP+Cookie+check

Is that a real cookie, meaning they've been there before, or a made-up cookie that they're randomly throwing in?

:: wandering off to look up what "Content-Length" means in a request header ::

[blend27]

It's a fake Cookie. I don't run WP, nor anything related to PHP. Here are some header sets that they send and as you may see the the UA's Different as well:

ALL HTTP 1.1
ALL Method GET

Host: domain.tld
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20130406 Firefox/23.0
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Content-Length: 0
Referer: https://www.google.by/search?q=domain.tld
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-Original-URL: /xmlrpc.php

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
X-Original-URL: /xmlrpc.php?rsd
Host: www.domain.tld
Keep-Alive: 300
Content-Length: 0
Connection: keep-alive

Host: domain.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

Host: domain.tld
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Cache-Control: no-cache
Referer: http://domain.tld
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; Zango 10.3.35.0)
Pragma: no-cache
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
DNT: 1
Content-Length: 0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-Original-URL: /xmlrpc.php

In the real world the above would indicate that the form was submitted via a GET method.....

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
X-Original-URL: /xmlrpc.php
Host: www.domain.tld
Accept: */*
Content-Length: 0
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded; Charset=UTF-8

All of these fail a standard headers check routine in my code.

[JS_Harris]

I'm actually surprised that this is catching anyone by surprise. For years I have caught Google(real google, verified IP etc) checking this, and other similar files, directly. About once or twice per month a single request to these files checks out as an official Google check, sometimes only requesting a HEAD response. I always assumed that Google was checking to see if I was using wordpress and to see if my installation was up to date and secure.

This new wave of hack attempts is troubling but the direct request for that file is far from new. You can safely disable access to that file via htaccess if you do not allow remote publishing. If you do allow remote publishing I suggest you whitelist the IP addresses you allow to remote publish and serve up the generic "remote publishing disabled" response built into wordpress for the rest.

In my opinion these pages should never have been serving up a readable response to begin with but Wordpress is full of these weaknesses. Another that irks me is that if someone guesses which email you use to log in the login screen behavior itself verifies this for all to see by then only demanding you enter a password instead of both a password AND login. It lets hackers only have to focus on a password, not a password and login combination.

If you're going to fix this weakness I suggest you do an audit for all possible security issues and apply a solution for all of them, not just a patch for one. Make sure you review ALL of the wordpress features you do not use, wordpress has many features that go unused but sit dormant as possible access points for malicious behavior.

[Pfui]

FWIW for Featured Home Page newcomers: The main point of this thread details a very specific bot/exploit pattern, first seen in early June:

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

Have you seen anything matching exactly that?

[lucy24]

It's a fake Cookie.

Oh, my goodness. I've never happened to look at cookies, because only a handful of pages use them for anything other than piwik. But pulling up the most recent headers I've got saved (two days ago) there's a steady stream of

Cookie: wordpress_test_cookie=WP+Cookie+check

Further cross-checking with raw logs tells me they all got a 403 slammed in their faces, possibly because they were asking for things like wp-login.php.

Edit: What does X-Original-URL mean? The horse's mouth is silent :( as you might expect with a header in X-something.

matching exactly that?

Did you mean the request + UA package? Detour to raw logs to search for the exact UA-- not the request, which is what I was looking at earlier-- and ignoring the ones from a few years ago when it was a bona fide human UA, I find them starting abruptly on 13 June. All of them, without exception, were asking for /xmlrpc.php. It's a botnet using infected browsers, isn't it? IPs vary all over the place. Headers from the most recent date all look like this:

IP: aa.bb.cc.dd
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Content-Type: application/x-www-form-urlencoded; Charset=UTF-8
Connection: close

The "example.com" is interesting because a lot of 403'd requests get it wrong and ask for "www.example.com"

[edited by: lucy24 at 1:31 am (utc) on Jul 11, 2015]

[keyplyr]

What does X-Original-URL mean?

Not knowing exactly where you're seeing this, but I assume it's the name of the originally requested URL HTTP request header. For it to be populated I think you need this directive in your httaccess:

X-AddOriginalURL ON
- or -
Header append X-AddOriginalURL
- or -
Header set X-AddOriginalURL

...depending on how your server is set-up. Or, of course, it could be ON at admin level if you are seeing the field populated and haven't set it at the account level.

[lucy24]

Not knowing exactly where you're seeing this,

In one of the header sets quoted further upthread. I've never seen it on my own site. Is it something you can optionally set when redirecting?

[Pfui]

starting abruptly on 13 June. All of them, without exception, were asking for /xmlrpc.php.

That's it! Thanks for checking for the exact, very limited parameters that seemingly appeared out of nowhere around that time.

a botnet using infected browsers, isn't it?

Not so sure what -- or who -- it is, which keeps me curious. Infected browsers? Not so sure about that either. Could just as easily be compromised machines running some program that makes hits appear to be by Linux FF 4.0.1.

[keyplyr]

Is it something you can optionally set when redirecting?

I think so (as stated in my post above.) I've never used it myself, but have worked on client sites with it a while back. Helpful if you have a site that takes visitors to a remote server, then onto somewhere else. I'm sure there's stuff at apache.org somewhere.

[aristotle]

I think the original flurry of requests (Firefox/4.0.1) probably came {and still coming) from a botnet. But then some variations of the request began showing up that don't appear to be associated with a botnet.

[blend27]

Is it something you can optionally set when redirecting?

It is actually the exact URL that is being accessed. It is used when we do rewrites in .htaccess. It could be called many different ways depending on the server and setup(ISAPI_rewrite, Mod_rewrite, etc..) and could be accessed programmatically later on in application code/logic .

RewriteRule ^index\.php$ default.aspx? [NC,R]
where /index.php?param=value will be your X-Original-URL, including the query string, and would be appended to the standard headers sent by request.

[lucy24]

and would be appended to the standard headers sent by request

The part I'm confused about is: Does this new header show up in later processing of the same request (that is, the mods that execute after mod_rewrite), or is it sent back to the originating requester for them to append to the follow-up request (the one they're being redirected to)?

Attempting to look it up, most of what I found had to do with IIS and/or proxies. This does not reduce the confusion :(

[blend27]

Does this new header show up in later processing of the same request..

Yep, You got it!
It is mostly used on IIS6 with ISAPI_Rewrite, IIS7+ has its own blend(less that 27 :) of them..)

[henry0]

a while ago I posted this
[webmasterworld.com...]

[SirTox]

It works best to redirect these folks to the 0.0.0.0 IP Address. Uses less resources on your server.

Add this to htaccess:

RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

[lucy24]

I don't think it took me five years to learn that you don't escape anything in the target, and there's no need for quotation marks.

Besides, 127.0.0.1 is more fun.

[lucy24]

Careful, henry, now you've got four seemingly identical posts pointing to two different threads (/wordpress/4666540.htm and /search_engine_spiders/4753373.htm).

[keyplyr]

The most simple remedy...

RewriteRule xmlrpc - [F]

[anallawalla]

I was redirecting requests to example.com (literally to that domain) but I'll try one of the above tips that are more neighbourly.

[lucy24]

Please, please don't redirect to any address that really exists. Other than, of course, the offender's own originating IP (which would serve them right, especially if the robot is too stupid to notice). It is sometimes tempting to redirect to fbi.gov or similar, but I really don't think they would take kindly to it. Might even blow up in your face.

[Pfui]

I was redirecting requests

Most major exploits don't follow off-site redirects or rewrites anyway, so [F] is quick 'n' easy. (But like Lucy, I relish using 127.0.0.1 on occasion;)