RE: XWT Foundation Advisory

["Jason Coombs" <jasonc () science org>]

Aloha, Thor.

> I still quite fail to see the relevance to firewalls, as nothing is
> circumvented - the administrator has explicitly allowed HTTP traffic on
> (most often) port 80.

Outbound HTTP traffic is allowed by the firewall administrator, yes, but
this exploit has the effect of allowing the attacker to send *INBOUND* HTTP
requests to any HTTP server inside the firewalled network from a remote
location outside the firewall. The HTTP servers behind the firewall are
otherwise normally protected from remote access by the existence of the
firewall. The HTTP servers that are at-risk are not the ones that service
inbound requests from outside the network but rather those HTTP servers that
are supposed to be accessible only to users on the LAN.

The remote attacker uses the browser as a JavaScript-based HTTP "proxy by
force".

The two most important conditions for vulnerability are:

1) The HTTP server (located on the internal network or anywhere else that is
accessible to the client browser) must be configured to respond to
HTTP/1.0-style requests that do not supply a Host: header. Even though the
browser sends Host: header along with its HTTP/1.1-compliant request, the
"default" Web site explicitly ignores the Host: header in order to maintain
compatibility with HTTP/1.0 clients.

2) The HTTP server must not require manual authentication or a cookie as a
condition for access to the requested URL. In some scenarios the attacker
may be able to compel the victim browser to send its cached HTTP Basic
Authentication credentials along with the request in order to authenticate
automatically with realms that same browser has previously authenticated
with through user-supplied login credentials.

The reason that a Host: header defeats the JavaScript-based proxy by force
is that the client thinks its sending the request to a host inside the
remote DNS domain that triggered the exploit. The Host: header contains that
remote (malicious) DNS domain, and the Web server in question (on the
internal network, for example) won't have that Host: header configured.

Sincerely,

Jason Coombs
jasonc () science org

-----Original Message-----
From: Thor Larholm [mailto:thor () pivx com]
Sent: Monday, July 29, 2002 11:51 PM
To: Microsoft Security Response Center; bugtraq () securityfocus com
Subject: RE: XWT Foundation Advisory


> From: Microsoft Security Response Center [mailto:secure () microsoft com]
<snip mitigating factors>

I for one am in agreement on this issue, especially with regards to
"Default" sites on e.g. IIS - it is very uncommon for anyone to serve
content from the "Default" site (without checking the Host header) these
days.

That's not to say that sites like support.microsoft.com does not do this as
it seems to operate on the "Default" site, neglecting the most important
mitigating factor.

I still quite fail to see the relevance to firewalls, as nothing is
circumvented - the administrator has explicitly allowed HTTP traffic on
(most often) port 80.

Out of plain curiosity, how is this fixed in IE6SP1 - as the Netscape team
fixed it by demanding both sites to set document.domain, regardless if one
is the parent?



Regards
Thor Larholm, Security Researcher
PivX Solutions, LLC

Are You Secure?
http://www.PivX.com