Interesting php log entries

Someone trying to make a point, it seems.

[Stefan]

I recently posted in a thread about hijacking - perhaps that was the source of the following log entries that showed-up this morning:

192.#*$!.83.151 - - [29/Nov/2005:08:13:31 -0700] "GET /thisdoesnotexistahaha.php HTTP/1.1" 301 348 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
192.xxx.83.151 - - [29/Nov/2005:08:13:32 -0700] "GET /xmlrpc.php HTTP/1.1" 301 333 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
192.xxx.83.151 - - [29/Nov/2005:08:13:32 -0700] "GET /file/trunk/xmlrpc.php HTTP/1.1" 301 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
192.xxx.83.151 - - [29/Nov/2005:08:13:33 -0700] "GET /log/trunk/xmlrpc.php HTTP/1.1" 301 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
192.xxx.83.151 - - [29/Nov/2005:08:13:37 -0700] "GET /wordpress/xmlrpc.php HTTP/1.1" 301 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
Etc, etc.

Needless to say, these are not my files, and in fact I have no php files on the site. Is anyone here familiar with the exploit that was being demonstrated with this?

[Stefan]

What I don't understand is the 301's that are being given for those files. If you try one of the urls, it gives a 404, of course, 'cause the files don't exist. But when that person came in with them, there's a 301 being generated. I haven't seen this before (well, not that I noticed - this time there were about 25 in a row and it stood out). I'm not having any luck tracking down info with G.

[jatar_k]

strange on the 301, I assume you get a 404 and a 404 is generated in the log when you try the same files

as far as what they are looking for it looks like standard searching for known xmlrpc vulnerable files

[pixel_juice]

Some interesting google results [google.com] for one of those files - the 'agile' thing is suggestive. What does your error log show (if anything) for these requests?

[Stefan]

I just entered the URL again for www.mydomain/thisdoesnotexistahaha.php and dl'ed the error file and logfile. Both the entries below are from my attempt:

[Wed Nov 30 17:35:00 2005] [error] [client 216.abc.def.1] File does not exist: /var/www/html/thisdoesnotexistahaha.php

[30/Nov/2005:17:35:00 -0700] "GET /thisdoesnotexistahaha.php HTTP/1.1" 404 309 "-" "Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8) Gecko/20051111 Firefox/1.5"

I wondered if it first if the 301 could be from mod_rewrite in htaccess to move non-www to www, but then when I tried it I got a 404 - thus my mystification.

I just checked that search, doh, didn't even try that before, just the /xmlrpc.php and a couple of others. Missed the obvious one. Checking some of them now, so far pretty obscure.

Added: Not much help with those searches, eh? Could it be my server doing it because of the mod_rewrite? It's the standard 301 code recommended here by jc for non-www to www.

[pixel_juice]

Were there any error log entires from the previous IP? Did the 301 result in another request from your site (ie if it genuinely as a 301, did it redirect to another of your files (the filesize difference suggests the redirects were to different places))?

And just for the sake of it, I would ensure your tests replicated the originial requests as exactly as possible (use "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" as the U/A).

[Stefan]

>>Were there any error log entires from the previous IP? Did the 301 result in another request from your site (ie if it genuinely as a 301, did it redirect to another of your files (the filesize difference suggests the redirects were to different places))?

Sorry, was just about to add that. No, no errors for when the other IP came in. Also, the last hit after the 301's on the .php pages was a 400 for [29/Nov/2005:08:14:04 -0700] "GET HTTP/1.1" 400 - "-" "-"
There were no pages in the log that were being 301'd to.

>>And just for the sake of it, I would ensure your tests replicated the originial requests as exactly as possible (use "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" as the U/A).

Just tried that, good thinking, but it still gives a 404.

[pixel_juice]

Added: Not much help with those searches, eh?

I guess that depends. Even apparently unhelpful data can still suggest certain things, for instance:

All are from the same IP
All are during this month
The attempts target a limited range of IPs (do you share this IP range?)

[Stefan]

The IP that was at my site was a different range than those. 192.170.x.x hit me, 60.248.x.x is found in the error files via G. I was assuming that the agile site just happens to have their error logs online for some reason - but they were responding with errors, anyway, not 301's.

>The attempts target a limited range of IPs (do you share this IP range?)

No, my site is 69.36.x.x. I've got agile as 204.83.x.x

I don't know if it's some clever hacker looking for vulnerabilities that don't exist on my site (no php), or my server doing something weird with a not-found .php file. If it were returning 404's, I wouldn't mind - I get various hack attempts for windows all the time (I'm on apache).

Added: Of course, at first I thought it was a hijack demonstration on my site, so if it's an attempted php hack, I feel somewhat better.

[pixel_juice]

From the mentions of this on the original google search and yahoo, my opinion is that the requests for /thisdoesnotexistahaha.php is part of a vulnerability scan engine of some kind.

I'm wondering if it my be a test of whether 404s deliver the correct headers, as if it didn't a 200 response for any page would indicate a vulnerable script, although in reality it wouldn't exist and so there would be no point in the hacker returning to that site, or adding it to the list of potential targets. The fact that it seems to be the first test might confirm that.

The 301 is definitely odd, although I would still suggest this is particular to your website (and very difficult to explain - do you use a custom 404 page?).

[Romeo]

Could it be my server doing it because of the mod_rewrite? It's the standard 301 code recommended here by jc for non-www to www.

... most likely.
Just try a "mydomain/thisdoesnotexistahaha.php" with curl and look into your log -- you should see a similar 301.

The 301 is just a status code sent to the client together with another URL. It is up to the client, if it follows the 301 and does another fetch for the 301-ed new URL (as most browsers do) or not (as a bot programmed not to do). This may explain, why you see a single 301 with no following 404, because the bot was simply not following the 301.

Regards,
R.

[Stefan]

Many thanks, Romeo, I think you've got it. It was the 301 that was confusing me. I've had regular probes for other vulnerablities, but that was the first attempt looking for php that somehow made the mod_rewrite kick out a 301.

I'm sure others will see similar entries in their logfiles in the future (the agile hits were recent, might be early-days for it), especially if they're using htaccess mod_rewrite to move non-www to www, or visa-versa. Perhaps, by then, search will again be possible for WW threads and we'll have saved someone some time when they come across this.

The code that is doing it, apparently, follows (examplified):

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST}!^www\.example\.org
RewriteRule (.*) http://www.example.org/$1 [R=301,L]

[jdMorgan]

> I wondered if it first if the 301 could be from mod_rewrite in htaccess to move non-www to www, but then when I tried it I got a 404 - thus my mystification.

Request your site by its IP address, and see what you get in your logs, 301 or 404. I see this exploit trying to fetch the same files from my server, accessing it by IP address, e.g. http://128.***.92.***/xmlrpc.php
It gets a 403, though, 'cause I got tired of it... :)

Also, try the WebmasterWorld server headers checker [webmasterworld.com] to see any redirect/error responses one-at-a-time.

[added]
For safety against entering an "infinite" redirect loop if a true HTTP/1.0 client accesses your site, use:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\.example\.org
RewriteRule (.*) http://www.example.org/$1 [R=301,L] 

An HTTP/1.0 client won't send a Host header, so you need to check HTTP_HOST for non-blank as well as non-www, otherwise the HTTP/1.0 host will just keep requesting with a blank HTTP_HOST and getting redirected -- until it or your server hits its maximum redirection limit.
[/added]

Jim

[Stefan]

Request your site by its IP address, and see what you get in your logs, 301 or 404.

I just tried that. When I entered the URL as IP#//thisdoesnotexistahaha.php.
the server just immediately redirected to www.mysite.org/thisdoesetc.php, with a 404, and the logfile also shows the 404. (My site has a unique/dedicated IP#).

And jd, my apologies for referring to you as "jc" in a previous post - I realized the error soon afterwards - it must be from all the Christmas carols I'm hearing lately ;-) And thanks for the extra line of code - it will be added, merci bien.

(By the way, if anyone wants to experiment, the site it happened to is the one in my profile - don't destroy the thing in the process though ;-)

Added: server headers check on www.mysite.org/thisdoesnotexistahaha.php gives:
HTTP/1.1 404 Not Found
Date: Sat, 03 Dec 2005 04:00:19 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.3.0
Connection: close
Content-Type: text/html; charset=iso-8859-1

[jdMorgan]

The server header checker shows your site responding normally, and as I'd expect it to, given the code you posted above:

Request http://www.example.com/thisdoesnotexistahaha.php results in 404-Not Found

Request http://example.com/thisdoesnotexistahaha.php results in 301-Moved Permanently redirect
.... to http://www.example.com/thisdoesnotexistahaha.php

Request http://69.36.***.64/thisdoesnotexistahaha.php results in 301-Moved Permanently redirect
.... to http://www.example.com/thisdoesnotexistahaha.php

> the server just immediately redirected to www.mysite.org/thisdoesetc.php, with a 404

... or it appeared to; The 301 response was handled first, followed by a 404 response. It is your browser that must re-request the requested page from the correct domain, so this actually requires two steps. If you want to see accurate results using a browser, you need to do two things: First flush and disable the browser cache, and second, use a VERY slow internet connection. If you don't flush your cache, you won't see the requests in the logs, because your browser will serve them from its local cache instead of fetching them from your server. That's why I suggested using the server headers checker. If you use a reasonably-fast (like 28.8kbps or above) internet connection, the 301 is handled so fast by your browser that all you will be able to see is the 404.

Jim

[Stefan]

Many thanks for poking around and checking stuff, Jim. Copy on what was going on. Good to know that things are how they should be.

You'll find a sticky in your Inbox.

Stefan