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

["GreyMagic Software" <security () greymagic com>]

> 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.

It is important to note that this vulnerability is not limited to firewalled
servers.

Using this vulnerability, a malicious webmaster may include content from
other sites in his page and freely interact with their content.

The privacy risk for users in this case is quite low because cookies are not
transferred to the server (different hostname). But this circumvention of
the Same Origin Policy will allow the webmaster to "safely" guess passwords
and steal services without any trace (if the "Host" header isn't checked, of
course).

For example, assume "victim.com" supplies stock market quotes to all
connecting clients. "attacker.com" would like to supply this service too.
The most common thing for "attacker.com" to do in this case is set up a
proxy, and upon a client request at "attacker.com", the server forwards the
request to "victim.com", analyzes the response and returns it to the client
at "attacker.com" in its own format.

This service stealing scenario can be easily noticed and traced by
"victim.com", which would simply disallow "attacker.com"'s connection.
Indeed, "attacker.com" can use a neutral open proxy, or even multiple
proxies in random order, but they are all likely to get blocked at some
point if "attacker.com" has heavy traffic.

With this vulnerability "attacker.com" can steal services from "victim.com"
without them ever knowing it. To "victim.com" it would seem like a real
client connected and used their services. While what really happened is the
following:

* "biz.attacker.com" got pointed at "victim.com"'s IP address.
* "fetch.biz.attacker.com" points to the attacker's own web server.
* A client requested a quote from "attacker.com".
* "fetch.biz.attacker.com" used a hidden iframe to load "biz.attacker.com".
* "fetch.biz.attacker.com" set document.domain to "biz.attacker.com".
* "fetch.biz.attacker.com" was now able to interact with "victim.com".
* "fetch.biz.attacker.com" extracted the results and displayed them.

This scenario makes "attacker.com" require virtually no resources in order
to serve clients because all the heavy HTTP requests are done by the
connecting client to "victim.com", fooling "victim.com" to think they have
an actual user and freeing up "attacker.com".

A lot of other similar scenarios are exposed by this vulnerability,
hopefully Microsoft will fix document.domain so it's required by both sides
for cross-hostname interaction.

- GMS