Re: XWT Foundation Advisory

[Peter Watkins <peterw () usa net>]

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: _bin
Description: