Re: Unicode Attack

From: Nick FitzGerald <nick(at)virus-l.demon.co.uk>
Date: Wed Nov 13 2002 - 20:35:18 EST

"Jeremy Junginger" <jjunginger@usbestcrm.com> wrote:

> It's time again to ask the group for some assistance with interpretation

Huh?

Your Snort logs will include everything "odd" (as defined by the Snort ruleset) that goes past your Snort sensors. Nothing seen in such incoming traffic means anything about your machines being vulnerable (well, nothing of the sort you report here means your machines are vulnerable). An "attack" as you call it ("probe" might be a little less emotive and thus help sort things out) does not mean you have anything attackable. The same requests directed to an Apache clearly would not be "an attack", as it is not if directed to a patched IIS box. Snort (or any other IDS) with the same detection rules monitoring such traffic though will flag it regardless that the target is an IIS or Apache box.

> ... I found

Indeed. The odds are quite high that it will be, and even if it's not you'd be lucky to find the ISP particularly inclined to help...

> ... Knowing this, I reported it to our ISP and blocked

Blocked the whole net-block or just the IP? If the former, you _may_ be unduly penalizing all those other subscribers to that ISP (it's a political call, and a business case one of the server in question is "commercial"). If the latter, are you sure it is on a static IP?

> ... and began to analyze the logs more closely. The web

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 happens all the time -- random scanning for unpatched IIS servers. I'm on a dynamically assigned dial-up in New Zealand and typically get 1 - 4 such probes per day (when I have my packet catcher running, which reminds me I should restart it...).

> INTERESTING NOTE: The web logs indicate that the URL Requested was

The "%5c" strings decode to "\", so the server was really considering "[...]/scripts/..\..\..\winnt/system32.cmd.exe?/c+dir"

> When running this URL against the server, it produces a 404 error on the

As it should because you do not have a version of IIS vulnerable to the Unicode decoding directory traversalflaw.

> ... The snort logs

Which is what we'd expect given the above.

> I guess my question is three-fold:

Well, none of your snippets reputedly from the logs suggests it decodes the Unicode, as it is still there in the log entries...

> 2) Does the Snort IDS "decode" the string before logging it to MySQL?

Also, apparently not.

> 3) Since there are few (if any) thorough Unicode scanners, is it

This question does not really make sense. There are only a few Unicode vulnerability variants, but what is really meant by that and what a number of people produce when writing a "scanner" for them are two quite different things... The thing you have to realize is that there are a few different basic forms of Unicode encoding and each (?) of them has been shown to be exploitable in some or other version or patch-level of IIS. To test your version of IIS, you should only need to know each of those Unicode forms and the location on your servers of a "useful" program to produce some test output that will be sent back to the requesting machine if the decode bypasses the security checks and thus the test app is executed. Armed with that information you can write a trivial script with one test of each Unicode encoding method.

However, what many of the "Unicode vulnerability scanners" provide is a long list of URLs to various programs commonly available in readily guessable locations and using one or more of the Unicode encodings. These can incorrectly clear a (somewhat unusually configured) IIS box simply because they fail to include a suitable path to a suitable "test" application. (The lists of URLs in such scanners are often compiled from web server logs and exploit scanners known to be used by script kiddies and others.)

Regards,

Nick FitzGerald

---

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 11:45:17 2002