1. 34
  1. 2

    So. How would you fix that? Make Application Level Gateways even smarter? That doesn’t sound right. :)

    1. 2

      On the browser side, once you’ve committed to multiple plaintext HTTP packets, unpredictably change their sizes so their content can’t be precisely controlled. It’s a performance hit, but a server can opt out of it by using HTTPS, which prevents the server from controlling the packet content. Web sockets have unpredictable browser-side masking to keep exactly this attack from happening, but it’s too late to do that for baseline HTTP.

      1. 1

        I’m highly doubtful this level of complexity will be acceptable for browsers to mitigate a niche attack. After all, NAT was never meant a security boundary.

        Disclaimer: I work on Firefox but not enough on networking to have any particular insights.

        1. 4

          This attack doesn’t look as if it’s actually specific to NAT. If I understand it correctly, any firewall that parses packets for protocols that advertise an inbound port in an outbound message and automatically opens inbound ports based on the contents would be vulnerable, whether NAT is involved or not. The real question for me is why firewalls are doing that. As I recall, SIP doesn’t need that functionality and FTP (the other protocol mentioned in the attack that does) has used passive mode (where the client initiates all connections) by default for 10-15 years in every client I’ve used.

          As to what the browser can do about this, there are presumably only a handful of packet formats that routers are inspecting for this. A browser could quite easily inspect the outbound queue and forcibly fragment things in such a way that any packet that looks as if it might trigger one of these rules would be forcibly split so that the boundary was in the wrong place.

          I’m not 100% convinced that it’s sufficient to do this only for HTTP: given that the attacker controls the server, they can probably give you a plaintext that encrypts to the desired packet format: During the symmetric flow, they just need to know the shared key and predict the nonce, they can then take the message that they want, decrypt it with the right IV, and send it you the client, which then sends it back, encrypted.

          1. 1

            I actually thought of the „encrypt it as a desired plain text“ hack. Would be fun to pull off.

            Browsers already implement a list of blocked ports. I’m suggesting we add 5060 to Firefox. We’ll see if that’s breaking other flows.

            1. 1

              Does that actually help? I don’t know enough about ALG, but as I understand the SIP thing it is detecting a specific pattern in the outbound packet that looks like a SIP message. FTP is the other protocol mentioned in the article, so you’d need to also block the FTP port for HTTP requests, because a packet that looks like it’s initiating an active-mode FTP transfer would also trigger the attack. There are probably other protocols that include this antipattern.

              1. 1

                Yup, ports for other plain text protocols are already mostly blocked. But this is a mitigation. Not the solution. See attached patch.

                1. 1

                  I think the thing that I’m confused by is whether this is enough. Do the routers that do ALG things detect SIP-like packets on outbound port 5060, or do they detect SIP packets? If it’s the former, then this mitigation is useful. If it’s the latter, then the attack will still work if you move the server to port 5061.

                  1. 1

                    I’m sure every firewall behaves differently. The full article quotes netfilter source code, which does require the port to be 5060. In particular, Samy is linking to https://github.com/samyk/linux/blob/29b0b5d56589d66bd5793f1e09211ce7d7d3cd36/net/netfilter/nf_conntrack_sip.c#L1676

            2. 1

              I’m not 100% convinced that it’s sufficient to do this only for HTTP: given that the attacker controls the server, they can probably give you a plaintext that encrypts to the desired packet format: During the symmetric flow, they just need to know the shared key and predict the nonce, they can then take the message that they want, decrypt it with the right IV, and send it you the client, which then sends it back, encrypted.

              Is there a strict correspondence between packets and TLS records (which have a record header, c.f. https://tls13.ulfheim.net/ )?

              Otherwise, could the browser cheaply force a re-key for non-websockets when making a new request or when receiving a websocket packet or server side push? That’d prevent the server communicating knowledge of the existing client key to the server-controlled page on the client.

              1. 1

                Good point. Alternatively, the browser could also just use a cryptographically secure random number generator for the nonces (which it might be doing anyway), which would make guessing the plaintext that encrypts to a specific cypertext impossible.

            3. 3

              NAT was never meant a security boundary.

              True, but at some point we need to acknowledge that it is being relied on as one in hundreds of millions of installations around the world.

          2. 2

            Are there really that many routers with ALG enabled? I’m genuinely surprised here. I worked in VoIP a long time ago, and the most common quick fixes were: disable ALG, and if that doesn’t work, create a separate VLAN for hardphones. But this was all business/enterprise router hardware, and I’ve not seen it much on consumer stuff.

            1. 1

              The size of the ALG-enabled router population is indeed questionable however some network appliances would not (at least explicitly) advertise ALG options, as it is the case with ISP supplied routers.

            2. 1

              Yeah, I’ve been trying to armchair that to little or no avail. My sole comfort is that I have a physically separated, policy routed net where one path is everything web and the other is things I care about and a data diode in. That’s not a solution for everyone.

              1. 1

                Don’t trust NAT to offer any protection to client devices… which has been always the advice.

                1. 3

                  Fun challenge - find an reasonable advice that has been ignored more than that one.

                2. 1

                  I have a separate (network) interface for talking to services on my network (and it’s the one with the default route), and I simply don’t bind those services to the network interface I put on the Internet. This makes me immune to this attack even though I use NAT with no particular firewalling simply by having my workstation not enable IP routing.

                  Another trick is to VPN to your gateway. This usually gives you another (virtual) interface and if the Internet is down that way your workstation firewall can now trivially differentiate between “internet” traffic and “lan traffic from the router” (this makes the Windows firewall a lot more useful).

                  Another (workstation-specific) trick is to block Internet hosts access to anything but ephemeral ports. This nullifies the most dangerous forms of this attack. If your router doesn’t block source routed traffic for you, consider using the MAC address of your router as the selector since it and everything behind it likely doesn’t have any business talking to your machine on anything but ephemeral ports anyway.