RE: New vulnerability in IIS4.0/5.0

["Microsoft Security Response Center" <secure () microsoft com>]

-----BEGIN PGP SIGNED MESSAGE-----

Hi All -

We've investigated this report, but it appears to be a false alarm. 
We have been unable to reproduce any of the claims on IIS 4.0 or 5.0
with the latest cumulative patch applied
(http://www.microsoft.com/technet/security/bulletin/MS01-044.asp), or
on the latest beta version of IIS 5.1.  The results from other
security organizations are the same -- none report any ability to
reproduce the claims in the report.

This is a good example of the wrong way to handle a security
vulnerability report.  We didn't receive this report until mid-day
today, well after it had been published on BugTraq and we'd already
begun an investigation.  There is simply no rationale for sending a
vulnerability report to the world first, and to the vendor -- the
only party that could build a patch -- last.  

If this had been a bona fide vulnerability, the irresponsible way it
was reported would have put a weapon into malicious users' hands,
thereby putting users needlessly at risk.  Even though the report
turned out to be false, there still was a cost to the user community.
 Because the authors chose to create an emergency, Microsoft and
other organizations investigating the Nimda worm had to divert
resources into checking the new report.  This cost all of us valuable
time, and hindered our efforts to help users defend their systems
against Nimda.

We established the Microsoft Security Response Center to make it easy
for people to report potential security vulnerabilities to us.  We
monitor the secure () microsoft com email address seven days a week, 365
days a year, and we investigate every report we receive.  Sending a
report to the vendor first makes sense, both from the perspective of
protecting users and ensuring that the researcher's name is only
associated with valid, reproducible reports.

Regards,

Scott Culp
Microsoft Security Response Center
Microsoft Corporation



  




- -----Original Message-----
From: ALife // BERG [mailto:buginfo () inbox ru] 
Sent: Wednesday, September 19, 2001 2:38 AM
To: Bugtraq () securityfocus com
Subject: New vulnerability in IIS4.0/5.0


- -----[ Bright Eyes Research Group | Advisory # be00001e
]-----------------

             Remote users can execute any command on several
               IIS 4.0 and 5.0 systems by using UTF codes

- -------------------------------------[ security.instock.ru
]--------------

Topic:              Remote users can execute any command on several
                    IIS 4.0 and 5.0 systems by using UTF codes

Announced:          2001-09-19
Credits:            ALife 
Affects:            Microsoft IIS 4.0/5.0

- ----------------------------------------------------------------------
- ----

- ---[ Description

     For  example, target has a virtual executable directory (e.g.
"scripts") that is located on the same driver of Windows system.
Submit request like this:

http://target/scripts/..%u005c..%u005cwinnt/system32/cmd.exe?/c+dir+c:
\

Directory list of C:\ will be revealed.

Of course, same effect can be achieved by this kind of  processing to
 '/'  and  '.'. For  example:  "..%u002f", ".%u002e/", "..%u00255c",
"..%u0025%u005c" ...

Note: Attacker can run commands of IUSR_machinename account privilege
      only.

     This is where things go wrong in IIS 4.0 and 5.0, IIS  first
scans the given url for ../  and  ..\ and  for  the normal unicode 
of  these strings, if those  are  found, the  string  is  rejected,
if these  are not found, the string will be decoded and interpreted.
Since the filter does NOT check  for the huge amount of overlong
unicode representations of ../ and ..\ the filter is bypassed and the
 directory  traversalling routine is invoked.

- ---[ Workarounds

     1. Delete the  executable virtual directory like /scripts etc.
     2. If executable  virtual directory is  needed, we suggest  you
to
        assign a separate local driver for it.
     3. Move all command-line utilities to another directory that
could
        be used  by an  attacker, and  forbid GUEST  group access
those
        utilities.

- ---[ Vendor Status

     2001.09.19  We informed Microsoft of this vulnerability.

- ---[ Additional Information

 [1] RFC 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode.
     RFC 2152
 [2] RFC 2044 UTF-8, a transformation format of Unicode and ISO
10646.
     RFC 2279
 [3] RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8
String
              Representation of Distinguished Names.

- ---[ DISCLAIMS

THE INFORMATION PROVIDED IS RELEASED BY BRIGHT EYES RESEARCH GROUP
(BERG) "AS IS" WITHOUT  WARRANTY  OF ANY KIND. BERG  DISCLAIMS  ALL 
WARRANTIES, EITHER EXPRESS OR IMPLIED, EXCEPT FOR  THE WARRANTIES OF
MERCHANTABILITY. IN NO EVENTSHALL BERG BE LIABLE  FOR  ANY  DAMAGES 
WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL,
LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF BERG HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. DISTRIBUTION  OR
REPRODUTION OF THE INFORMATION IS PROVIDED THAT THE ADVISORY IS NOT
MODIFIED IN ANY WAY.

- -------------------------------------[ security.instock.ru
]-------------- -----[ Bright Eyes Research Group | Advisory #
be00001e ]-----------------


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQEVAwUBO6lQf40ZSRQxA/UrAQHRawgAmBjseQTRxTQx0lW4T0kf5n3HPmwLb54A
EcJzMT3O/qEDakQKv9mE1yGrxWMUrhlGNXg1cT++Vi3d+E6FqIw5kMe7wtJslf+L
AojWIzSsve9epkanuSi1/JFAhoccAIOz2e6pj9JxmVIUdAWvHsoQ1mo6P8+mH3HX
69xczuemzrUfGEeV43Btul9NjQGa1hFsMhJR2LsOVoC6z8dPe2toiM4WcwE81hvS
mlx1imWFmYddxzdvav3ZjgkpdnKeIEo4s91okbmElq2qQgFGl1jKxCnzIerd8nNk
vn/X3JCHxko6EtJyW2dXPt1bnYxaWN0gxfUOiGwvGqTxQys9Rck0WA==
=Ovie
-----END PGP SIGNATURE-----

Attachment: PGPexch.htm.asc
Description: PGPexch.htm.asc