Off-path TCP hijacking in NAT-enabled Wi-Fi networks

[egberts1]

A whitepaper detailing this CVE-2022-32296 attack.

Vulnerability is in Double-Hash Port Selection (DHPS, IETF RFC 6056)

Fixed in Linux 5.17.9 and above using a variant of DHPS.

Linux sysctl:

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.rp_filter = 1

Also Firefox Only HTTPS must be enabled to prevent JavaScript from performing dwell on hidden unsecure HTTP DOM frame.

----

https://support.mozilla.org/mk/questions/1359401

https://arxiv.org/pdf/2209.12993

https://github.com/0xkol/rfc6056-device-tracker

https://www.rfc-editor.org/rfc/rfc6056.html

[sambazi]

there is probably a reason that rp_filter defaults to off though

[blahgeek]

Is it common for routers to create a new mapping for TCP packets that is NOT SYN (in figure 3 in this article)? Is there a legit use case for this behavior? Wouldn't it be simpler and more secure not to do that?

[ytch]

T̶a̶i̶l̶s̶c̶a̶l̶e̶: https://tailscale.com/blog/how-nat-traversal-works

Libp2p: https://docs.libp2p.io/concepts/nat/hole-punching/

B̶o̶t̶h̶ (update: Only Libp2p works with TCP) use similar method for hold-punching. Libp2p can use such method for establishing direct connection between hosts behind different NAT networks.

[Wheaties466]

im pretty sure any router that uses fast path does this.

its meant to speed up connections and allow for more throughput through a router.

[patrakov]

The legit use case is to pick up connections that were established before the router reboot.

[damsalor]

The answer to this might be severely unsettling

[reflexe]

Maybe i am missing something but while it is interesting, I dont think it has any real security impact.

Since the threat model is that the attacker and the victim are connected to the same router via the same wifi network, not isolated from each other, in a case where you are using wifi in psk for example, the attacker can already sniff everything from other clients.

Therefore, you can spoof packets by just responding to them directly. It is a lot simpler and takes a lot less time (since you just need to respond faster than the server with the right seq and port numbers). Once you are in the same network you can do even crazier stuff like arp spoofing and then let the victim think that you are the router and convince it to send all of its packets to you (https://en.m.wikipedia.org/wiki/ARP_spoofing)

Edit: on a second thought, maybe in a use case where the victim and the attacker are in different wifi networks (or just configured to be isolated ), the attacker should be able to perform a denial of service for a specific ip:port by sending RST and then ACK with every possible source port.

[vass77]

Also only works with non encrypted conns (ftp, http), that one should not be using. And like you say on open or PSK networks you can do worst stuff (if isolation is not enable arp spoofing the default G will be way worst then this)

[theamk]

Feels much less scary in 2024.. when was the last time you used HTTP for anything important?

[supriyo-biswas]

These are not theoretical concerns though. For example, since SSH uses a trust on first use model as opposed to a central trust/web of trust model, they can direct the victim to a different SSH server if they're connecting to a new one, and intercept all traffic.

(Edit: Even with HTTPS, there are other ways to MITM a connection because each trusted CA is considered an equal. For example, instead of doing a full-on MITM on a service which is likely to be detected[1], a better solution may be to obtain a certificate and target the specific user.)

[1] http://notes.valdikss.org.ru/jabber.ru-mitm/

[fullspectrumdev]

From recent efforts sniffing packets in public areas to specifically try answer this question: there’s still an assload of plaintext HTTP.

[SebFender]

Never think HTTPS will save you from proxies built by attackers... This may make it much simpler...

[fulafel]

Always nice to have more security arguments against NAT.

[sambazi]

because there are so few of them?

[aidenn0]

Anyone know if the MASQUERADE support in Linux iptables is affected by this? Or how I could tell?

[zootboy]

Well, of the three mitigations suggested in the article:

1 - Random NAT port allocation

Seems like the answer is "not by default." According to iptables(8), SNAT defaults to using the pre-translated ports whenever possible, so it's up to the connecting client (victim's TCP stack) to randomly select source ports. There is a "--to-ports" option that lets you limit the usable source ports, but it's not mentioned how the ports are selected in that case.

2 - Reverse Path Validation

I'm not really sure how this helps in the described situation. If the attacker and the victim are on the same wifi access point, then both of their traffic will be sourced from the same network interface, so even strict RFC 3704 validation will pass for spoofed packets from the attacker. But for completeness, you can turn that on by setting a sysctl (rp_filter = 1).

3 - TCP window checking

I _believe_ that the vanilla linux kernel does check this by default, as the mentioned adjustments to OpenWRT seem to be removing a non-standard option to disable the TCP window checking

https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...

[Joel_Mckay]

In general there are usually rules that prevent cross-forwarding traffic, and thus traffic over wifi is isolated from each client (unless you need to share a home NAS/printer this should remain enabled.)

Most if not all modern routers have this feature, and also the ability to turn off the dumpster-fire that is UPnP and flaky port-trigger mods. Additionally, some add packet marking rules, which is often also used to enforce fair bandwidth sharing. Yet note this can be a nonstandard controversial gray-area.

One could also use a private cert based VPN + Kerberos with firewall client pre-set rules on any un-trusted/open access points.

YMMV, =3

[lathiat]

I would have assumed linux conntrack to do more rigorous "tcp window checking" as an assumption, however the article also notes they received a positive response from OpenWRT who implemented a mitigation, so I am curious to see the details of that mitigation.

[hamilyon2]

I always found it astonishing that security and integrity of the internet often rests upon “but TCP sequence numbers are unguessable”

[suprjami]

TCP sequence numbers are not a security mechanism, they are a data ordering mechanism. If you want security, use encryption like IPSec or TLS. This has been the state of things since TCP was invented in 1980. Someone new discovers it all the time.

[immibis]

They are effectively authentication cookies, but the cookies are too short, but at least they turn over frequently and you have to send a few gigabytes of data to guess one.

Almost every internet security mechanism relies on nobody guessing secret numbers, but normally they are sized appropriately.

[goodpoint]

That's why we had to invent TLS (and now QUIC)

[the8472]

Since this is caused by many-to-one NATs IPv6 should be immune to this. Migrating to ipv6 should be listed as one of the mitigations.

[suprjami]

Good thing the IEEE recommended against implementing IPv6 NAT and everyone followed that rec- oh, wait.

[binkHN]

Ouch. I bet the majority of coffee shops are affected.

[hackernudes]

Would client isolation prevent the attacker at the layer 2 level?

[vzaliva]

I assume a VPN should mitigate these attacks?

[bustling-noose]

You might still experience DOS attacks.

[johnklos]

No.

[Xocial]

125.135.80.59

[Wheaties466]

yet another use case for RFC 3704, Reverse path validation.

[MacrohardDoors]

If only my iPhone had an ethernet port, I’d be able to go completely wifi free.

[khrbtxyz]

https://www.apple.com/shop/product/HMJU2ZM/A/belkin-ethernet...

[eru]

You can make a local bluetooth network, too.