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


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward


    I think you mean javascript.

    Otherwise, good article.

  2. Dan Goodin (Written by Reg staff)


    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.

  3. Anonymous Coward

    few large networks?

    you mean like NTL/Virgin/Teleworst?

  4. Steven Knox

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

  5. Nexox Enigma


    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.

  6. Kanhef


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

  7. Chris C

    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?

  8. Anonymous Coward

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

  9. Anonymous Coward

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

  10. Jeff Deacon

    Re: Common?

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

  11. Bod

    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.

  12. foo_bar_baz

    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?

  13. Inachu

    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.

This topic is closed for new posts.

Other stories you might like

Biting the hand that feeds IT © 1998–2022