[HN Gopher] Off-path TCP hijacking in NAT-enabled Wi-Fi networks
___________________________________________________________________
Off-path TCP hijacking in NAT-enabled Wi-Fi networks
Author : gtirloni
Score : 200 points
Date : 2024-06-18 23:27 UTC (23 hours ago)
(HTM) web link (blog.apnic.net)
(TXT) w3m dump (blog.apnic.net)
| theamk wrote:
| Feels much less scary in 2024.. when was the last time you used
| HTTP for anything important?
| supriyo-biswas wrote:
| 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/
| SebFender wrote:
| There's another great example - perfect comment.
| foobiekr wrote:
| https://www.usenix.org/system/files/login/articles/105484-Gu.
| ..
|
| Abstract: No.
| theamk wrote:
| Re 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 wrote:
| 2: 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 wrote:
| sure 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.
| tsimionescu wrote:
| The 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 wrote:
| > "since SSH uses a trust on first use model"
|
| ...can use...
| themoonisachees wrote:
| This 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 wrote:
| Never think HTTPS will save you from proxies built by
| attackers... This may make it much simpler...
| SteveNuts wrote:
| Wouldn't there still need to be a major vulnerability with
| the TLS library your client is using?
| supriyo-biswas wrote:
| You can obtain a certificate for the domain in question
| (easier if you are a nation-state) and MITM that specific
| user.
| theamk wrote:
| ... but you need to MITM server to obtain certificate,
| and if you can MITM server, why bother with user's wifi?
| supriyo-biswas wrote:
| Because 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/
|
| [2] https://www.wired.com/2010/03/packet-forensics/
|
| [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1391063
| yjftsjthsd-h wrote:
| How 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).
| theamk wrote:
| Sure they will, given Chrome's requirement for CT logs, any
| attacker-issued certificates will be logged, someone will
| find the suspicious record, and the method will likely be
| burned from all the publicity.
|
| 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.
| 8organicbits wrote:
| How often are you reviewing the CT logs for your domains? I
| posit that's rare.
| immibis wrote:
| BTW this attack actually happened with jabber.ru - "law"
| "enforcement" physically intercepted their Ethernet port,
| then they got to use their IP address and could issue new
| certificates.
| debatem1 wrote:
| Do you happen to have a link or any other information
| about this?
| fullspectrumdev wrote:
| From recent efforts sniffing packets in public areas to
| specifically try answer this question: there's still an assload
| of plaintext HTTP.
| binkHN wrote:
| Ouch. I bet the majority of coffee shops are affected.
| hackernudes wrote:
| Would client isolation prevent the attacker at the layer 2
| level?
| sambazi wrote:
| i 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 wrote:
| Anyone know if the MASQUERADE support in Linux iptables is
| affected by this? Or how I could tell?
| lathiat wrote:
| 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.
| taneliv wrote:
| As 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/75e78bcaab84755
| 7ce...
| xxpor wrote:
| Note 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 wrote:
| 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...
| fanf2 wrote:
| The attack uses packets sent from the WiFi side to the WAN IP
| address, which is what reverse path filtering prevents.
| zootboy wrote:
| Ah, yes, that's the detail I missed for why #2 is relevant.
| So the answer to #2 is "not by default, but easy to
| enable." Though other comment threads here have discussed
| the potential for this to impact NAT hole punching.
| aidenn0 wrote:
| For those looking for rp_filter it is
| net.ipv4.conf.all.rp_filter
|
| (or replace "all" with a device name to turn it on for just
| one device).
| Joel_Mckay wrote:
| 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
| vzaliva wrote:
| I assume a VPN should mitigate these attacks?
| bustling-noose wrote:
| You might still experience DOS attacks.
| vzaliva wrote:
| But only if my VPN is using TCP transport, right?
| bustling-noose wrote:
| Yes. With UDP VPN this shouldn't be a problem I guess.
| vzaliva wrote:
| I think IPSec is also safe as it neither UDP or TCP.
| johnklos wrote:
| No.
| Joel_Mckay wrote:
| Kerberos
| MacrohardDoors wrote:
| If only my iPhone had an ethernet port, I'd be able to go
| completely wifi free.
| khrbtxyz wrote:
| https://www.apple.com/shop/product/HMJU2ZM/A/belkin-ethernet...
| bustling-noose wrote:
| With usb c this is even cheaper and easier.
| tichiian wrote:
| I'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 wrote:
| What'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
| eru wrote:
| You can make a local bluetooth network, too.
| egberts1 wrote:
| 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 wrote:
| there is probably a reason that rp_filter defaults to off
| though
| chatmasta wrote:
| Yes, I think disabling it allows for more hole-punching
| techniques, since you can basically maintain a TCP connection
| indefinitely and across network connectivity changes.
| blahgeek wrote:
| 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 wrote:
| Tailscale: https://tailscale.com/blog/how-nat-traversal-works
|
| Libp2p: https://docs.libp2p.io/concepts/nat/hole-punching/
|
| Both (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.
| mkj wrote:
| The tailscale one at least isn't TCP, it's UDP
| ytch wrote:
| My bad, I forget about this.
| damsalor wrote:
| The answer to this might be severely unsettling
| patrakov wrote:
| The legit use case is to pick up connections that were
| established before the router reboot.
| blahgeek wrote:
| If the router reboots, it cannot remember the correct mapping
| of the last connection, right? (The mapped port may not be
| the original source port)
| r1ch wrote:
| That's why port preservation is the usual behavior.
| patrakov wrote:
| (edited) Correct, this pickup of ports from the ACKs that
| the internal host keeps resending only works if the
| externally mapped port didn't change from the default (same
| as internal).
| semi wrote:
| wouldn't it also work for connections established on another
| router that then failed or otherwise had traffic shift to it?
| Wheaties466 wrote:
| 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.
| xxpor wrote:
| Connection tracking != fast path flow tracking in a lot of
| cases.
| Wheaties466 wrote:
| well yeah but one of the main reasons for a different path
| after a syn packet is fast path behavior.
|
| fast path changes the packet flow so it doesn't get
| processed by all firewall rules.
|
| just explaining the use case for OPs question.
| fulafel wrote:
| Always nice to have more security arguments against NAT.
| sambazi wrote:
| because there are so few of them?
| hamilyon2 wrote:
| I always found it astonishing that security and integrity of the
| internet often rests upon "but TCP sequence numbers are
| unguessable"
| suprjami wrote:
| 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.
| sambazi wrote:
| security is never perfect and the bar is rising.
|
| sequence numbers were once considered 'good enough' as prime-
| factors are today
| immibis wrote:
| 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.
| the8472 wrote:
| 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 wrote:
| Good thing the IEEE recommended against implementing IPv6 NAT
| and everyone followed that rec- oh, wait.
| the8472 wrote:
| IEEE? 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 wrote:
| Strictly 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...
|
| 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):
|
| * https://datatracker.ietf.org/doc/html/rfc7157
|
| * https://datatracker.ietf.org/doc/html/rfc8678
| Wheaties466 wrote:
| yet another use case for RFC 3704, Reverse path validation.
| reflexe wrote:
| 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.
___________________________________________________________________
(page generated 2024-06-19 23:02 UTC)