Feeds

back to article Proxy server bug exposes websites' private parts

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, …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

Java?

I think you mean javascript.

Otherwise, good article.

0
0
(Written by Reg staff)

@Java?

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

Not sure if the author really meant javascript. If anyone from CERT knows, please contact me.

0
0
Unhappy

few large networks?

you mean like NTL/Virgin/Teleworst?

0
0
Silver badge
Boffin

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

0
0

Hmmm

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.

0
0

Common?

"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?

0
0

Help me understand this

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?

0
0
Stop

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

0
0
Stop

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

0
0

Re: Common?

And I believe it is routinely used by most/all ISPs to implement the IWF censorship list.

0
0
Bod
Bronze badge

Transparent ISPs

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

0
0
Pirate

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?

0
0
Flame

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.

0
0
This topic is closed for new posts.