Network Security Threats and Attack Models

A threat model is a formal statement of what an adversary can observe, what an adversary can do, and what the defender is trying to protect (confidentiality, integrity, authenticity, availability). Without an explicit threat model, claims like "this system is secure" are meaningless — secure against whom, doing what? Network security threats are best organized along two axes: whether the adversary is passive or active, and whether the adversary is on-path (can see and manipulate packets between the legitimate parties) or off-path (must inject packets blindly, guessing sequence numbers or ports). A passive attacker only observes traffic — tapping a shared Wi-Fi channel, reading unencrypted packets at a compromised router, or performing traffic analysis on encrypted metadata. Passive attacks violate confidentiality but do not modify anything, so they are undetectable by the victim unless the channel itself reveals monitoring (e.g., ARP table anomalies). Eavesdropping and sniffing are the classic passive attacks: a network interface card in promiscuous mode captures every frame on a shared segment, regardless of destination address. An active attacker injects, modifies, blocks, or replays packets. Spoofing forges a source identity — an IP address, a MAC address, a DNS response, an email "From" header — so that the victim's trust decisions are based on false information. A man-in-the-middle (MITM) attack is the active attack in which the adversary sits logically between two parties, relaying (and selectively altering) their traffic, so that each believes they are talking directly to the other. Injection attacks operate at a different layer: instead of forging network identity, they exploit an application's failure to distinguish data from executable instructions, as in SQL injection or cross-site scripting over HTTP. The canonical formal adversary for cryptographic protocol analysis is the Dolev-Yao model: the adversary controls the entire network, can read, delete, delay, duplicate, and inject any message, but cannot break the underlying cryptographic primitives (cannot decrypt without the key, cannot forge a valid signature without the private key). This is a deliberately pessimistic, worst-case model — a protocol proven secure against a Dolev-Yao adversary is secure against any real-world network attacker with equivalent computational limits, because the model assumes the attacker already has full control of the wire.

Eavesdropping: mechanism

On a shared broadcast medium (classic Ethernet hubs, unencrypted Wi-Fi), every frame reaches every network interface on the segment; a normal NIC discards frames not addressed to it, but a NIC in promiscuous mode delivers all frames to the OS. On switched networks, an attacker must actively redirect traffic first (e.g., ARP spoofing, MAC flooding) before passive sniffing works, which blurs the line between "purely passive" and "active setup, passive read." ```

# Passive sniffing loop (conceptual) set interface to promiscuous mode for each frame captured on the wire: if frame.ethertype == IPv4 or IPv6: packet = parse(frame.payload) if packet.protocol == TCP and packet.dst_port == 80: log(extract_plaintext_payload(packet)) # cleartext HTTP is fully readable else if is_TLS(packet): log(packet.metadata) # SNI, sizes, timing -- traffic analysis only ``` Defense: encryption. TLS and Secure Channels ensures the payload is ciphertext indistinguishable from random bits to anyone without the session key, so the `extract_plaintext_payload` branch above yields nothing useful — but metadata (destination IP, packet sizes, timing, and historically the SNI field) may still leak information even under TLS, which is why traffic analysis remains a live research area.

Spoofing: mechanism

IP spoofing sets the source address field of an outgoing packet to a value the sender does not own. Because IP is a connectionless, best-effort protocol with no built-in source authentication, routers forward such packets exactly as if they were legitimate, unless egress/ingress filtering (BCP 38) is deployed by an ISP. ``` function send_spoofed_packet(fake_source_ip, target_ip, payload): packet.src = fake_source_ip # forged packet.dst = target_ip packet.payload = payload packet.checksum = compute_checksum(packet) # checksum only detects corruption, not forgery transmit(packet) ``` Spoofing is dangerous precisely because most receivers historically trusted the source IP for logging, access control lists, or reflected amplification (spoof the victim's IP as the source when querying an open DNS resolver, and the large response floods the victim — the seed of many DDoS Attacks and Mitigation techniques).

ARP spoofing (on a LAN) forges Address Resolution Protocol replies, telling a victim host that the attacker's MAC address corresponds to the gateway's IP address: ``` function arp_spoof(victim_ip, gateway_ip, attacker_mac): loop every few seconds: send_arp_reply(to=victim_ip, claim="gateway_ip is at attacker_mac") send_arp_reply(to=gateway_ip, claim="victim_ip is at attacker_mac")

# victim and gateway now route all traffic through the attacker unknowingly ```

Man-in-the-middle: mechanism

A MITM attack requires two things: interception (the attacker's traffic path is between the two legitimate endpoints) and impersonation (each endpoint believes it is talking directly to the other). ARP spoofing achieves interception on a LAN; a rogue Wi-Fi access point or a compromised router achieves it on a wider scale; a compromised or coerced Certificate Authority achieves it against TLS itself. ``` function mitm_relay(client_conn, server_conn): spawn thread: while message = client_conn.receive(): log_or_modify(message) server_conn.send(message) # attacker sees and can alter every message spawn thread: while message = server_conn.receive(): log_or_modify(message) client_conn.send(message) ``` Against plaintext HTTP, this is trivial and total: the attacker sees and can rewrite everything. Against TLS, the attacker cannot simply relay bytes — it must present a certificate the client will accept for the server's domain. This is why certificate validation (chain of trust to a root CA, hostname matching, revocation checking) is the single most important line of defense against MITM on the modern web; a MITM against properly validated TLS requires either a compromised CA, a client that ignores certificate warnings, or exploitation of a downgrade attack (forcing the connection to a weaker protocol version or cipher suite).

Injection: mechanism

Injection attacks exploit an application that concatenates untrusted user input directly into a command interpreter — SQL, shell, HTML/JavaScript — without separating data from code. ```

# Vulnerable (string concatenation) query = "SELECT * FROM users WHERE username = '" + input_username + "' AND password = '" + input_password + "'"

# Attacker sets input_username to: admin' --

# Resulting query:

# SELECT * FROM users WHERE username = 'admin' --' AND password = '...'

# The "--" comments out the password check entirely. ``` The fix is parameterized queries / prepared statements, which send user input as data through a separate channel from the SQL command template, so the database engine never re-parses it as syntax: ```

# Safe (parameterized) statement = prepare("SELECT * FROM users WHERE username = ? AND password = ?") execute(statement, [input_username, input_password]) ``` Cross-site scripting (XSS) is the HTML/JavaScript analogue: if a web application echoes user input into a page without encoding special characters, an attacker can submit `` as a comment, and every visitor's browser executes it in the context of the trusted site, exfiltrating session cookies to the attacker — a direct violation of the same-origin trust the HTTP and the Web security model relies on.

Network security claims are usually stated as computational security rather than classical algorithmic complexity: a defense is "correct" if breaking it requires resources infeasible for a bounded adversary, not literally impossible.

Eavesdropping cost. Passive sniffing on a shared medium is $O(1)$ per frame captured — the attacker does no computation beyond parsing. The defender's countermeasure, encryption, shifts cost onto the attacker: breaking a modern symmetric cipher (AES-128) or asymmetric scheme (RSA-2048, or the discrete-log problem underlying Diffie-Hellman key exchange) by brute force costs roughly $2^{128}$ or the sub-exponential general number field sieve time respectively — both far beyond feasible computation with current or foreseeably projected hardware. Correctness here rests on well-studied hardness assumptions, not a proof of absolute impossibility; this is why key sizes are periodically increased as algorithms and hardware improve.

Spoofing and blind injection cost. For an off-path attacker to inject a forged TCP segment into an established connection, it must guess both the correct 4-tuple (source/destination IP and port) and a 32-bit sequence number landing inside the receive window. With random initial sequence numbers uniformly distributed over $2^{32}$ values and a receive window of size $W$, a single blind guess succeeds with probability roughly $W / 2^{32}$. Older systems with small windows and predictable (incrementing) initial sequence numbers made this attack practical in the 1990s; modern operating systems use cryptographically random ISNs specifically to push this probability toward $0$, which is a direct, quantifiable security engineering response to a known weakness — the correctness argument is literally a probability calculation over the sequence-number space.

MITM against TLS. Assuming the cryptographic primitives are secure (Dolev-Yao's "unbreakable crypto" assumption) and the client correctly validates the certificate chain, a MITM cannot succeed without possessing a private key that chains to a CA the client trusts. The correctness of this defense reduces to: (1) the CA correctly verified domain ownership before issuing a certificate, and (2) the client's certificate validation logic has no bypassable bug. Both are engineering assumptions, not mathematical guarantees — which is exactly why CA compromises (e.g., DigiNotar, 2011) and validation bugs (e.g., "goto fail" in early iOS/macOS TLS stacks) have historically produced real, exploitable MITM vulnerabilities despite mathematically sound underlying cryptography.

Injection attacks. These are not a cryptographic weakness at all — they are a parsing correctness failure. The formal argument for why parameterized queries fix SQL injection is a type-safety argument: once user input is passed as a typed data value through the database driver's binding API, the database's SQL parser never re-tokenizes it as syntax, so no string value can escape into the command grammar, regardless of its contents. This is provably sound as long as the driver's binding implementation itself has no bugs — the defense converts an unbounded input-validation problem into a fixed, auditable API contract.

Honest tradeoffs. Every defense discussed shifts cost or trust rather than eliminating risk: encryption trades computation for confidentiality; certificate validation trades a centralized trust hierarchy (CAs) for identity assurance; random sequence numbers trade a small chance of collision for resistance to blind spoofing; parameterized queries trade a small API discipline cost for eliminating an entire vulnerability class. None of these are absolute guarantees — each has an explicit assumption whose failure reopens the attack.

Trace a concrete MITM attack against an HTTP (not HTTPS) login form on a shared coffee-shop Wi-Fi network, step by step.

Two properties make this attack complete and dangerous: it required zero cryptography to break (plaintext HTTP gives the attacker everything for free once step 3 succeeds), and it is entirely invisible to the victim because the attacker relays every message faithfully in both directions after copying it — nothing about the user experience changes. Now trace the same scenario with HTTPS enforced and a correctly configured browser:

The contrast is the entire lesson: interception (ARP spoofing) succeeded identically in both cases — the network-layer vulnerability was unchanged. What differed was whether the application layer enforced cryptographic identity checking. This is precisely why TLS and Secure Channels is not optional hardening but the load-bearing defense against MITM on the modern web.

:::physicist|Danny Dolev and Andi Yao|active from late 1970s|formal modeling of network adversaries Dolev and Yao's 1983 paper formalized the "attacker controls the network" model now bearing their names, giving cryptographic protocol designers a precise, worst-case adversary against which security proofs could be constructed and checked.

Every browser padlock icon depends on the defenses catalogued here: certificate validation against MITM, TLS against eavesdropping, and HSTS against downgrade attacks are all direct engineering answers to the threat taxonomy in this article. Public Wi-Fi security tools, corporate network monitoring, and intrusion detection systems are built explicitly to detect ARP spoofing and abnormal traffic patterns consistent with sniffing or MITM positioning. Web application firewalls and ORM frameworks exist largely to prevent the injection class of attacks at scale across millions of deployed applications. DNS security extensions (DNSSEC) exist to stop DNS spoofing, a direct application of the identity-forgery threat model to name resolution. Understanding this threat taxonomy is also the prerequisite for reasoning about Firewalls and Packet Filtering (which restrict which packets are even allowed to reach a host), Virtual Private Networks (which extend encrypted, authenticated tunnels across untrusted networks precisely to neutralize eavesdropping and MITM on the path), and DDoS Attacks and Mitigation (which frequently begins with spoofed-source reflection attacks of exactly the kind described above).

Ask the tutor: How would you extend the Dolev-Yao threat model to formally analyze a Wi-Fi network using WPA2?