Source-linked AI summary
Cross User/App Network Attacks - Hijacking TCP Connections and DNS Cache Poisoning via a Malicious User/App (Extended Version)
Tamir Shahar, Amit Klein
TL;DR
The paper challenges the assumption that randomized TCP and DNS state defeats off-path attacks by studying collaboration between a malicious local application and a remote off-path adversary. It develops leakage-based inference techniques and demonstrates TCP hijacking and DNS cache poisoning across multiple operating systems and deployment settings.
Problem
Off-path TCP and DNS attacks rely on unpredictable sequence numbers and UDP source ports, but it is unclear whether unprivileged local code can expose enough connection state to defeat these defenses.
Method
The paper combines a malicious unprivileged application with a remote off-path adversary and uses socket APIs, IP options, cBPF, procfs, and OS-specific ISN properties to infer connection state.
Results
The authors demonstrate TCP connection hijacking and DNS cache poisoning across Linux, Android, Windows, macOS, and iOS, including realistic deployment settings.
Takeaways & Limitations
The findings show that residual leakage at the application–OS boundary can bypass core TCP and DNS defenses without privileged access or packet capture.
Takeaways & Limitations
The Linux systemd-resolved attack is slowed and made less reliable because coarse sampling requires attacking both the loopback and recursive-resolver ports.
Abstract
from arXiv · showhide
Off-path network attacks against TCP and DNS (over UDP) client-server connections are generally considered impractical nowadays, due to built-in security features in these protocols, e.g. randomized TCP (initial) sequence numbers and randomized UDP source ports, respectively. In this work, we refute this presumption by demonstrating that an unprivileged malicious application running on the client (but practically off-path), when combined with a remote off-path adversary, can enable powerful network attacks against such connections. We show how such a local--remote collaboration between the malicious application and a remote adversary allows inference of sensitive connection state, including TCP sequence numbers and DNS stub-resolver UDP source ports. Our attacks exploit standard socket API calls such as bind(), protocol mechanisms such as IP options, and operating system features such as cBPF and procfs to infer the TCP initial sequence number (ISN) and the UDP source port in use by the connection of interest. Specifically, we take advantage of certain properties of the ISN generation algorithm as implemented in major operating systems. We demonstrate TCP connection hijacking in Linux, Android, Windows, macOS and iOS, and DNS cache poisoning against Windows, Android and the popular systemd-resolved DNS stub resolver in Linux. We evaluate our techniques across multiple operating systems and realistic deployment settings, including environments behind port-preserving NAT-integrated routers. We disclosed our techniques to Microsoft, Apple, Linux and Google, which led to the release of several patches.
1 Introduction
The paper asks whether an unprivileged local application collaborating with a remote off-path adversary can infer connection state despite OS isolation, and answers yes with practical TCP hijacking and DNS cache poisoning attacks.
- 1.1 Motivation: The threat is realistic because modern devices routinely run potentially untrusted third-party applications alongside processes with different trust levels.The paper notes that 33.74% of surveyed apps explicitly enable HTTP connections, with observed HTTP traffic in 2,790 of 35,000 apps.
- 1.1 Motivation: The research question is whether ordinary OS interfaces and network-stack observations reveal enough connection state for these attacks.
- 1.1 Motivation: The paper demonstrates practical TCP connection hijacking and DNS cache poisoning by combining an unprivileged malicious application with a remote off-path adversary.The attacks target other applications and users on the same device.
- 1.1 Motivation: Shared OS behavior can collapse the effective entropy of protocol defenses even when malicious code cannot observe packets directly.
- 1.2 Our contribution: The paper identifies TCP ISN and UDP source-port leakage through IP options, cBPF, bind calls, and bind(0), then evaluates end-to-end attacks across realistic settings.
2 Background
TCP and DNS use randomized state to authenticate and match traffic, while OS facilities such as cBPF and IP options expose mechanisms that the paper studies as leakage channels.
- 2.1 TCP Protocol: TCP endpoints exchange 32-bit ISNs during the handshake, so inferring a client ISN and its 4-tuple can enable server impersonation and packet injection.
- 2.2 cBPF: Unprivileged cBPF filters can truncate packets before delivery to user space, providing a channel for leaking information despite lacking direct communication from kernel to user space.
- 2.3 IP Options: IP options provide optional packet-header fields, including source-routing mechanisms that can influence packet paths through specified locations.
- 2.4 DNS: DNS responses are matched using a TXID and UDP 4-tuple, while stub-resolver caching lets accepted responses influence later queries.
- 2.4 DNS: Randomized DNS TXIDs and UDP source ports make off-path forgery difficult, but learning them enables forged responses that poison the resolver cache.
3 Related Work
Prior attacks infer or manipulate network state through shared counters, network infrastructure, VPNs, fragmentation, or port exhaustion; this work instead uses local interaction with the victim host without exhausting ports.
- 3 Related Work: Earlier collaborative attacks validated TCP sequence-number guesses through victim-side side channels, but several platform-specific techniques have been mitigated.
- 3 Related Work: Other TCP hijacking methods exploit shared IPID or challenge-ACK mechanisms, PMTUD state, VPN tracking, or IPv4 fragmentation under deployment-specific assumptions.
- 3 Related Work: Unlike prior approaches based on externally observable network behavior, this work infers state through local interaction with the victim host.
- 3 Related Work: Prior DNS attacks predict or exhaust UDP source ports, but port exhaustion can disrupt other applications that depend on ephemeral ports.
- 3 Related Work: The paper distinguishes its approach from static vulnerability detection and from prior port-exhaustion attacks by inferring source ports without exhausting the port space or disrupting normal operation.
4 Threat Model
The threat model pairs an unprivileged victim-host application with an off-path remote node that can spoof packets, targeting TCP connections and DNS stub-resolver queries under stated deployment assumptions.
- 4 Threat Model: The adversary consists of an unprivileged malicious application on the victim machine cooperating with an off-path Attacker Remote Node that cannot observe traffic.
- 4 Threat Model: The remote node is assumed able to craft packets with arbitrary headers and spoof source IP addresses where the underlying network permits IP spoofing.
- 4 Threat Model: TCP attacks target connection establishment for a known destination service, with the remote node either outside or co-located within the victim’s switched local network.
- 4 Threat Model: DNS attacks target a stub resolver with a known upstream resolver, and the malicious application can trigger attacker-chosen domain queries.
- 4 Threat Model: The default DNS setting excludes DNSSEC validation, encrypted DNS, and DNS cookies, while port-preserving NAT is common in measured IPv4 networks.
5 ISN Generation Algorithm
The paper analyzes how TCP initial sequence numbers are generated across major operating systems and shows that their structure can weaken protection against prediction. Non-Windows systems use a fixed keyed-hash component plus a time-dependent offset, while Windows adds more complex evolving state; correlative ports further expose predictable relationships.
- Non-Windows ISN generation: The standard ISN construction combines a keyed hash over the connection 4-tuple with a time-dependent offset and a boot-generated secret key.The timestamp has 64 ns resolution in the described Unix-like implementation, and the key is a 128-bit secret unavailable to user space.
- Non-Windows ISN generation: This structure significantly reduces ISN entropy from the attacker’s observation point and enables prediction under certain conditions.The keyed hash protects independent 4-tuples, but its constancy for a fixed 4-tuple leaves the time offset as the changing component.
- macOS and iOS: macOS and iOS use an almost identical XNU ISN-generation algorithm, with a timestamp resolution of 128 ns.The same relation between two ISNs applies on these platforms.
- Windows: Windows derives ISNs from a keyed hash over the 4-tuple plus an offset influenced by time, recent connection activity, and likely randomness.The offset is maintained through four internal ISN-generator buckets, each with evolving state.
- Windows: Approximately 25% of candidate ports are correlative with a given source port, producing nearly constant ISN differences across repeated measurements.Correlative ports map to the same Windows ISN-generator bucket and are used within a sub-millisecond interval.
- Non-Windows ISN generation: For a fixed 4-tuple, the keyed-hash component remains constant, so one observed ISN and timestamp can support inference of a future ISN.The attack therefore reduces to obtaining one reference ISN together with its timestamp through indirect leakage mechanisms.
6 TCP Hijacking Attack Details
The attack combines local inference of TCP connection state with remote spoofed-packet injection to hijack a victim’s HTTP connection. It builds port–ISN–timestamp references, identifies the target port and timing, estimates the ISN, and races forged packets against the legitimate handshake.
- The malicious application and remote adversary remain off-path: the application infers state locally while the remote adversary injects packets, and may capture ISNs through IP options.The collaboration uses complementary capabilities rather than direct traffic observation.
- Preprocessing: A per-port reference table stores sampled ISNs and timestamps for the target four-tuple, generated through repeated connect() attempts and side-channel leakage.The table assumes the victim’s source IP remains fixed during the attack.
- The application detects the newly allocated client port and obtains a nearby initiation timestamp using OS connection-state interfaces or ephemeral-port prediction.Linux /proc/net/tcp exposes active connection information, while port-allocation patterns provide an alternative prediction mechanism.
- The attacker infers the target ISN from the client port and connection timing, then sends spoofed packets accepted as part of the legitimate connection.The inferred ISN is a range of candidates, so the remote adversary brute-forces those values during the handshake.
- IP-options method: IP options provide a cross-platform alternative by routing initiation packets through an attacker-controlled relay that observes the transmitted SYN and its ISN.Many routers filter or ignore IP options, so the technique is also demonstrated with the relay on the victim’s local switched network.
- cBPF ISN leakage: The cBPF method reconstructs the 32-bit ISN by leaking one acknowledgment-number byte at a time from response packets and recording the initial-SYN timestamp.Four iterations over the same connection recover the four bytes.
7 DNS Cache Poisoning Attack details
The attack infers a stub resolver’s UDP source port and races forged DNS responses against legitimate replies to poison cached records. Linux’s record-based caching enables malicious records to be introduced through forged CNAME chains, whereas Android and Windows impose additional constraints on query timing, cache behavior, or TXID guessing.
- Linux attack: Linux systemd-resolved separately caches resource records, allowing a forged CNAME chain to insert malicious records unrelated to the queried domain.This record-based model differs from query-based caching and permits trusted additional records to be cached.
- Source-port discovery: The attacker identifies the resolver’s UDP source port using procfs, exhaustive bind probing, or bind(0) sampling before brute-forcing the DNS transaction ID.Linux source-port discovery methods differ in coverage and speed; the Linux UDP port-selection method does not use the TCP ephemeral-port algorithm.
- Linux attack: A forged response with the correct TXID and source port can poison example.com, redirecting later connections to an attacker-controlled address.The attack delays the genuine response, injects spoofed replies, and relies on the stub resolver accepting the forged validation fields.
- Android attack: Android’s query-based cache requires poisoning the actual target-domain query, leaving less time because the legitimate response cannot be delayed through an attacker-controlled domain.A full bind scan takes about 179 ms versus typical 50–100 ms DNS response time, so the attacker splits the race window between port probing and TXID guessing.
- Windows attack: Windows permits only one TXID candidate per attempt because an incorrect TXID response prevents the subsequent valid answer from being cached.The resolver terminates the outstanding query after five incorrect responses, while even one incorrect response blocks caching of the valid answer.
8 Experiments
The experiments evaluate TCP hijacking across five operating systems and DNS cache poisoning across Linux, Android, and Windows using multiple preprocessing, port-discovery, and deployment configurations. Results include successful demonstrations, platform-specific constraints, and substantial differences in preprocessing cost.
- Experimental scope: TCP hijacking was evaluated on Linux, Android, macOS, iOS, and Windows, while DNS cache poisoning was evaluated on Linux, Android, and Windows.The TCP experiments used cBPF or IP-options preprocessing; Linux DNS experiments compared procfs, bind-all, and bind(0) source-port discovery.
- Preprocessing comparison: IP-options preprocessing reduced setup cost to 22 seconds and about 2 MB of traffic, compared with 305 seconds and about 290 MB for cBPF preprocessing.These measurements were reported for the preprocessing comparison in the experimental setup.
- Windows setup: Windows preprocessing took 1300 seconds and generated approximately 1.53 GB of traffic because each target port required finding a correlated port through hundreds of packets.The experiment used the Windows ephemeral-port range 49152–65535 and IP-options preprocessing.
- Windows validation: The Windows pairwise experiment evaluated every pair from two sets of 200 candidate source ports to test whether ISN differences remained stable across trials.Stable differences classified port pairs as correlative, validating the platform-specific correlation behavior used in the attack.
- DNS poisoning experiments: Repeating a Windows DNS TXID guess reduced one attack round from about 55 ms to 7.4 ms, while transmitting only five packets per attempt.The setup used RTT_victim↔resolver = 51 ms and RTT_victim↔ARN = 5 ms; five incorrect TXIDs trigger early termination.
9 Discussion
The discussion identifies cross-application leakage channels and proposes mitigations targeting interfaces, port allocation, ISN generation, and IP options.
- 9.1 Attack Mitigation: Per-user filtering of /proc/net can limit cross-user connection-state leakage while preserving access for applications.Modern Android already applies stronger restrictions that block regular applications from accessing /proc/net.
- 9.1 Attack Mitigation: Rate-limiting bind() and connect() calls per user can reduce port-inference probing that process or thread spawning might otherwise bypass.The proposal permits exemptions for privileged processes and can be enforced separately for UDP and TCP.
- 9.1 Attack Mitigation: Partitioning ephemeral ports between privileged and unprivileged applications can prevent port exhaustion and inference attacks against privileged services.A per-user limit on simultaneously allocated TCP and UDP ports is offered as a simpler mitigation for port exhaustion alone.
- 9.1 Attack Mitigation: Removing deterministic increments and strengthening randomization would address predictable Linux TCP ephemeral-port selection.The described algorithm uses small port increments for consecutive connections to the same destination.
- 9.1 Attack Mitigation: Including the user identifier in ISN computation can prevent sequence-number correlation between users with otherwise identical connection parameters.The proposed form is ISN = H_k(4-tuple, UID) + time mod 2^32.
- 9.1 Attack Mitigation: Blocking source-routing IP options and requiring elevated privileges to send LSRR or SSRR packets mitigates the associated TCP leakage mechanism.The recommendation applies to TCP traffic across the Internet.
10 Conclusion
The paper shows that an unprivileged co-located application collaborating with a remote adversary can bypass TCP and DNS defenses through OS and network-stack leakage. It develops cross-platform attacks, releases reproducibility artifacts, and reports coordinated vendor disclosure and Linux patches.
- 10 Conclusion: The attack model bypasses TCP and DNS defenses through residual leakage from operating-system interfaces and network-stack behavior.The malicious application is low privilege and co-located with the target, while the adversary remains remote and off-path.
- 10 Conclusion: The techniques infer TCP ISNs and DNS source ports without privileged access or packet capture, enabling TCP hijacking and DNS cache poisoning across five operating systems.The evaluation covers Linux, Android, macOS, iOS, and Windows.
- 10 Conclusion: The artifact reproduces three Linux attacks, including TCP hijacking using cBPF- and IP-options-based preprocessing techniques.Docker-based setup instructions, scripts, and evaluation guidance are included.
- 10 Conclusion: Linux maintainers deployed two patches addressing the cBPF- and IP-options-based TCP hijacking mechanisms.The disclosure status is summarized in Table 7.
B.2 Stakeholder Analysis
The stakeholder analysis identifies operating-system vendors and end users as the main affected parties, while domain owners are not directly affected. Application servers may observe anomalous traffic but are not directly compromised.
- B.2 Stakeholder Analysis: End users running TCP applications or stub resolvers may be affected, although automatic updates and coordinated disclosure reduce the exposure window.The paper allows 60 days between patch availability and publication.
- B.2 Stakeholder Analysis: Domain owners are not directly affected because the DNS attacks exploit operating-system behavior rather than resolver flaws.The attacks are expected to become infeasible once operating-system patches are deployed.
- B.2 Stakeholder Analysis: Application servers are not directly compromised but may be temporarily impersonated and receive anomalous packets during TCP hijacking.Examples include out-of-window acknowledgments and unexpected resets; normal operation is expected after client-side patches.
D Comparison with Prior Work
Compared with prior work, this paper introduces OS-level primitives for inferring TCP and DNS connection state without several earlier deployment requirements. It supports contemporary Linux, Android, Windows, macOS, and iOS under one collaborative attacker model.
- D Comparison with Prior Work: Earlier collaborative TCP attacks on Android, iOS, and macOS relied on global counters that were mitigated, while this work also demonstrates Windows attacks and considers DNS poisoning.The comparison notes that prior Linux approaches may exhaust TCP ports.
- D Comparison with Prior Work: Prior OS-level side-channel studies focused on activity inference, whereas this work uses leaked network state for practical TCP hijacking and DNS cache poisoning.The comparison includes cross-application and cross-process activity-inference work.
- D Comparison with Prior Work: Unlike prior TCP techniques, the attacks do not depend on global IPID counters, IPv4 fragmentation, wireless visibility, VPN deployment, or a controlled local-network machine.The comparison states that the attack instead requires only an unprivileged application on the victim host.
- D Comparison with Prior Work: Unlike prior DNS cache-poisoning approaches, the work infers the resolver source port without UDP-port exhaustion, fragmentation, weak kernel randomness, or browser-mediated exhaustion.The comparison targets the local stub resolver without fragmentation and uses local OS interaction.
- D Comparison with Prior Work: The work introduces new OS-level primitives for inferring TCP ISNs and DNS source ports under a shared local-malicious-app and remote-adversary model.It combines TCP hijacking and DNS cache poisoning across contemporary platforms.
E Analysis of Ephemeral Port Sampling via bind(0)
The analysis models repeated bind(0) calls as sampling ephemeral ports and shows that O(L log L) samples provide near-complete coverage with high probability, while leaving residual false negatives.
- Sampling model: The analysis approximates kernel port allocation as independent uniform sampling across L available ephemeral ports, despite the actual policy not being guaranteed uniform.N denotes independent bind(0) invocations, and L denotes available ephemeral ports.
- Coverage analysis: The derivation builds from the probability that a port is missed in one trial and remains unselected across N independent trials.It then extends single-port coverage to all L ports under an independence approximation.
- Full coverage: With N = αL log L for α > 1, the probability of full port coverage approaches 1 rapidly as L grows.The approximation applies for α > 1 and sufficiently large L.
- Implications: O(L log L) bind(0) samples achieve near-complete ephemeral-port coverage with high probability, although coverage is not guaranteed.Ports absent from the sample are likely in use, but randomness can still produce false negatives.
F.1 Timing Side Channels in System Calls
The section combines reverse engineering and black-box experiments to analyze TCP ISN generation and timing-related behavior across major operating systems. It identifies exploitable structure in Windows ISNs but leaves the complete offset-update mechanism unresolved.
- Timing side channels: Repeated bind() calls showed occasional latency spikes plausibly associated with contention during concurrent kernel port allocation.The proposed explanation involves contention on shared kernel resources such as allocation locks.
- Methodology: The methodology combines source-code review, static binary analysis, dynamic kernel debugging, and black-box network experiments.Windows analysis additionally used IDA Pro and WinDbg to trace TCP connection-establishment paths and values.
- Platform coverage: The analysis covers Linux and inherited Android logic, XNU-based macOS and iOS, and the closed-source Windows TCP/IP stack.Linux analysis followed secure TCP sequence-generation functions, while macOS and iOS share the analyzed XNU networking stack.
- Windows ISN analysis: Windows ISNs derive from a keyed hash of the connection 4-tuple plus an evolving offset tied to time, recent activity, and per-bucket state.The analysis did not fully recover all details of the offset mechanism.
- Windows ISN experiments: Stable ISN relationships between certain source-port pairs, observed during short-interval connection experiments, identify correlative ports in Windows.The experiments fixed source and destination IPs and the destination port while varying source ports.
- Limitations: The Windows reverse-engineering analysis remains partial because the complete offset-update mechanism was not recovered.The authors identified the relevant function and several internal-state components, but further work is required.