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
