On Mon, Jul 29, 2002 at 03:38:27PM -0700, Microsoft Security Response Center wrote: > > Hi All - > > We'd like to set the record straight as regards the advisory > published today by the XWT Foundation. > address the issue via a service pack. Accordingly, a fix has been > included in IE 6 Service Pack 1, which is due to be released shortly. What about IE 5.x? > Among the barriers that an attacker would face in attempting to > exploit the vulnerability are the following: > * It would require that the attacker host a DNS server, a fact that > would be traceable. Not host a DNS server, but be able to publish DNS records. I know of at least one DNS provider who hosts zone files for free, with the only accountability being an email address (i.e., no acountability). Sure, the attacker also needs to register a domain name, but how traceable is that, really? Hijack an existing (unused?) domain & the attacker is set... > * The attacker would need detailed information about the internals of > the user's network, such as intranet server names. The attacker needs no server names, only IP addresses, and the IANA reserved address space reduces the number of likely targets. Is an IP address in 192.168.0.0 "detailed" information? I wouldn't say so. > * If the intranet site were an HTTPS: site, a dialog would warn the > user that the name on the site's certificate did not match the domain > name. Aw, c'mon. How many companies use https for internal servers? (Ironically, MSFT's integration of IPSEC in recent versions of Windows has likely convinced some enterprises to use IPSEC as a global solution to the longstanding problem of cleartext/unauthenticated network traffic. Such enterprises are less likely to bother with SSL/TLS, and more likely to be vulnerable to this browser-based attack. Go figure.) > * If the intranet site used cookie-based authentication, the attack > would fail because the attacker's site would be unable to > authenticate on behalf of the user Another red herring. How many unlikely "safe" scenarios do you want to discuss? The reality is that typical "intranet" setups don't use https and do make available a good bit of information without *any* authentication. In many (most?) cases it's believed that the intranet can only be accessed from behind the firewall, so authentication is not needed. This attack scenario shreds that assumption. > * The attack would not work against web servers configured to support > multiple host headers, with the exception of any content served up at > the "default" site. Again, an unlikely "safe" scenario. Internal servers are *far* less likely to be configured for multiple host-by-name servers than external/public servers. Also I note that Michael Howard's checklist for securing IIS 5.0 (Microsoft's http server offering) makes no mention of tweaking the virtual host configuration for security reasons as you (now) suggest. -Peter -- Peter Watkins - peterw@tux.org - peterw@usa.net - http://www.tux.org/~peterw/ Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692
Attachment:
pgp00179.pgp
Description: PGP signature
