Otherwise, good article.
Computer networks that use proxy servers to automatically redirect browser connections should be on the lookout for a serious architectural flaw that could allow attackers to remotely access intranets and other website resources that are normally off limits, security experts are warning. At least four proxy server vendors, …
Otherwise, good article.
AC, unfortunately, the advisory is less than crystal clear on this.
It says: "To exploit this issue an attacker needs to execute active content (Java, Flash, Silverlight, etc) in the context of a web browser." Elsewhere it says, "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."
you mean like NTL/Virgin/Teleworst?
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.
And I was just getting ready to deploy a transparent proxy on my home network. If I do that now, I won't update Squid for a couple years, which means I'll be vulnerable... Nothing like a good excuse to procrastinate.
"It remains unclear how common transparent interception is used in proxy servers"
Isn't this used for just about every public wifi network that has a login or authentication page?
Am I the only one who fails to see the security implications here? I read the vulnerability note, but I still don't get it. If your client system is compromised and your network traffic can be altered, then it's game over for your client system. So that just leaves the scenario of the client system using the proxy as a gateway to access a third system, where the client system normally is not allowed to access that third system. But that doesn't sound like a problem, either. If you designed your network right, and configured the appropriate ACLs and firewall rules, that wouldn't be an issue. Maybe it's just because I'm tired, but I don't see a software vulnerability here at all. The only ways I can see this being a problem are through bad configurations. Am I missing something?
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.
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).
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.
And I believe it is routinely used by most/all ISPs to implement the IWF censorship list.
"The good news is that the vulnerability only seems to affect proxy servers running in transparent mode"
A lot of ISPs work in this mode.
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?
I used to do this to bypass crap security at work back in the day when Quake 1 was still brand new.
fscked by SHA-1 collision? Not so fast, says Linus Torvalds