11

I have many attempts on my (small, personal and absolutely unimportant) web server, and apache and fail2ban usually do their job right. But there's a log entry that worries me:

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

The problem is answer wasn't a 404 code, but a 200 instead. Is that okay? Seems weird to me, but my knowledge on this field (and many others) is, to put it softly, limited.

  • 1
    Looks like I'm not allowed to post a new answer, but we found an entry like this in our logs, and we were able to verify that it was not dangerous by reproducing the request with curl: curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. The default config seems to return a "Welcome to nginx" page with no meaningful content, on our ubuntu system. So it's a 200 response, but it's a simple catch-all page -- we're not actually proxying the request elsewhere or anything like that. – Frank Farmer Feb 26 '13 at 1:41
12

First, up front, I don't know what the presumed attacker is trying to accomplish. Maybe there's a PHP script or PHP version out there vulnerable to some strange session ID attack, I dunno. You probably have nothing to worry about, though.

Your server behaved exactly as expected. 200 is the expected code in that particular situation because of how Apache interprets the URL being passed to it.

First, http://allrequestsallowed.com is treated like the more usual 'Host:' header (note that I don't think this is specified in the RFC and other servers may not interpret it this way I was wrong, this is specified in RFC 2616 in section 5.1.2, even though clients rarely seem to use that form. Excuse me, I need to go fix an HTTP server implementation I wrote a while back...).

Now, presumably you don't have a site named 'allrequestsallowed.com'. So what happens when Apache gets a Host: header (or equivalent) for a hostname it doesn't recognize? It picks the first virtual host as the default. This is well-defined and documented behavior for Apache. So whatever your first virtual host is (or just the main server configuration if there aren't any vhosts) takes over, no matter what it's named.

Now, the rest of the URL given consists of two parts -- the path, /, and a GET parameter (the ?PHPSESSID... bit).

Now, the path / should be present on pretty much every web server out there. In most cases, it maps to something like index.html or perhaps an index.php script, though you can override any of this of course.

If it maps to a static HTML file, absolutely nothing unusual happens -- the contents of the file are returned, and that's that, the parameter is simply ignored. (Assuming you don't have certain advanced configuration directives set, and you almost certainly don't.)

On the other hand, if it's a script of some sort, that PHPSESSID variable will get passed to the script. If the script actually uses that variable (in this particular case, only PHP scripts using PHP's built-in session handling are likely to), its behavior will depend on the contents.

In all likelihood, however, even if your / happens to map to a PHP script using sessions, nothing remarkable will happen. The session ID probably won't exist anyway, and will either be ignored, or the script will show an error.

In the unlikely case that the session ID does exist, well, the attacker could conceivably hijack someone else's session. That would be bad, but it's not really a security hole in itself -- the hole would be wherever the attacker got the session ID information from (sniffing a wireless network is a good candidate if you're not using HTTPS). They wouldn't actually be able to do anything that the user whose session it originally was couldn't do.

Edit: Additionally, the '%5C' inside the SESSIONID maps to a backslash character. This seems to be a test for directory traversal attacks on windows hosts.

| improve this answer | |
  • I've had similar requests 404, 500, 403, and 20x on my servers running nginx or lighttpd, and after sending the IPs/source hosts to a cyber-analysis firm, it was confirmed it was attempts to exploit holes in the server among other things. Similar requests as the one that was specified by the OP, different hosts. Are you saying that they should be entirely disregarded? Because if they are truly concerned, they can block the host(s) in iptables. – Thomas Ward Jul 11 '11 at 12:59
  • @The Evil Phoenix: The host in the URL isn't where the request is coming from, it's just the equivalent of a 'Host:' header. The actual client IP address, which OP obscured, could be blocked with iptables if he wished, but unless he's getting flooded with requests, it really doesn't matter. Just because someone tries to exploit a hole doesn't mean a hole is present. I administer numerous (Linux) servers which record many strange requests intended to exploit holes every day -- most of them Windows/IIS holes! It's just blind scanning. If it doesn't get a hit, it moves on to the next IP address. – Nicholas Knight Jul 11 '11 at 13:21
  • @The Evil Phoenix: Further, if a hole were present, blocking the IP address that exploited it wouldn't do one bit of good. Your server would already be compromised, and would still be vulnerable to the same attack from other sources -- and there are plenty of sources. Every zombie system out there (and there are many millions) is a potential source of malicious scans. – Nicholas Knight Jul 11 '11 at 13:23
  • Nice and thorough explanation.... Thanks a lot. I obscured the offending IP in case he/she ip-ego-surfes :). My / maps to apache's default "It works" (I know, how unprofessional... but I said it was personal, lol). So I assume I must do nothing unless the same IP becomes a pain, in which case I will block it out with iptables (or even hosts.deny?). Thanks again. – luri Jul 11 '11 at 18:06
1

I've got this allrequestsallowed logged on an ip that's used as A record for all our parking-domains.

My shot is that this hostname is used in combination with the "attacker's" local hostfile pointing to the target host.

The actual webserver at 31.44.184.250 is just to handle external requests.

My opinion: total harmless. Don't see any value added use for it except for stuff you can do with any other fake domain name in your hostfile.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.