Browser plug-ins, transparent proxies and same origin policies

Published: 2009-03-10
Last Updated: 2009-03-10 13:37:41 UTC
by Swa Frantzen (Version: 1)
1 comment(s)

First, just a quick reminder:

  • Same origin policy is a way a browser keeps methods from being called between different sites. It assures that www.evil.com's scripts can't access www.bank.com's methods, even if you have both of them open in the same browser at the same time. Any failure here often is catastrophic to security.
  • Transparent proxies sit between the browser and the Internet and -as their name suggests- transparently try to either cache some content and safe some bandwidth or either are there to inspect traffic and/or enforce policies. They are supposed to be invisible to the browser. You'll find them at hotels, ISPs, corporate perimeters etc. There are quite a few security technologies that incorporate them to do content filtering.
  • Browsers typically have plug-ins such as a flash player that have extensive scripting capabilities (or java). These plug-ins can open TCP connections themselves.

As you're probably getting by now: the above combination can have a problem depending on how the transparent proxy is working.

Last month CERT released a not much published about vulnerability note, that by now still lists many vendors as unknown, but is starting to collect a number of vulnerable ones as well.

Robert sent us a pointer to a paper titled "Socket Capable Browser Plugins Result In Transparent Proxy Abuse".

In it the author describes the attack method in greater detail. The scenario is as follows:

The user (victim) visits somehow www.evil.com through his browser.

  • The browser resolves www.evil.com to 1.1.1.1
  • The browser downloads the content of the web page
  • The browser spots an object referenced in the web page
  • The browser downloads the object as well from the same www.evil.com website
  • The browser starts executing the object
  • The object opens a connection to 1.1.1.1 on port 80
  • In that TCP connection, it asks -using the HTTP protocol- for a URL that appears to come from a host www.secret.com (while connected to www.evil.com)

If the transparent proxy intercepts this (it will), and if it resolves www.secret.com to it's real IP address and not 1.1.1.1 of www.evil.com (it might), it might just have connected the browser -thinking it's talking to www.evil.com- with a connection to www.secret.com. The browser will now allow the object from www.evil.com access to what comes in (and goes out) through the connection to www.secret.com, while it also still can communicate with www.evil.com.

What can you do against this:

  • As a user: install Firefox and NoScript: as a user in e.g. a hotel that has a vulnerable transparent proxy this might be the only layer you'll get. By default, NoScript stops the objects from www.evil.com like all other scripts you didn't explicitly trust.
  • As an administrator of a transparent proxy, check the US-CERT note above and if your vendor isn't listed as "not vulnerable", contact them for a solution.

If you know other defenses that are effective, do contact us and we'll update.

--
Swa Frantzen -- Section 66

1 comment(s)

Comments

I'd be very happy if JavaScript just disappeared, and most of the common browser plugins too. They should at least lose access to sockets and the ability to manipulate HTTP headers. I don't know how many web or other services of today can be considered secure when this unsolicited in-browser trash can make arbitrary connections and cross-domain POSTs without a user's consent.

To make matters worse, plenty of websites would be totally inoperable without support for scripts like this -- running their poorly-written web app. code in-browser because any server would topple over trying to do that itself. It's about time I used NoScript and told some of these web developers exactly why I won't use their services any more.

Diary Archives