RE: New vulnerability in IIS4.0/5.0

From: Microsoft Security Response Center (secure@microsoft.com)
Date: 09/20/01 

Subject: RE: New vulnerability in IIS4.0/5.0
Date: Wed, 19 Sep 2001 19:12:16 -0700
Message-ID: <C10F7F33B880B248BCC47DB44673884703C42BA9@red-msg-07.redmond.corp.microsoft.com>
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "ALife // BERG" <buginfo@inbox.ru>, <Bugtraq@securityfocus.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-----

Relevant Pages

  • Re: Starting a Pen-Testing Career
    ... Perhaps my perceptions of the business are a bit naive, ... Buinsesses don't care about security and vulnerabilty and exposure. ... How else would they be able to provide such a report in isolation - ... written vulnerability scanner' to produce reports. ...
    (alt.computer.security)
  • RE: MBSA scanner
    ... the license must state clearly what is restricted. ... that referred to the nature of the vulnerability or exploit itself would be ... > all the suggestions on how to fix a vulnerability that a report might ... > nothing preventing Nessus, Internet Scanner, Cybercop, Retina, ...
    (Pen-Test)
  • Re: MBSA scanner
    ... all the suggestions on how to fix a vulnerability that a report might ... > Nessus is another example; the GPL has the same restrictions on distribution ... And also read the GPL FAQ: ...
    (Pen-Test)
  • RE: Netstumbling
    ... to their network, ... If I find a vulnerability and expose it to access ... >> Are your vulnerability scans producing just another report? ... > Manage the entire remediation process with StillSecure VAM's ...
    (Pen-Test)
  • D-Link Access Point DWL-900AP+ TFTP Vulnerability
    ... ETHEREANET-NCC Security Report EN-NCC-20021014-04 ... D-Link Access Point DWL-900AP+ TFTP Vulnerability ... the device features also an embedded TFTP ... receive a binary image of the device configuration which contains, ...
    (Bugtraq)