RE: Unicode Attack

[Information Security <InformationSecurity () federatedinv com>]

> 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) - -

It's been my experience that the actual URL probably sent to your server was
/scripts/..%255c../..%255c../..%255cwinnt/system32/cmd.exe?/c+dir.  If you
type that into your browser, you'll probably have success.

You would see this entry on any proxy device in front of the web server.
IIS
and Snort (IMHO) appropriately run a single URL decode on the request, which
pretty much follows URI RFC specs, so that's not really a bug.

Something else that might be interesting to note is the actual signature.
I've
seen a number of different signatures for the automated unicode scans, and
it seems that once an attacker settles on a way in, they keep using the 
same sequence until they've backdoored your system.  So when you unravel
everything that happened, group your log entries across all your servers
together by the ones with the "..%5c../..%5c../..%5c" attack string, and
maybe you'll be able to see how he walked across your environment.

> This is an IIS 5.0/Win2k Server with SP2 and Latest Hotfixes per
> HFNETCHECK, which I thought would preclude this server from being
> vulnerable to a Unicode-type attack.  The only thing that has not been

I've never understood exactly how hfnetcheck works, but you might want
to check for things like uninstall/reinstall of IIS and restoration of
files from backup.  This might leave enough residue to fool hfnetcheck,
but actually leave your server exposed.


----------------------------------------------------------------------------
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