Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Apps :: web5578.htm

JavaScript's "Same Origin Policy" circumvention allows bypassing firewall rules



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-2014 AOH