Re: Unicode Attack

[Nick FitzGerald <nick () virus-l demon co uk>]

"Jeremy Junginger" <jjunginger () usbestcrm com> 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.  ...

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
> 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 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) - -
>
> 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) - -
>
> 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 
"[...]/scripts/..\..\..\winnt/system32.cmd.exe?/c+dir"

> 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 uni.pl, 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.)


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