-----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-----
PGPexch.htm.asc
