Date: 29 Jul 2002 10:57:11 -0700
From: Adam Megacz <adam@xwt.org.>
To: [email protected]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: [email protected]
Apache Foundation Notified: [email protected]
Netscape Notified: http://help.netscape.com/forms/bug-security.html
Mozilla Project Notified: [email protected]
CERT Notified: [email protected]
01-Jul Advisory updated; SOAP/XML-RPC also vulnerable if client is
Microsoft Internet Explorer.
Microsoft Notified: [email protected]
Apache Foundation Notified: [email protected]
Mozilla Project Notified: [email protected]
CERT Notified: [email protected]
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.htmlhttp://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-00.txt
[4] http://unstable.elemental.com/mozilla/build/latest/mozilla/extensions/dox/interfacensIXMLHttpRequest.html
[5] http://bugzilla.mozilla.org/show_bug.cgi?id=154930
--
Sick of HTML user interfaces?
www.xwt.org
