Message-ID: <Pine.LNX.4.58.0702032000440.30846@dione>
Date: Sat, 3 Feb 2007 21:57:01 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...sys.com, websecurity@...appsec.org
Subject: Web 2.0 backdoors made easy with MSIE &
	XMLHttpRequest

As you probably know, the famous "web 2.0" XMLHttpRequest object allows
client-side web scripts to send nearly arbitrary HTTP requests, and then
freely analyze and manipulate the returned response, including HTTP
headers.

This gives an unprecedented level of control over your browser to the
author of a visited site. For this reason, to prevent various types of
abuse, XMLHttpRequest is restricted to interacting only with the site from
where the script originated, based on protocol, port, and host name
observed.

Unfortunately, due to a programming error, Microsoft's Msxml2.XMLHTTP
ActiveX object that MSIE relies on allows you to bypass this restriction
with the use of - BEHOLD - a highly sophisticated newline-and-tab
technology.

If the victim uses a proxy server (which is very common in corporate
settings), any intranet or Internet site can be interacted with in this
arcane manner:

  xmlhttp.open("GET\thttp://dione.ids.pl/\tHTTP/1.0\n\n", "x",true);

Otherwise, only sites co-hosted on the same server or load balancer can be
interacted with - which today can still mean quite a lot, for example
foxyteens.googlepages.com and gmail.com go nicely together. In such a
case, the request is:

  xmlhttp.open("GET\t/\tHTTP/1.0\nHost:\tdione.ids.pl\n\n", "x",true);

All contents of the requested page, including cookies, hidden form tokens,
etc, can be then extracted through the use of responseText and
getResponseHeader(), manipulated by the script, and used into subsequent
GET or POST requests.

A test page is available here:

  http://lcamtuf.coredump.cx/iexmltest.html

The browser will think it's still talking to the site from which the
script originated, so no session cookies will be sent to that server - but
some interesting activity is still possible: in the true spirit of Web
2.0, this can be trivially turned into an interactive client-side backdoor
proxy that may send shivers down the spines of some corporate security
dudes.

Consider this example: a guy working for company X is sent a link to
hotbrunette25's blog or a really cute video of singing hamsters. While he
is preoccupied with that resource, the creator of a malicious script can
order victim's browser to:

  1) Rapidly scan company's internal web services (XMLHttpRequest
     supports asynchronous connections and connection notification),

  2) Obtain real-time copies of site fronts (raw HTML responseText can be
     sent back directly to the attacker through a "legitimate"
     XMLHttpRequest).

  3) Interact with interesting ones in real-time in a virtually
     unrestricted manner (POSTs and GETs with any payloads can be
     requested, cookies can be set with setRequestHeader, etc).

Attacker functionality can be esentially implemented as a browser plugin
or a custom proxy and allow what amounts to highly-responsive,
feel-like-you're-there, remote presence - which certainly takes what used
to be blind bounce scanning and XSS to a 2.0 level.

In a setting where no proxy is available, and no elaborate private
infrastructure would be exposed to the attacker, the author of
foxyteens.googlepages.com can of course still use this to send possum
gang-rape spam through GMail from victim's IP, or whatnot - but that's of
course less exciting.

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists