6 ms·
Off-path TCP hijacking in NAT-enabled Wi-Fi networks
- Xocial 2y ago125.135.80.59
- theamk 2y agoFeels much less scary in 2024.. when was the last time you used HTTP for anything important?
- supriyo-biswas 2y agoThese 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/ http://notes.valdikss.org.ru/jabber.ru-mitm/
- SebFender 2y agoThere's another great example - perfect comment.
- foobiekr 2y agohttps://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf https://www.usenix.org/system/files/login/articles/105484-Gu... Abstract: No.
- theamk 2y agoRe SSH: sure, it can happen, but in practice I'd rate this pretty low with most SSH users... (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.
- tjoff 2y ago2: key based ssh won't really help and isn't the magic bullet people seem to believe. Especially nonencrypted ssh keys which is what the majority uses.
- theamk 2y agosure it is, as long as you don't have agent forwarding 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.
- tjoff 2y agoYou assume that the server already knows the key though? 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.
- tsimionescu 2y agoThe HTTPS MITM case doesn't need to intercept close to the server, it just needs to know that Victim is trying to talk to a particular server. Then, they obtain a forged certificate, and use the same mechanism shown here to intercept the TLS ClientHello and pretend to be the TLS server, with the legitimate certificate. The reason this works is because in a targetted attack, it's much less likely that the improperly issued certificate would become public and (1) be revoked, and (2) cause problems for the CA that issued it.
- megous 2y ago> "since SSH uses a trust on first use model" ...can use...
- themoonisachees 2y agoThis specific attack is unable to exploit this, because it requires that the TCP connection be already established. By the time the user had gotten the server's public key, you are unable to hijack the connection.
- SebFender 2y agoNever think HTTPS will save you from proxies built by attackers... This may make it much simpler...
- SteveNuts 2y agoWouldn’t there still need to be a major vulnerability with the TLS library your client is using?
- supriyo-biswas 2y agoYou can obtain a certificate for the domain in question (easier if you are a nation-state) and MITM that specific user.
- theamk 2y ago... but you need to MITM server to obtain certificate, and if you can MITM server, why bother with user's wifi?
- supriyo-biswas 2y agoBecause it’s easier that the server be MITMed for a shorter duration to prevent discovery[1]. It’s also easier if you can just strong arm the CA to issue a certificate or have the shady CA issue it[2][3]. [1] http://notes.valdikss.org.ru/jabber.ru-mitm/ http://notes.valdikss.org.ru/jabber.ru-mitm/ [2] https://www.wired.com/2010/03/packet-forensics/ https://www.wired.com/2010/03/packet-forensics/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1391063 https://bugzilla.mozilla.org/show_bug.cgi?id=1391063
- yjftsjthsd-h 2y agoHow does one bypass certificate transparency? I tend to exclude state actors from my threat models (1. they tend to be the all-powerful boogeyman that bypasses all threat models anyways, and 2. I doubt that the NSA is going to get you by way of coffee shop wifi) but I'm actually struggling to see how even they would bypass this particular protection; if Chrome only trusts CT-logged certs, even a targeted one-off is likely to be discovered (albeit, AIUI, after the fact).
- fullspectrumdev 2y agoFrom recent efforts sniffing packets in public areas to specifically try answer this question: there’s still an assload of plaintext HTTP.
- binkHN 2y agoOuch. I bet the majority of coffee shops are affected.
- hackernudes 2y agoWould client isolation prevent the attacker at the layer 2 level?
- sambazi 2y agoi don't think so because attacker-to-client communication is only used to restore the original nat-mapping. 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.
- aidenn0 2y agoAnyone know if the MASQUERADE support in Linux iptables is affected by this? Or how I could tell?
- lathiat 2y agoI 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.
- taneliv 2y agoAs user zootboy above comments, OpenWRT removed a patch from their kernels that introduced a "no window checking" option for TCP processing,[1] which I suppose was enabled by default. [1] https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
- xxpor 2y agoNote that this means that conntrack's window tracking has to be perfectly in sync with both endpoints (assuming TCP invalids are dropped). Given endpoints tend to be updated more often than middleboxes, this isn't a great assumption to make.
- zootboy 2y agoWell, 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/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
- vzaliva 2y agoI assume a VPN should mitigate these attacks?
- bustling-noose 2y agoYou might still experience DOS attacks.
- vzaliva 2y agoBut only if my VPN is using TCP transport, right?
- bustling-noose 2y agoYes. With UDP VPN this shouldn’t be a problem I guess.
- johnklos 2y agoNo.
- Joel_Mckay 2y agoKerberos
- deleted 2y ago[deleted]
- MacrohardDoors 2y agoIf only my iPhone had an ethernet port, I’d be able to go completely wifi free.
- khrbtxyz 2y agohttps://www.apple.com/shop/product/HMJU2ZM/A/belkin-ethernet-power-adapter-with-lightning-connector https://www.apple.com/shop/product/HMJU2ZM/A/belkin-ethernet...
- bustling-noose 2y agoWith usb c this is even cheaper and easier.
- tichiian 2y agoI'd guess apple would invent some "made for iCrap" certification plus parts authentication to keep prices up and skim off some money for themselves.
- doublepg23 2y agoWhat’s the point of getting angry at a fictional product? They sell a generic USB-C Ethernet adapter for $30 https://store.apple.com/xc/product/HJKF2ZM/A https://store.apple.com/xc/product/HJKF2ZM/A
- eru 2y agoYou can make a local bluetooth network, too.
- MacrohardDoors 2y agoI do not like using Bluetooth. As soon as I figured out how to do bluetooth hacking on my Flipper Zero, I stopped using bluetooth - it is completely vulnerable to the same kinds of attacks BadUSB can do. Scary!
- egberts1 2y agoA 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://support.mozilla.org/mk/questions/1359401 https://arxiv.org/pdf/2209.12993 https://arxiv.org/pdf/2209.12993 https://github.com/0xkol/rfc6056-device-tracker https://github.com/0xkol/rfc6056-device-tracker https://www.rfc-editor.org/rfc/rfc6056.html https://www.rfc-editor.org/rfc/rfc6056.html
- sambazi 2y agothere is probably a reason that rp_filter defaults to off though
- chatmasta 2y agoYes, I think disabling it allows for more hole-punching techniques, since you can basically maintain a TCP connection indefinitely and across network connectivity changes.
- sambazi 2y agoiirc more like that you basically need the 'loose mode' because most cpe's are bridging wireless and wired networks, but this then won't protect against the more serious shenanigans
- blahgeek 2y agoIs 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 2y agoT̶a̶i̶l̶s̶c̶a̶l̶e̶: https://tailscale.com/blog/how-nat-traversal-works https://tailscale.com/blog/how-nat-traversal-works Libp2p: https://docs.libp2p.io/concepts/nat/hole-punching/ 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.
- damsalor 2y agoThe answer to this might be severely unsettling
- patrakov 2y agoThe legit use case is to pick up connections that were established before the router reboot.
- blahgeek 2y agoIf the router reboots, it cannot remember the correct mapping of the last connection, right? (The mapped port may not be the original source port)
- fulafel 2y agoAlways nice to have more security arguments against NAT.
- sambazi 2y agobecause there are so few of them?
- orangeboats 2y agoAmong all adjectives to describe the security issues of NAT, "few" is not one of them. _Especially_ when you remember that many are under the false impression that they are "protected" by NAT.
- sambazi 2y agoimo the protection is real and a good tradeoff for a research project to become a mass medium (i.e. clients usually don't want incoming connections from the internet[1]) 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
- fulafel 2y agoThis seems to suffer from the common reasoning error of equating addressability with reachability. Your university can disable public reachability without NAT eg using firewalling.
- hamilyon2 2y agoI always found it astonishing that security and integrity of the internet often rests upon “but TCP sequence numbers are unguessable”
- suprjami 2y agoTCP 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.
- sambazi 2y agosecurity is never perfect and the bar is rising. sequence numbers were once considered 'good enough' as prime-factors are today
- immibis 2y agoThey 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 2y agoThat's why we had to invent TLS (and now QUIC)
- the8472 2y agoSince 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 2y agoGood thing the IEEE recommended against implementing IPv6 NAT and everyone followed that rec- oh, wait.
- the8472 2y agoIEEE? You mean the IETF? And I explicitly said "many-to-one NATs" to not have to quibble about network-prefix-mapping NATs like NAT66 which are not deployed in coffee shops anyway.
- throw0101c 2y agoStrictly speaking NAT66 does not have any kind of specification, so implementations are 'vendor specific': * https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ 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 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): * https://datatracker.ietf.org/doc/html/rfc7157 https://datatracker.ietf.org/doc/html/rfc7157 * https://datatracker.ietf.org/doc/html/rfc8678 https://datatracker.ietf.org/doc/html/rfc8678
- Wheaties466 2y agoyet another use case for RFC 3704, Reverse path validation.
- reflexe 2y agoMaybe 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 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 2y agoAlso 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)