back to article FalseCONNECT sends vendors scrambling to patch proxy MITM bug

For the many people that dislike corporate proxies, this probably won't be much of a surprise: a bunch of environments are vulnerable to man-in-the-middle attacks. “FalseCONNECT” is a combination of protocol bug and implementation error – which means it affects end users via operating systems, as well as network devices. The …

  1. Anonymous Coward
    Anonymous Coward

    Ingenious

    This is fairly ingenious. In my opinion Chirgwin makes a bit of a meal out of it, but the salient points are:

    1. An HTTP CONNECT request to a proxy will usually (but not necessarily) be transmitted in the clear and may therefore be intercepted.

    2. Mr Decime took advantage of the previous point by sending a response to the browser which does not conform to the protocol: RFC 7235 states that a 407 MUST be accompanied by a "Proxy-Authenticate" header. It looks like WebKit does not check for this and treats a 407, which in principle should only be generated by a proxy and not by the end server, as any other 4xx response, and therefore evaluates the response body within the security context of the end server.

    Note: Seriously sleep deprived. I might have got something wrong myself above.

  2. Anonymous Coward
    Anonymous Coward

    Does this require that you have a proxy configured?

    It sounds like it does, which would tend to make it much more likely to be exploited to attack those browsing from inside a corporate network. That's where hackers really want to get though, since there's a lot of juicy data inside and internal security is often pretty lax.

    This could become a rather troublesome attack, given the variety of stuff vulnerable (and I have a feeling that's not a complete list) and how long it will take to get it all patched up.

    1. theblackhand

      Re: Does this require that you have a proxy configured?

      Yes, you would need to have a proxy configured to trigger the CONNECT's rather than sending the requests directly to a web server.

      If the attacker is on the same subnet as you and you are using Windows, they might be able to automatically configure proxy settings via WPAD using NetBIOS name resolution, but there are steps that can be taken to mitigate that (disable proxy auto detection, disable NetBIOS over TCP/IP).

  3. frank ly

    Security Design

    When the various security protocols were formulated and issued, didn't they have a group of experienced white/black hat hackers to go over them with a fine-toothed comb to try to break them?

    This attack seems like simple trickery and not particularly clever or complicated.

    1. waldo kitty
      Boffin

      Re: Security Design

      When the various security protocols were formulated and issued, didn't they have a group of experienced white/black hat hackers to go over them with a fine-toothed comb to try to break them?

      ummm... you're not thinking of the period of time in question... remember that the net started wild and free... it wasn't tied or locked down until hackers started ruining things for everyone... that was years later after it was all up and running...

      1. Amos

        Re: Security Design - been there done that. Twice already.

        RFC 7235 etc were redone just a few years ago. That is why the MUST exists on the 407 response status.

        There is nothing actually new about this problem. It has been known about since sometime around 2002 when Microsoft found it and fixed similar behaviours in MSIE. The other browser vendors lagged a bit but got their fixes out in 2009. Lookup CVE-2009-1835 if you want a reference.

  4. Anonymous Coward
    Anonymous Coward

    With the large number of non-browser applications using basic auth only...

    ... getting someone proxy credentials is easier than many think. And let's not talk of how many systems store proxy credentials in plain text in some config file. Where using SSO, they could be the AD credentials.

    The issue is often Linux software is used, and configuring it to use a strong authentication methods (i.e. Kerberos) may be complex, especially against a Windows AD.

    So lazy and incompetent sysadmins use the easiest - and most insecure - auth method. Coupled with lazy and incompetent developers who to the same client side (so even if you configure your proxy correctly, some app will ask for Basic only....), getting proxy traffic can be one of the best way to p0wn a whole network.

    1. Anonymous Coward
      Anonymous Coward

      Re: With the large number of non-browser applications using basic auth only...

      This vulnerability has nothing to do with Basic auth. If you actually read the vulnerability info it requires the not-a-proxy recipient to *omit* the authentication type header.

      And FYI, the most insecure authentication scheme is not Basic. Its NTLM. Both can be decrypted in realtime, but Basic at least nobody with half a brain trusts very much. NTLM goes places Basic is forbidden on grounds of being insecure.

      With Basic you get a username and password. Period. And only for the proxy being logged into.

      With NTLM you get username, OS version and patch level, user account hash and ID, Internal machine name, workgroup and/or domain name used for the LAN, whether the user is English/American or international (and what non-English country), and some details about the DC server. With the decrypted hash ID you can go anywhere that user + DC combo permits. Who needs a a freakin' password?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like