Re: XWT Foundation Advisory: Firewall circumvention possible with all browsers
From: Peter Watkins (peterw@usa.net)Date: 07/29/02
- Previous message: Microsoft Security Response Center: "RE: XWT Foundation Advisory"
- In reply to: Adam Megacz: "XWT Foundation Advisory: Firewall circumvention possible with all browsers"
- Next in thread: GreyMagic Software: "RE: XWT Foundation Advisory: Firewall circumvention possible with all browsers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 29 Jul 2002 16:23:36 -0400 From: Peter Watkins <peterw@usa.net> To: Adam Megacz <adam@xwt.org>
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
- Previous message: Microsoft Security Response Center: "RE: XWT Foundation Advisory"
- In reply to: Adam Megacz: "XWT Foundation Advisory: Firewall circumvention possible with all browsers"
- Next in thread: GreyMagic Software: "RE: XWT Foundation Advisory: Firewall circumvention possible with all browsers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
