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
