Off-path TCP hijacking in NAT-enabled Wi-Fi networks
blog.apnic.net
blog.apnic.net
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
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.
its meant to speed up connections and allow for more throughput through a router.
fast path changes the packet flow so it doesn't get processed by all firewall rules.
just explaining the use case for OPs question.
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.
(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) You need new host which hasn't been TOFU'd yet, and you need it to be exposed to internet with no VPN/mesh inbetween.
(2) You need password-based authentication _or_ agent forwarding, otherwise you won't be able to intercept traffic (with key-based auth, you can pretend to be the server, but that won't likely to last long). While I would not say that everyone uses key-based ssh, they should! It's an easy way to significantly increase your SSH security level.
As for HTTPs MITM, I don't see how this applies. They had to intercept traffic next to a server to be able to issue certificate - and I am pretty sure no one runs servers from the untrusted coffee shop connection! And you already have access to the server's datacenter, then there is no need to exploit public WiFi, you can intercept the server's traffic directly.
1. The ssh connection is intercepted, malicious server lets accepts arbitrary user's public key
2. Malicious server tries to connect to real server and fails - original pubkey authentication was channel-bound and cannot be reused
3. Malicious server now has to pretend to be the real server without knowing what the real server looks like. User immediately detects the shell prompt is different, the hostname is wrong, all the files are missing, etc... and disconnects.
(You can make some sort of contrived situation, like you only ssh'd to restart service, _and_ you used "sudo" with password _and_ you used ssh command so you didn't see the prompt _and_ this was the first command you did on your new computer... but this seems pretty unlikely)
And encrypted vs non-encrypted keys seems completely unrelated to connection interception attacks - who cares how the keys are stored on the computer? It's all the same on the wire.
The assumption was that it is the first time they connect. Which if so would mean that the key was configured out of band, but if we add that possibility you can do the TOFU out of band as well.
Yes, it is more common to transfer keys out of band - but it is getting a bit contrived.
...can use...
[1] http://notes.valdikss.org.ru/jabber.ru-mitm/
I have no doubt that there maybe a few dozen people in the entire world who would get attacked this way, but the chances it would be me are pretty much zero.
don't get me wrong, i like a global address space as much as the next internet native, but it's not for everyone to pay the price for it and nat makes it easy to opt-out of a large portion of the problem space.
[1] my university used to give public-routed v4 to students connecting their winxp laptop to the network; guess what happend
[1] https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
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...
net.ipv4.conf.all.rp_filter
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
sequence numbers were once considered 'good enough' as prime-factors are today
Almost every internet security mechanism relies on nobody guessing secret numbers, but normally they are sized appropriately.
* https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no...
NPTv6 is slightly different in that there really isn't address-port state (though an SPI firewall could track connection state), but the first /64 of the address is swapped about, and everything else should be left alone:
* https://datatracker.ietf.org/doc/html/rfc6296
(Of course I often get grief in networking forums for mentioning NPTv6 because it's "only" an Experimental RFC, and not Standards track.)
The main reason to use these mechanisms is either frequent prefix changes or multi-homing, though documents have been written on how to deal with those situations without translation (often in combination with ULA):
otoh ap-isolation isn't really a security feature but enhances spectrum efficiency by suppressing client-to-client communication. most wifi's are susceptible to the 'evil twin' attack.