RE: Unicode Attack

[Information Security <InformationSecurity () federatedinv com>]

> > Web log entries:
> >
> > 2002-11-12 13:00:37 210.201.100.253 - x.x.x.17 80 GET
> > /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321
> > 31 HTTP/1.1 63.241.137.233
> > Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - -
>
> That server should not be vulnerable to the Unicode URL encoding 
> directory traversal trick seen above.  It seems you have a "safe" box 
> and are getting all worried because your IDS saw something that 
> ...

Whoooooooooooaaaaa...there's no question that this server IS vulnerable and
WAS successfully "recon"d, Jeremy provided all the evidence you need with
the single log entry.  IIS logs like this are very rich with information.
Take a closer look at the log entry
/scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321
And break it down into parts:

/scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe
They asked for access to cmd.exe

/c+dir 
They wanted cmd.exe to do a "dir" command and return immediately (no
interaction)

200
The server returned an HTTP "200" OK to what they wanted.  RED FLAG!!  No
doubt about it, someone successfully sent arguments to cmd.exe and it
returned data.  I can't imagine any scenario where you can get a 200 and NOT
have control of cmd.exe (unless it's a honeypot cmd.exe).

1849 
This is the win32 return code, and a 0 here would indicates success; quite
honestly, I'm not sure what the 1849 is from (can anyone help with this
one?)...It might be from the "dir" command, or it might represent the
typical error "this page did not return a properly formatted header.  The
headers it did return are..."

321 31
This helps to confirm: you can see that 321 bytes were sent back to the
client in response to the 31 byte request.

There's some other good info we can get from this log entry:

Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
means that whatever they're using for recon is probably using the built-in
IE object and not crafting the http stream.  Perl and command line tools
usually don't include the "User-Agent" in the http header.  Assuming they're
not using a sophisticated tool that inserts a bogus user agent, it looks
like they're running an older version of Windows 2000, possibly unpatched.

 - -
Don't forget the blank entries, they're just as important.  The first one is
the cookie--if Jeremy's site uses cookies to track user sessions (the
typical IIS setup), we know that this is the first time the user has been
here recently (again, assuming they're typing the URL into IE).  The second
blank is for the http referrer--in this case, it's blank, it doesn't give
you anything, but when it's not blank for an attack, it might help you find
an attacker that's hiding behind a proxy.



It's obvious thorugh testing that IIS does a single URL decode of the string
before logging it, and it makes perfect sense to do that.  But I'm still
interested in knowing whether SNORT does--I wouldn't expect it to, and maybe
it's not SNORT itself, but one of the actual presentations or storage
mechanisms.



----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com