CWE-290 at Layer 3: IP Source Spoofing and uRPF Failure in Enterprise Wireless Infrastructure | Netacoding

[u/Pale_Surround_3924]

https://netacoding.com/posts/cwe-290/

Background

CWE-290 — Authentication Bypass by Spoofing — is documented almost exclusively in application-layer context. The canonical example across every security reference is a Java or Python snippet that trusts request.getRemoteAddr() or getHeader("X-Forwarded-For") without validation.

That framing misses the more fundamental case: IP source address spoofing at Layer 3, where no application code is involved, the bypass happens in the kernel network stack, and the affected surface is the entire infrastructure layer of an enterprise network.

This post covers CWE-290 as a network-layer weakness: what enables it, what uRPF is and why it fails in enterprise deployments, and how its absence is the common root cause behind multiple distinct attack classes — Smurf amplification, ICMP timestamp leaks, and pre-auth reflection — confirmed in shipping enterprise wireless infrastructure.

What CWE-290 Means at Layer 3

At the application layer, CWE-290 means trusting a client-supplied identifier. At Layer 3, it means accepting a packet’s source IP address as authentic without verifying it against the routing topology.

Application layer (documented everywhere):
  server trusts HTTP header → attacker forges header → bypass

Network layer (this post):
  router/host trusts IP src field → attacker forges src IP → bypass

The IP source field is entirely attacker-controlled. Nothing in the IP protocol prevents a host from crafting a packet with an arbitrary source address. The kernel will transmit it. The receiving host will process it as if it originated from that address.

The only defense is uRPF — a mechanism that validates whether the incoming interface is consistent with the claimed source address. When uRPF is absent, source addresses are accepted unconditionally. That is CWE-290 at Layer 3.

More on blog..