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

[Peter Watkins <peterw () usa net>]

On Mon, Jul 29, 2002 at 10:57:11AM -0700, Adam Megacz wrote:

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

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

Very clever!

Seems to me there's another tactic many enterprises can use to protect 
against this in a fairly simple, centralized manner. Any enterprise which 
forces its users' browsers to use a proxy server for "external" content may 
have an easy fix. Simply configure the proxy server to disallow any request 
whose Host is not the company's own domain *and* whose "remote" IP address 
is on the local network. E.G. in Squid ACL logic, something like

acl ToOurDomain dstdomain .example.com
acl ToOurLAN dst 10.0.0.0/8 192.168.0.0/16 
http_access deny ToOurLAN !ToOurDomain

Since the victim.example.com user's browser will connect to the specified 
proxy server to get http://bar.baz.com/somePrivatePage.html, the proxy 
server can prevent the client attack without any hard-to-distribute client 
software updates.

More straightforward might be

acl ToOurLAN dst 10.0.0.0/8 192.168.0.0/16 
http_access deny ToOurLAN

since in most cases the clients should never request an internal resource 
through the proxy server (it's inefficient, for starters).

There's an assumption here, that the client software/browser will look at 
the URL's "hostname" component on its face ("bar.baz.com") instead of the IP 
address it represents ("10.0.0.9") when deciding if the URL represents a 
"local" resource (i.e., one to request via direct TCP) or a "remote" address 
that should go through the proxy server.

Of course enterprises that use have "straight" NAT are in trouble -- even 
places with transparent Web proxy servers would be out of luck, as the 
request for http://bar.baz.com/somePrivatePage.html is unlikely to hit the 
transparent proxy, as such networking magic is usually implemented on the 
egress point(s), not on multiple points inside the network. In a typical NAT 
setup, the request for http://bar.baz.com/somePrivatePage.html would go 
directly from desktop:someHighPort to target:80 & the device doing the 
transparent redirection would never see it happen. Sure, the transparent 
proxy in some cases could munge the content of cleartext/http pages en route 
to the user's desktop, but that's getting seriously hairy. NAT at work is bad.

-Peter

-- 
Peter Watkins - peterw () tux org - peterw () usa net - http://www.tux.org/~peterw/ 
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692