Joined: 28 Oct 2002 Posts: 16777215 Location: Chicago, IL US
Posted: Mon Jul 14, 2003 11:26 pm Post subject:
Two more responses from incidents.org.
Both of these say pretty much the same thing. Its regarding IIS and virtual hosts. The first post makes sense since this attack is directed at an IIS server. The more I look at it the more I like it
Second one just enforces the theory of the first.
Okay. I'm going to make a guess here.
The GET string, excerpted below, indicates that it is using HTTP/1.1:
(Pretty nice URL by the way.)
In order to make a valid HTTP/1.1 request, you have to specify a host
(I think the proper terminology is 'host header') for the request. I'm
guessing that whoever devised this tool decided to just throw in
'www.google.com' as a host header. Under IIS, if you specify a host
that is not configured, it falls back on the first virtual host that is
configured for the IP. So by specifying 'www.google.com', they pretty
much guarantee that they will fall to the first host -- and on a
IIS install, this will be the default web site which lives under
So this is my armchair one minute guess-analysis. Hope it helps
A web server might be host to multiple sites, and the Host: header
on the request allows the client to specify which one he wants. I
expect single-site servers just ignore it, and in any case it's not
relevant to the request since directory traversal attempts to break
out of the site to the host machine.
I also agree that the host field being set to "www.google.com" is just filler to make the HTTP GET request valid and that the requested URL (GET /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts\script.exe HTTP/1.1) is definitely a known IIS-specific Directory Transversal attack.
This request is attempting to use a Unicode vulnerability to copy the Windows NT command processor (cmd.exe) to the path c:\inetpub\scripts directory as filename scripts.exe. This will mean that the file will be publicly accessible via http://<hostname or IP>/scripts/scripts.exe and its presence there will allow the execution of arbitrary system commands and permit directory transversals, thus giving the attacker “free reign over the machine.”
Based on the response I saw in the traffic capture, the server denied the request because the requested file was not found (HTTP/1.1 404 Not Found). This makes sense because the system appears to be running Apache web server (Server: Apache/1.3.27 (Unix)), and it would not have the directory path the URL was looking for, even if it was Apache on Windows.
This type of scan/attack in not uncommon these days, unfortunately…
All times are GMT + 2 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum