-----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 secureat_private 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:buginfoat_private] Sent: Wednesday, September 19, 2001 2:38 AM To: Bugtraqat_private 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-----
This archive was generated by hypermail 2b30 : Thu Sep 20 2001 - 11:31:30 PDT