Re: Unicode Attack

From: Nick FitzGerald (
Date: 11/14/02

Date: Thu, 14 Nov 2002 14:35:18 +1300
From: Nick FitzGerald <>

"Jeremy Junginger" <> wrote:

> It's time again to ask the group for some assistance with interpretation
> of web logs and snort alerts. There was some funny activity on the web
> farm. I noticed a couple "ATTACK RESPONSES-http dir listing" attacks on
> some of our web servers, queueing me in to the fact that the servers in
> question were not patched against a Unicode-type vulnerability. ...


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
> the offending IP, and tracked it back to a broadband home connection. I
> think with reasonable certainty that the attack was not spoofed (because
> of the nature of TCP and the fact that he received a response from the
> web server); however, I cannot rule out the possibility of the host
> being compromised. ...

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
> access immediately, ...

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
> logs are continuous, so I am assuming that they are intact, though they
> may be suspect. There are no lapses in time, and the logs appear to be
> fairly contiguous. I also noticed that the attack was scripted, as
> there were many WEB-IIS SAM RETRIEVAL attempts interspersed with the
> Unicode strings, all happening in less than 10 seconds. The log entries
> of the first server are below.
> Web log entries:
> 2002-11-12 13:00:37 - x.x.x.17 80 GET
> /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321
> 31 HTTP/1.1
> Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - -
> 2002-11-12 13:00:37 - x.x.x.17 80 GET
> /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321
> 31 HTTP/1.1
> Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - -
> 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
> done is running URLSCAN and IISLOCKDOWN. Obviously, these will be my
> steps for patching the servers, but I would like to ask for some
> assistance with replicating the attack.

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
> (correct me if I'm wrong)
> http://x.x.x.17/scripts/..%5c..%5c..%5cwinnt/system32.cmd.exe?/c+dir
> (possibly with a c:\ at the end).

The "%5c" strings decode to "\", so the server was really considering

> When running this URL against the server, it produces a 404 error on the
> server rather than listing the drive contents. ...

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

> ... The snort logs
> (Snort/MySQL/PHP/ACID/Apache) indicate that the URL was
> http://x.x.x.17/scripts/..%5c..%5c..%5cwinnt/system32.cmd.exe?/c+dir .

Which is what we'd expect given the above.

> I guess my question is three-fold:
> 1) Does the IIS server "decode" the string before logging it to the web
> logs?

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
> possible to write a perl script that could check for all possible
> Unicode variants on a given web server to test the effectiveness of the
> URLSCAN and IISLOCKDOWN utilities (pre-change/post-change pen-test)? I
> have some "shell" programs like, but am a little confused about
> how to generate all of the possible combinations.

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


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:

Relevant Pages

  • Unicode Attack
    ... I noticed a couple "ATTACK RESPONSES-http dir listing" attacks on ... and began to analyze the logs more closely. ... Unicode strings, all happening in less than 10 seconds. ... of the first server are below. ...
  • RE: Unicode Attack (FOLLOW UP)
    ... The attacking host at is a Windows 2000 Chinese Server, ... Subject: Unicode Attack ... and began to analyze the logs more closely. ... Unicode strings, all happening in less than 10 seconds. ...
  • RE: isa 2004 & external website access issue
    ... emailed the logs to you as requested. ... each web server has its own public IP ... > headers in ISA Server ... > 'Microsoft Firewall' service. ...
  • RE: Exchange Server
    ... I researched your logs and found the MSExchangeTransport events 4006, 969, ... Right click Default SMTP Virtual Server and select Properties. ... Microsoft CSS Online Newsgroup Support ... This newsgroup only focuses on SBS technical issues. ...
  • RE: OWA 2003 with ISA 2004
    ... OWA externally. ... i can login by any user. ... 825763 How to configure Internet access in Windows Small Business Server ... g. Reproduce this issue and send the logs to me. ...