30th Jul 2002 [SBWID-5578]
COMMAND
JavaScript's "Same Origin Policy" circumvention allows bypassing
firewall rules
SYSTEMS AFFECTED
All
PROBLEM
In Adam Megacz [adam@xwt.org] of XWT Foundation
[http://www.xwt.org/sop.txt] security advisory :
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-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
______________________________________________________________________________
Updates
31 July 2002
============
Jason Coombs [jasonc@science.org] posted following comments:
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.
SOLUTION
?
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH
