RE: XWT Foundation Advisory: Firewall circumvention possible with all browsers

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

Aloha Adam,

I'm writing to you because I simply can't believe that Microsoft would
misunderstand the XWT Foundation Security Advisory vulnerability of July 29,
2002 to the point that they don't plan to immediately release hotfixes for
all JavaScript-enabled Microsoft products. Patching IE 6 through a service
pack as they propose does nothing to remediate past browser deployments, and
that's the point of your advisory.

All JavaScript-enabled products are most likely vulnerable to this bug.

Further, I'm astonished that Microsoft Security Response Center would
publicly mis-characterize this vulnerability as follows:

> * It could only be exploited if the user clicked a link within an
> email - it could not be exploited without user interaction.

Using Microsoft Outlook 2000 (version 9.0.0.2711) and IE 6 (version
6.0.2600.0000) the following javascript (shown without brackets) works as
expected within an e-mail message with a "Content-Type: text/html" to
automatically open a new browser window and launch the exploit you describe
(if jasoncoombs.com in fact hosted the exploit):

script language="javascript1.1"
window.open("http://jasoncoombs.com";);
/script

The user does not have to click a link in an e-mail message in order to be
vulnerable, they need only to read an HTML e-mail message. This is a
well-known vulnerability in HTML e-mail. Other exploits are possible to
compel a user's browser to visit a malicious URL without unsafe user
interaction.

Microsoft apparently does not understand the scope and technical cause of
this bug. I would encourage you to continue your dialog with them and help
them understand the vulnerability more accurately.

Hotfixes DO need to be released to patch this vulnerability. It does not
require the following, as Microsoft asserted when it downplayed the severity
of the bug:

> * The attacker would need detailed information about the internals of
> the user's network, such as intranet server names.

As you point out in "Moving beyond a single server" the exploit can be used
to scan an internal network, and a related or subsequent exploit would then
be possible to deliver content to the attacker from the servers that are
found by the scan.

Microsoft should reconsider its policy of attempting to downplay the
severity of security vulnerabilities when responding to those who discover
and report them in good faith. Especially if they are going to approach the
issue as though users who have slightly-out-of-date software (such as my
Outlook 2000 example cited above) don't exist or aren't worth protecting.

The recommended solution for all Web servers to eliminate default Web sites
and switch to HTTP/1.1 host headers as an access requirement is a good
solution and it solves the immediate problem, albeit at the expense of
compatibility with HTTP/1.0 clients. The vulnerability you found
demonstrates clearly that HTTP/1.0 without SSL is flawed from a security
viewpoint for yet another reason. This should be viewed as the straw that
breaks the camel's back: deprecate HTTP/1.0.

Microsoft should take advantage of this opportunity to educate and inform
customers and release a security advisory of their own that reinforces
awareness of the security risk of HTTP/1.0 due to its lack of host header
and urge all Microsoft customers to immediately remove production Web sites
(both Internet-based AND intranet-based Web sites) from the default Web site
mapping in Internet Information Services and configure host header settings
instead. Microsoft is missing an important opportunity to remediate security
flaws in HTTP/1.0 by downplaying the severity of this vulnerability.

The only explanation possible is that Microsoft must not understand the bug.
Please try again to communicate it to them -- Microsoft has no reason to be
offended by your refusal to include their Vendor Response because
Microsoft's Vendor Response was technically incorrect. It would have done
harm to the public's understanding of the vulnerability if you had published
it as part of your advisory, and I commend you for NOT doing so in spite of
the risk to your reputation.

If you need help explaining your reason for not including Microsoft's Vendor
Response in your vulnerability announcement, I'd be happy to assist you as a
third-party who understands and agrees with your decision. My first reaction
to Microsoft's critical response of your security advisory was to be
disappointed that you had not included their Vendor Response. It was only
through further effort and research into the vulnerability you describe that
I was able to conclude that you had done the right thing.

As the Responsible Vulnerability Disclosure Process detailed in the
Christey/Wysopal draft evolves, there will no doubt be further debate on
this subject. The draft, located at:

http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0
0.txt

includes a section 3.5.3 on involving a coordinator if the vendor disagrees
with the nature of the bug you are reporting:

"3.5.3 Coordinator Responsibilities
1) The Coordinator MUST attempt to resolve any conflicts or technical
   disagreements that arise between the Reporter and the Vendor."

In this case, because there is an apparent misunderstanding on the part of
Microsoft with respect to the nature of the bug, you should have involved a
coordinator before public disclosure if your intent was to follow the
Responsible Vulnerability Disclosure Process to the letter. Dave Ahmad was
apparently your coordinator, although you don't specify in your timeline
whether or not Dave had any contact with Microsoft pursuant to 3.5.3 acting
in the role of Coordinator. Microsoft doesn't disagree that there is a bug,
but in the future you should infer that they don't fully comprehend it based
on the inadequacy of their Vendor Response. They are, after all, smart
people too.

Sincerely,

Jason Coombs
jasonc () science org

-----Original Message-----
From: Microsoft Security Response Center [mailto:secure () microsoft com]
Sent: Monday, July 29, 2002 12:38 PM
To: bugtraq () securityfocus com
Cc: Microsoft Security Response Center
Subject: RE: XWT Foundation Advisory

-----BEGIN PGP SIGNED MESSAGE-----

Hi All -

We'd like to set the record straight as regards the advisory
published today by the XWT Foundation.  Microsoft thoroughly
investigated the issue described in the advisory, and discussed our
findings in detail with the advisory's author.  When the XWT
Foundation solicited a response from Microsoft to include in the
advisory, we prepared one that accurately reports the risk the issue
poses and the solution we developed.  It's a pity the XWT Foundation
chose not to honor its promise to include our response.  For the
record, this is the vendor response we provided:

=====================================================================
Microsoft has investigated the issue discussed in the report, and
agrees that the issue is bona fide from a technical standpoint.
However, because of the difficulties associated with exploiting it
(discussed below), Microsoft believes it is most appropriate to
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.

Among the barriers that an attacker would face in attempting to
exploit the vulnerability are the following:
* It could only be exploited if the user clicked a link within an
email - it could not be exploited without user interaction.
* It would require that the attacker host a DNS server, a fact that
would be traceable.
* The attacker would need detailed information about the internals of
the user's network, such as intranet server names.
* 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.
* 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
* 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.
======================================================================
=

Microsoft stands by its assessment of the issue.  Regards,

Microsoft Security Response Center


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQEVAwUBPUXCqo0ZSRQxA/UrAQEztAf/Y3qYCwMDTBSqZR0UrXTj4kA3m6bGWa2l
6LlGtHdKlwtSxWvwdXjsapSbfdQhMthV2+onjWi2lGDS6eqzvKbqf2kzVBBf6mU7
p8KxvgcpWGz3LLqQ1YtmLM7SuGgHayUq5ny6AlTMoYI0ZUMD8R9rVyRSM+CTMkQx
irskV/2HbqmrA4K1BdTV59t6n96lA955KaQMfKChxjk/YmQuBb/77DO+UABEWpdE
N3Sq2OgZOZxElLdBP3Yq/+sei6ixxH3g0UoAH+nOTTvYZDaizMWOPDnhVcwyx6mC
R0lXp70xSB8OvUo89e27eLXz/FYmNBpv54b5gKGJ6HTzxl0YjjeolQ==
=Uzha
-----END PGP SIGNATURE-----

-----Original Message-----
From: Adam Megacz [mailto:adam () megacz com]
Sent: Monday, July 29, 2002 2:06 PM
To: jasonc () science org
Subject: Re: XWT Foundation Advisory: Firewall circumvention possible
with all browsers



Whoops! You're right. I'll correct that on the web page.

  - a

"Jason Coombs" <jasonc () science org> writes:
> Question --
>
> Shouldn't the following read: sets document.domain to "bar.baz.com"
> not "baz.bar.com" ? baz.bar.com isn't a parent domain of foo.bar.baz.com
> as stated, but bar.baz.com would be, and it would be consistent with the
> intent of your exploit description -- to resolve that 10. address.
>
> Sincerely,
>
> Jason Coombs
> jasonc () science org
>
> >  3) A JavaScript on said page sets document.domain to "baz.bar.com"
> >     (this is valid since baz.bar.com is a parent domain of
> >     foo.bar.baz.com). See [1]. Also note that this step is not
> >     strictly necessary, but substantially improves the performance of
> >     the exploit and the ease of implementation.
>
>
> -----Original Message-----
> From: adam () megacz com [mailto:adam () megacz com]On Behalf Of Adam Megacz
> Sent: Monday, July 29, 2002 7:57 AM
> To: bugtraq () securityfocus com
> Subject: XWT Foundation Advisory: Firewall circumvention possible with
> all browsers
============================================================================
> ==
> XWT Foundation Security Advisory
>
> Adam Megacz <adam () xwt org>
> http://www.xwt.org/sop.txt
> 29-Jul-2002 [Public Release]
____________________________________________________________________________
> __
> Abstract
>
> The following exploit constitutes a security flaw in JavaScript's
> "Same Origin Policy" (SOP) [1]. Please note that this is *not* the
> IE-specific flaw reported in Februrary [2].
>
> The exploit allows an attacker to use any JavaScript-enabled web
> browser behind a firewall to retrive content from (HTTP GET) and
> interact with (HTTP <form/> POST) any HTTP server behind the
> firewall. If the client in use is Microsoft Internet Explorer 5.0+,
> Mozilla, or Netscape 6.2+, the attacker can also make calls to SOAP or
> XML-RPC web services deployed behind the firewall.
____________________________________________________________________________
> __
> Status
>
> This advisory is being released in accordance with the Responsible
> Disclosure Draft RFC [3]. See the last section of this advisory for a
> timeline. Vendors were notified on 28-Jun-2002, 30 days prior to the
> public release.
>
> As of 29-Jul-2002, *no vendor* has implemented a fix that will protect
> clients behind proxies (without external DNS) from the attack variant
> outlined in the section "Quick-Swap DNS".
>
> Further vendor status can be found in the section "Vendor Responses".
____________________________________________________________________________
> __
> Exploit
>
>   1) Attacker controls DNS zone *.baz.com, configuring it as follows:
>
>       a) foo.bar.baz.com -> some web server operated by the attacker
>       b)     bar.baz.com -> 10.0.0.9 (some address behind BigCo's
firewall)
>   2) The attacker induces unsuspecting user at BigCo to visit
>      http://foo.bar.baz.com/.
>
>   3) A JavaScript on said page sets document.domain to "baz.bar.com"
>      (this is valid since baz.bar.com is a parent domain of
>      foo.bar.baz.com). See [1]. Also note that this step is not
>      strictly necessary, but substantially improves the performance of
>      the exploit and the ease of implementation.
>
>   4) JavaScript on the page then loads a page from
>      http://bar.baz.com/somePrivatePage.html into a hidden frame. This
>      page will be retrieved from 10.0.0.9, a machine behind the
>      firewall.
>
>   5) The JavaScript then extracts the contents of the other frame (it
>      can do this since the two frames' document.domain matches),
>      url-encodes it into a link and loads *that* link in another
>      hidden frame, thereby transmitting the contents of the intranet
>      page back to the attacker as part of the HTTP GET request. Large
>      pages could use <form>s and an HTTP POST.
____________________________________________________________________________
> __
> Moving beyond a single server
>
> By adding an entry X.Y.Z.baz.com for each address 10.X.Y.Z, this
> script could iteratively scan the entire 10.0.0.0/8 netblock. A
> pop-under could be used to keep a window open (with the JavaScript
> probe running) long enough to get substantial coverage.
____________________________________________________________________________
> __
> Attacking Web Services
>
> If the client in use is Microsoft Internet Explorer, this technique
> can be used to access arbitrary SOAP or XML-RPC based web services
> behind the firewall. Microsoft Internet Explorer 5.0 and later ship
> with an ActiveX control called "XMLHTTP", which allows JavaScripts to
> POST XML content to the server they originated from. Although XMLHTTP
> does not respect changes to document.domain, it is still vulnerable to
> this Quick-Swap DNS. Credit goes to Jared Smith-Mickelson for
> suggesting this possibility.
>
> A similar attack should be feasible with Mozilla's XMLHttpRequest
> object [4].
____________________________________________________________________________
> __
> Increased sophistication
>
> An even more sophisticated attack would involve the JavaScript
> querying the attacker's server for a list of IPs/URLs to fetch using
> this exploit. If the attacker can induce enough users within BigCo to
> visit the malicious script (by spamming them?), the attacker could
> construct a proxy server that would route her requests to a cluster of
> slave javascripts. The attacker would effectively be able to open up
> a web browser and saunter around the company's intranet as if she were
> sitting right on it.
____________________________________________________________________________
> __
> Quick-Swap DNS
>
> This variation of the attack will still work even if browser vendors
> change their policy to prohibit changes to document.domain.
>
> In this situation, the attacker would need a DNS server with the
> refresh/expire ttl set to zero (no caching allowed). Once the user
> loads the page from the attacker's web server, the attacker would
> change her DNS records so that foo.bar.baz.com now points to
> 10.0.0.9. The exploit would proceed normally. A custom DNS server
> could be used to automate this process. By allocating a single
> hostname to each slave JavaScript, an arbitrary number of
>
> Clients can be modified to "lock in" the IP for a given hostname once
> a page is loaded, although this approach will fail for clients behind
> a proxy without DNS access.
____________________________________________________________________________
> __
> Short Term Solution (by Dave Ahmad of SecurityFocus)
>
> Web servers behind firewalls should be configured to reject any HTTP
> requests with an unrecognized "Host" header, rather than serving pages
> from the "default" virtual host. This can be accomplished without
> patches by creating a "default" virtual host with no content, and
> creating a name-based virtual server for each hostname which the
> server is intented to serve as.
____________________________________________________________________________
> __
> Long Term Solution
>
> Many products have embedded HTTP servers which entirely ignore the
> Host header since they do not support name-based virtual hosts. The
> notion of a "default" virtual server is also very useful; it is
> doubtful that web server vendors will be willing to remove this
> feature simply to work around a flaw in popular web browsers.
>
> Clearly, a long-term solution to this problem must involve a
> refinement of the SOP policy.
>
> SOP should be enforced on an IP-by-IP basis, rather than a
> hostname-by-hostname basis, since the hostname-to-IP mapping is under
> the control of the attacker, while the IP-to-physical-server mapping
> is not.
>
> Since some clients behind HTTP proxies do not have access to a DNS
> server which they can use for name-to-IP resolution, HTTP Proxies
> should return an additional header in the HTTP reply
> "Origin-Server-Address:", whose value is the network-layer address of
> the origin server. A web browser without DNS access which recieves a
> script from a proxy which does not support this header must not be
> allowed to access content in any other frame, iframe, window, or
> layer.
____________________________________________________________________________
> __
> Vendor Responses
>
> Netscape:
>
>     Netscape/Mozilla has included a patch in the CVS repository [5]
>     which implements the following two refinements:
>
>         1) A change to document.domain is only honored if both the
>            source and target frame altered document.domain.
>
>         2) If the client has access to external DNS, the hostname-to-IP
>            mapping is "pinned" for the lifetime of the page.
>
>     These refinements defend against this vulnerability if the client has
>     access to DNS. Clients behind proxies who lack DNS access are still
>     vulnerable to the attack outlined in the section "Quick-Swap DNS".
>
> Microsoft:
>
>     Unsurprisingly, Microsoft's response to this issue came from their
>     Public Relations department, rather than their Engineering
>     department.  The statement indicated that Microsoft *would not*
>     issue a patch or hotfix, but would prefer to downplay the severity
>     of the vulnerability instead.
____________________________________________________________________________
> __
> Responsible Disclosure Timeline
>
> 25-Jun    Vulnerability discovered by Adam Megacz, submitted to bugtraq
>           [Discovery Phase begun]
>
> 26-Jun    Bugtraq moderator (Dave Ahmad) witholds posting, confers with
>           Adam Megacz, proposes short-term solution.
>
> 28-Jun    Vendor disclosure [Notification Phase begun]
>
>                   Microsoft Notified: secure () microsoft com
>           Apache Foundation Notified: security () apache org
>                    Netscape Notified:
> http://help.netscape.com/forms/bug-security.html
>             Mozilla Project Notified: security () mozilla org
>                        CERT Notified: cert () cert org
>
> 01-Jul    Advisory updated; SOAP/XML-RPC also vulnerable if client is
>           Microsoft Internet Explorer.
>
>                   Microsoft Notified: secure () microsoft com
>           Apache Foundation Notified: security () apache org
>             Mozilla Project Notified: security () mozilla org
>                        CERT Notified: cert () cert org
>
> 08-Jul    Advisory updated; SOAP/XML-RPC also vulnerable if client is
> Mozilla.
>
> 29-Jul    Advisory publicly released on bugtraq.
____________________________________________________________________________
> __
> Footnotes
>
> [1] http://www.mozilla.org/projects/security/components/same-origin.html
http://developer.netscape.com/docs/manuals/communicator/jsguide4/sec.htm
> [2] http://online.securityfocus.com/bid/3721
>
> [3]
http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0
> 0.txt
>
> [4]
http://unstable.elemental.com/mozilla/build/latest/mozilla/extensions/dox/in
> terfacensIXMLHttpRequest.html
>
> [5] http://bugzilla.mozilla.org/show_bug.cgi?id=154930
>
> --
> Sick of HTML user interfaces?
> www.xwt.org

--
Sick of HTML user interfaces?
www.xwt.org

Some people don't care if the pie is smaller, so long as they still
get all of it.