RE: Unicode Attack

From: Information Security <InformationSecurity(at)federatedinv.com>
Date: Wed Nov 13 2002 - 13:27:18 EST

> 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

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 Received on Thu Nov 14 04:17:37 2002