Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks

[Deleted member 77025]

Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks

In this paper, we uncover a new side-channel vulnerability in the widely used NAT port preservation strategy and an insufficient reverse path validation strategy of Wi-Fi routers, which allows an off-path attacker to infer if there is one victim client in the same network communicating with another host on the Internet using TCP. After detecting the presence of TCP connections between the victim client and the server, the attacker can evict the original NAT mapping and reconstruct a new mapping at the router by sending fake TCP packets due to the routers' vulnerability of disabling TCP window tracking strategy, which has been faithfully implemented in most of the routers for years. In this way, the attacker can intercept TCP packets from the server and obtain the current sequence and acknowledgment numbers, which in turn allows the attacker to forcibly close the connection, poison the traffic in plain text, or reroute the server's incoming packets to the attacker. We test 67 widely used routers from 30 vendors and discover that 52 of them are affected by this attack. Also, we conduct an extensive measurement study on 93 real-world Wi-Fi networks. The experimental results show that 75 of these evaluated Wi-Fi networks (81%) are fully vulnerable to our attack. Our case study shows that it takes about 17.5, 19.4, and 54.5 seconds on average to terminate an SSH connection, download private files from FTP servers, and inject fake HTTP response packets with success rates of 87.4%, 82.6%, and 76.1%. We responsibly disclose the vulnerability and suggest mitigation strategies to all affected vendors and have received positive feedback, including acknowledgments, CVEs, rewards, and adoption of our suggestions.

Another effective measure to pre-
vent the attack is to adopt the RFC 3704 recommendation,
which suggests using the strict mode to filter out forged
packets. In our test, routers from ASUS, Netgear, ZTE, Aruba,
Cisco Meraki, and certain models of TP-LINK, Mercury, and
Huawei take this recommendation by default, thus defending
against our attack. However, this strategy may introduce addi-
tional performance overhead and potentially impact the relia-
bility of networking for certain applications (e.g., OpenVPN
running on the router may be affected as the reverse path
validation may interfere with packet deliver

Source:

[2404.04601] Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks

https://www.ndss-symposium.org/wp-content/uploads/2024-419-paper.pdf

 

[Justinh]

Interesting. The high-end vendors sometimes advertised here are vulnerable and the ASUS-es are not.

 

[sfx2000]

Interesting read...

Thx for sharing..

 

[RMerlin]

Interesting. The high-end vendors sometimes advertised here are vulnerable and the ASUS-es are not.

I couldn't help but notice Ubiquiti in there indeed...

Reverse path validation is frequently disabled for VPN usage, that might be why.

 

[jerry6]

Interesting. The high-end vendors sometimes advertised here are vulnerable and the ASUS-es are not.

except the rtax89x and rtax 57x

 

[sfx2000]

I couldn't help but notice Ubiquiti in there indeed...

Reverse path validation is frequently disabled for VPN usage, that might be why.

Reading into the academic paper, it's mostly around nf_conntrack configuration - so mitigation might not be so hard to accomplish...

For others, the Kernel uses the netfilter connection tracker for tracking the NAT/SNAT tables, along with the firewall - there can be optimizations done there to conserve memory and improve performance...

 

[RMerlin]

so mitigation might not be so hard to accomplish...

In Linux, reverse path filtering is managed through the /proc/sys/net/ipv4/conf/INTERFACE/rp_filter userspace interface.

Just write to that interface to enable/disable it. Asuswrt explicitely set it in its firewall configuration, someone with a different device with SSH access could also manually adjust it himself. Correct values are 0, 1 and 2 (I don't remember the difference between 1 and 2).

Just need to keep in mind the impact it might have on any VPN tunnel where you use policy routing.

 

[Justinh]

except the rtax89x and rtax 57x

?? those are shown as immune

 

[sfx2000]

In Linux, reverse path filtering is managed through the /proc/sys/net/ipv4/conf/INTERFACE/rp_filter userspace interface.

The issue discussed in the paper has nothing to do with VPN - it's netfilter and the connection tracker for NAT...

 

[RMerlin]

The issue discussed in the paper has nothing to do with VPN - it's netfilter and the connection tracker for NAT...

I'm specifically talking about reverse path filtering here, which is one of the mitigation methods they document.

 

[sfx2000]

I'm specifically talking about reverse path filtering here, which is one of the mitigation methods they document.

Direct from the paper...

The open-sourced router operating systems, i.e., OpenWrt and AsusWrt, both have related options to reduce CPU overhead, i.e., the nf_conntrack_tcp_no_window_check option in OpenWrt and the ip_conntrack_tcp_be_liberal option in AsusWrt. These options are set to true by default, and once they are set, Netfilter will not perform TCP window tracking in contrast to the original Linux kernel. The difference between the two systems is that OpenWrt does not check the sequence number of the packet at all, while AsusWrt only checks if the sequence number is beyond the current sequence number in a 2G space. Besides, we found most of the routers in the market also disable the TCP window tracking strategy by default and have similar behaviors to the two systems above

 

[sfx2000]

I couldn't help but notice Ubiquiti in there indeed...

Something about glass houses and stones... please be careful where they are casually tossed...

I found this interesting because it crossed SDK's from the chipset vendors, and some OEM's fixed it, and some OEM's implemented the bug from upstream

Not your problem, looks like Asus already took care of it for you... and not an issue for OpenWRT on MASTER...

In any case - the BSP/SKD's from the chipset vendors may introduce risks in the name of optimization...

 

[ColinTaylor]

Direct from the paper...

VII. COUNTERMEASURES

Reverse Path Validation. Another effective measure to prevent the attack is to adopt the RFC 3704 recommendation, which suggests using the strict mode to filter out forged packets. In our test, routers from ASUS, Netgear, ZTE, Aruba, Cisco Meraki, and certain models of TP-LINK, Mercury, and Huawei take this recommendation by default, thus defending against our attack. However, this strategy may introduce additional performance overhead and potentially impact the reliability of networking for certain applications (e.g., OpenVPN running on the router may be affected as the reverse path validation may interfere with packet delivery [38]).

 

[sfx2000]

I'm specifically talking about reverse path filtering here, which is one of the mitigation methods they document.

that's one approach - but let's look at TCP Window Tracking - and that's all in nf_conntrack and management there.

I appreciate belt and suspenders approaches... reverse path filtering is a good thing

Where things can get weird - network fast-past offloads...

 

[coxhaus]

That sure is a lot of routers vulnerable.

So, is fast path vulnerable if you use it in ASUS routers or other routers? It is used to make slow routers faster and does something with a switch chip. A lot of people don't use QoS because it kills fast path and slows down their router. I know with QoS you are mainly trying to manipulate UDP but sometimes you need to change TCP. I know what network packet sequencing is but I am not sure what fast path is in terms of what is being done to speed things up or I should I say not being done to make it faster. Maybe skipping some network layers.

 

[sfx2000]

@coxhaus - the fast path is layer 2 with rules defined for the fast path...

Going up the stack where QoS generally lives, it's not really a problem, other than ECN if both ends of the link support it.

NSS/CTF/Runner (the fast path hardware-offloads) - skipping networks layers, yes, I agree...

fast-path and QoS are at odds - fast path says no packets/frames are discarded, QoS says we can discard frames at any time...

The more I read into this report - one thing that wasn't disclosed was the client behavior itself - randomization is present there - because of security.