| /a1b2c3d4e5f6g7h8i9/nonexistentfile.php
|
Umbra
msg:404137 | 2:31 pm on Jun 22, 2006 (gmt 0) |
Requests for /a1b2c3d4e5f6g7h8i9/nonexistentfile.php have been coming from many different IPs over the last few months. Are so there so many would-be hackers out there, or is this just a worm?
|
Umbra
msg:404138 | 1:43 pm on Jun 27, 2006 (gmt 0) |
Hmm, am I the only one seeing /a1b2c3d4e5f6g7h8i9/nonexistentfile.php in our logs?
|
GaryK
msg:404139 | 3:22 pm on Jun 27, 2006 (gmt 0) |
When it comes to PHP you either have to become inured to the hacking attempts or lose your sanity. :) Most of those log entries are from so-called script kiddies who wouldn't know what to do even if they did hack into your site. Just make sure your setup is secure and that will give you pretty good protection against the more serious hackers.
|
mat
msg:404140 | 4:24 pm on Jun 27, 2006 (gmt 0) |
No, we had something a while ago. I can't remember the exact details, but we formed the conclusion that it was a way of testing to see if mod_rewrite was running as such attempts do not result in a 404 but a server timeout. The string could be anything, as long as it had that number of characters.
|
Pfui
msg:404141 | 8:17 pm on Jun 27, 2006 (gmt 0) |
It's a common exploit: [05/Jun/2006:10:37:44 -0700] "GET /a1b2c3d4e5f6g7h8i9/nonexistentfile.php
[05/Jun/2006:10:37:44 -0700] "GET /adxmlrpc.php
[05/Jun/2006:10:37:44 -0700] "GET /adserver/adxmlrpc.php
[05/Jun/2006:10:37:45 -0700] "GET /phpAdsNew/adxmlrpc.php
[05/Jun/2006:10:37:45 -0700] "GET /phpadsnew/adxmlrpc.php
[05/Jun/2006:10:37:45 -0700] "GET /phpads/adxmlrpc.php
[05/Jun/2006:10:37:46 -0700] "GET /Ads/adxmlrpc.php
[05/Jun/2006:10:37:46 -0700] "GET /ads/adxmlrpc.php
[05/Jun/2006:10:37:46 -0700] "GET /xmlrpc.php
[05/Jun/2006:10:37:47 -0700] "GET /xmlrpc/xmlrpc.php
[05/Jun/2006:10:37:47 -0700] "GET /xmlsrv/xmlrpc.php
[05/Jun/2006:10:37:48 -0700] "GET /blog/xmlrpc.php
[05/Jun/2006:10:37:48 -0700] "GET /drupal/xmlrpc.php
[05/Jun/2006:10:37:48 -0700] "GET /community/xmlrpc.php
Just Google -- "a1b2c3d4e5f6g7h8i9/nonexistentfile.php"
-- and you'll see how prevalent it is. So if you have PHP aboard, be sure-sure-sure you stay on top of every single script's site for updates, checking at least once a month, more often if you really want to stay on the safe side. Here's the latest barrage of exploits I've seen, posted on June 23, ALL of which involve PHP: Vulnerability FYI: "Claroline" Remote Code Execution Exploit (etc.)
[webmasterworld.com...] And here are some earlier ones, not necessarily PHP-specific: Vulnerability FYIs: Horde; also MS Data Pub w/ PUT twist
[webmasterworld.com...]
|
GaryK
msg:404142 | 7:55 am on Jun 28, 2006 (gmt 0) |
| such attempts do not result in a 404 but a server timeout |
|
Why would a request for a non-existent file result in a server timeout? Surely it should result in a 404 (File Not Found) unless your server timeout is really, really quick? :)
|
Pfui
msg:404143 | 2:10 pm on Jun 28, 2006 (gmt 0) |
Good point, Gary. Clearly the intruders I see rarely time out (unless they're from the belly of the beast -- which some may be:) Get turned away, yes, but not timed out. Also, for me, turning them away is a function of SetEnv and not mod_rewrite -- I don't run .php so this is instantly effective: SetEnvIf Request_URI "php" no_way
(muaha-ha) Effect: access_log 216.66.19.70 - - [05/Jun/2006:04:13:26 -0700] "GET /a1b2c3d4e5f6g7h8i9/nonexistentfile.php HTTP/1.0" 403 772 "-" "-"
cgrmail.com - - [05/Jun/2006:10:37:44 -0700] "GET /a1b2c3d4e5f6g7h8i9/nonexistentfile.php HTTP/1.0" 403 772 "-" "-"
[IP and Host unobfuscated because the exact TLD is gone now, or perhaps never really existed... Plus the IP appears here [tanaya.net], in a Firewall DNS Database -- mapped to nine different TLDs.] error_log [Mon Jun 5 04:13:26 2006] [error] [client 216.66.19.70] client denied by server configuration: /path/to/dir/a1b2c3d4e5f6g7h8i9/nonexistentfile.php
[Mon Jun 5 10:37:44 2006] [error] [client 216.66.19.70] client denied by server configuration: /path/to/dir/a1b2c3d4e5f6g7h8i9/nonexistentfile.php
That's just one intruder ('script kiddie' sounds too innocent) hitting x2 in one day. They, and others of its ilk, typically run every single IP in our block in one to two seconds.
|
GaryK
msg:404144 | 4:10 pm on Jun 28, 2006 (gmt 0) |
<rant>
Script kiddie sounds more diplomatic than calling them young, meddlesome, ill-mannered, unethical jerks who aren't even computer-savvy enough to do what they're doing without a pre-written script, and who wouldn't know how to take advantage of an unpatched exploit without again resorting to a pre-written script. I'm nothing if not polite so script kiddie is what I'll call them. ;)
</rant> I think we need to know more about this time-out versus 404 issue.
|
Pfui
msg:404145 | 4:59 pm on Jun 28, 2006 (gmt 0) |
"Jerks" works for me:)
|
mat
msg:404146 | 5:16 pm on Jun 28, 2006 (gmt 0) |
Nope, tried it again. No 404 (I'll actually look at the logs tomorrow and see what is returned), just a hung page. That was the point, that's why we decided it was a check to see if mod_rewrite was running. I'll talk to the expert tomorrow and get him to llok at logs. The following is what shows for browser headers: [domain.com...] GET /a1b2c3d4e5f5g7h8i9/nonexistentfile.php HTTP/1.1
Host: www.domain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: PHPSESSID=990d26d3999b152e7688daa6b0817a5a HTTP/1.x 200 OK
Connection: close
Date: Wed, 28 Jun 2006 17:12:52 GMT
Server: Apache/2.0.46 (Red Hat)
Accept-Ranges: bytes
Content-Encoding: gzip
Vary: Accept-Encoding
Cache-Control: max-age=21600
Expires: Wed, 28 Jun 2006 23:12:52 GMT
Content-Type: text/html; charset=UTF-8
----------------------------------------------------------
|
jdMorgan
msg:404147 | 3:32 am on Jul 1, 2006 (gmt 0) |
I'd guess this was a test to see if you're running one of the many forums or blog packages that include the following type of rewrite -- I may not get this quite right from memory, and I'm generalizing anyway:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !=f
RewriteRule (.*) /script.php?page=$1 [L]
The point being to rewrite any requested URL that does not correspond with an existing (usually static) file to the script, be it WordPress or anything like it. Tons of scripts use this code. If you are running the code above, and the script itself doesn't validate URLs, then any requested URL that would normally return a 404-Not Found would instead be rewritten to and handled by the script, and would likely return a 200-OK. Jim
|
|
|
