SANS ISC: Browser plug-ins, transparent proxies and same origin policies - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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