Proxy server bug exposes websites' private parts

few large networks?

you mean like NTL/Virgin/Teleworst?

@AC - Java

No, they mean Java.

From the advisory:

"Browser plugins (Flash, Java, etc) may enforce access controls on active content by limiting communication to the site or domain that the content originated from. An attacker may be able to forge host header values via active content."

Otherwise, good comment.

Not convinced of the seriousness of this one

For those who know a little about HTTP, this vulnerability is basically to do with the fact that many transparent proxies make a connection directly to what's in the "Host:" header of a request, *not to the original destination IP*. So I could, for example, make an outbound connection to the IP address of google.com on port 80, send an HTTP request with the "Host:" header set to the hostname of an internal machine, and end up connected to the internal machine rather than Google - without, if the code making the connection was hosted on google.com, necessarily breaking the security model of whatever sandbox environment my code runs in.

So having acknowledged the vulnerability... why do I say it's "not serious"? Well, for an attacker to exploit this, they have to know that a vulnerable transparent proxy is in use, trick someone into running their code, know the location of whatever is on the LAN that they want to access, and that resource has to be unsecured (i.e. accessible without username/password) or secured with details I have previously pilfered. Additionally, the code's environment has to allow me to make arbitrary TCP connections, because sandboxed no language which just provides a wrapper around HTTP requests should allow code to insert an arbitrary "Host:" header, so no JavaScript for you, script kiddies. Also, since the HTTP "CONNECT" request (used for HTTPS tunnels; can be abused for arbitrary tunnelling on badly configured proxies) doesn't use "Host:" headers, you can only access resources on plain old HTTP (no other protocols, not even HTTPS).

Workarounds are simple: require usernames & passwords for intranet sites, use HTTPS for intranet sites, explicitly deny access to intranet sites via access controls on the proxy, or best of all, *don't use a transparent proxy* (say it with me: TRANSPARENT PROXIES SUCK).

@Kanhef - yes, but that's missing the point

Transparent proxies may be in use in that kind of environment, but it is intranet sites which can be accessed unexpectedly here, not resources on the local machine. In your example, it wouldn't allow an attacker to do anything that a normal user of the network couldn't; and since it's a network with a public entry point, it had better already have its internal infrastructure secured. There would be no point in attacking via this method, an attacker would be much better off just going and joining the network directly.

Lack of imagination

If I understood AC's explanation, an applet could access arbitrary intranet sites while appearing to the browser and VM to be communicating with its host site. Routers with default configuration and web admin interface enabled are an obvious target. Trivial to script a session to add lax firewall rules. You DO read your proxy logs, right?

lol this is really an old old bug!

I used to do this to bypass crap security at work back in the day when Quake 1 was still brand new.