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

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.

uRPF: The Defense Mechanism

Unicast Reverse Path Forwarding (uRPF) — defined in RFC 3704 — works by performing a reverse routing lookup on the source address of every incoming packet.

Packet arrives: IP(src=10.0.1.5, dst=10.0.2.1) on interface eth0

uRPF check:
  "What interface would I use to reach 10.0.1.5?"
  → routing table says: eth0
  → packet arrived on eth0
  → PASS

  "What interface would I use to reach 192.168.99.1?"
  → routing table says: eth1
  → packet arrived on eth0
  → FAIL → DROP (spoofed source)

uRPF Modes

Strict mode — the packet must arrive on the best-path interface for the source address. Most effective, requires symmetric routing.

ip verify unicast source reachable-via rx   # Cisco IOS strict

Loose mode — the source address must exist in the routing table on any interface. Less effective but compatible with asymmetric paths.

ip verify unicast source reachable-via any  # Cisco IOS loose

Feasible mode — source must be reachable via any feasible path in the FIB. Intermediate between strict and loose.

Without any uRPF mode enabled, the source address field of every incoming IP packet is trusted unconditionally. The router or host has no mechanism to detect or drop spoofed traffic.

Why uRPF Is Absent in Enterprise Wireless

Asymmetric Routing

Enterprise wireless infrastructure is built for redundancy and failover. Traffic from an AP to a controller may take a different physical path than traffic in the opposite direction. Strict uRPF drops legitimate traffic in these topologies.

AP → Switch_A → Controller    (forward path)
Controller → Switch_B → AP   (return path, different interface)

Strict uRPF on Controller:
  Packet from AP arrives on Switch_B interface
  uRPF: "Best path to AP is via Switch_A"
  → FAIL → legitimate packet dropped

The operational response is to disable uRPF rather than engineer symmetric paths. The security consequence is CWE-290.

Controller Architecture

Wireless controllers process CAPWAP tunnels, management traffic, and data plane traffic simultaneously across multiple interfaces. Source validation at the packet level would require per-interface FIB lookups for every packet — operationally expensive and operationally risky in high-throughput environments.

The Result

uRPF is disabled. Source addresses are unconditionally trusted. Any host on the same Layer 2 segment can claim to be any other host. Authentication based on source IP — at any layer — is bypassed.

CWE-290 as Root Cause: Three Attack Classes

When uRPF is absent, the following attack classes become viable. All three were confirmed in ArubaOS AOS-8 (Build 95415) via authorized static analysis and live packet capture.

Attack Class 1 — Smurf Amplification (CWE-290 + CWE-406)

Detailed in the previous post. The short version:

Without uRPF:
  Attacker sends: IP(src=VICTIM, dst=BROADCAST) / ICMP(type=8)
  Controller accepts src=VICTIM as legitimate (no uRPF check)
  Controller replies: IP(src=CONTROLLER, dst=VICTIM) / ICMP(type=0)
  VICTIM receives unsolicited ICMP flood

With uRPF strict:
  Controller: "Packet from VICTIM arrived on management interface"
  Controller: "Best path to VICTIM is via AP interface"
  → interface mismatch → DROP
  Amplification prevented at the source validation step

uRPF is not just a mitigation for Smurf. Its absence is the CWE-290 vulnerability that makes Smurf possible.

Attack Class 2 — ICMP Timestamp Information Leak (CWE-290 + CWE-200)

ICMP Timestamp Request (Type 13) asks the target for its current time. The response leaks milliseconds-since-midnight UTC — useful for timing attacks, session prediction, and network mapping.

Attacker sends:
  IP(src=TRUSTED_MGMT_IP, dst=CONTROLLER) / ICMP(type=13)

Without uRPF:
  Controller accepts src=TRUSTED_MGMT_IP as legitimate
  Controller replies with timestamp to TRUSTED_MGMT_IP
  Attacker sniffs response (same L2 segment)

With uRPF:
  Source validation: TRUSTED_MGMT_IP not reachable via this interface
  → DROP → no timestamp disclosed

The information leak (CWE-200) is gated by CWE-290: without source validation, any host on the segment can impersonate a trusted management address and elicit timestamp responses.

Attack Class 3 — Pre-Auth Reflection (CWE-290 + CWE-406)

ICMP processing occurs before any authentication check. Combined with missing source validation, an attacker can use any infrastructure device as a pre-authentication reflection point:

Scenario: reflect ICMP at a target using controller as intermediary

Attacker sends to controller:
  IP(src=TARGET, dst=CONTROLLER) / ICMP(type=8)

Controller (no uRPF):
  Accepts src=TARGET as valid
  Replies: IP(src=CONTROLLER, dst=TARGET) / ICMP(type=0)
  TARGET receives ICMP Reply it never requested — from CONTROLLER

No authentication required.
No session required.
No credentials required.

Packet-Level Verification

Test Setup

Machine A (attacker)   192.168.1.10  — sends spoofed ICMP
Machine B (observer)   192.168.1.20  — receives reflected traffic
Target device          192.168.1.1   — controller/infrastructure device

uRPF Absence Confirmation

1
2
3
4
5
6
7
8
9

from scapy.all import *

# Spoof source as Machine B, send to target
pkt = IP(src="192.168.1.20", dst="192.168.1.1") / \
      ICMP(type=8, id=0xCWE2, seq=290)

send(pkt, verbose=0)
print("[*] Sent spoofed ICMP Echo to target")
print("[*] If target replies to 192.168.1.20 → uRPF absent → CWE-290 confirmed")

Capture on Machine B:

1
2
3

tshark -i eth0 \
  -Y "icmp.type == 0 && ip.dst == 192.168.1.20 && ip.src == 192.168.1.1" \
  -T fields -e frame.number -e ip.src -e icmp.seq

Expected Output — CWE-290 Confirmed

frame 1: 192.168.1.1 → seq=290

Machine B receives an ICMP Echo Reply from the target for a request it never sent. The target accepted the spoofed source address and replied to it. uRPF check was not performed. CWE-290 is confirmed.

Expected Output — uRPF Present

(no output)

The target drops the packet at the source validation step. No reply is generated.

pcap Signature

A confirmed CWE-290 absence leaves the following packet pattern:

Frame N:   A → target   IP(src=B, dst=target)  ICMP type=8  id=X
Frame N+1: target → B   IP(src=target, dst=B)  ICMP type=0  id=X

Key indicators:

• B appears as ICMP Reply destination without having sent the Request
• The id field in Request and Reply matches, confirming reflection
• B has no corresponding type=8 in its own send queue

This pattern is definitively distinguishable from normal ICMP exchange and provides unambiguous evidence of source validation failure.

RFC Compliance Timeline

RFC 3704 defines uRPF and recommends deployment. It is a recommendation, not a requirement. Enterprise vendors are not obligated to implement it. Many do not.

Detection

Suricata Rules

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Detect spoofed ICMP — source not in expected subnet
alert icmp !$HOME_NET any -> $HOME_NET any (
  msg:"CWE-290 - ICMP from unexpected source";
  itype:8;
  threshold: type both, track by_src, count 5, seconds 10;
  sid:9000020; rev:1;
)

# Detect potential uRPF bypass — high-rate unsolicited replies
alert icmp $HOME_NET any -> $HOME_NET any (
  msg:"CWE-290 - Potential reflection victim: unsolicited ICMP replies";
  itype:0;
  threshold: type both, track by_dst, count 50, seconds 5;
  sid:9000021; rev:1;
)

Behavioral Indicators

Attacker-side signature:
  → ICMP Echo Requests where src ≠ sending host's actual IP
  → Source IP not present in ARP table for that interface
  → Requests sent to broadcast or infrastructure addresses

Victim-side signature:
  → ICMP Echo Replies received without corresponding Requests
  → Reply ID/Seq values not matching any active ping session
  → Multiple simultaneous sources sending type=0 to same dst

Mitigation

Network Layer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Linux — enable strict uRPF on all interfaces
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Linux — loose mode for asymmetric routing environments
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter

# Persist across reboots
echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
sysctl -p

! Cisco IOS — strict uRPF per interface
interface GigabitEthernet0/0
  ip verify unicast source reachable-via rx

! Cisco IOS — loose uRPF for asymmetric environments
interface GigabitEthernet0/0
  ip verify unicast source reachable-via any

Stack Level

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/*
 * Minimal uRPF check in packet processing path
 * Before forwarding or replying to any ICMP:
 */
static int validate_source_address(struct sk_buff *skb) {
    struct iphdr *iph = ip_hdr(skb);
    struct net_device *dev = skb->dev;
    struct rtable *rt;
    struct flowi4 fl4 = {
        .daddr = iph->saddr,  /* reverse lookup: src becomes dst */
    };

    rt = ip_route_output_key(dev_net(dev), &fl4);
    if (IS_ERR(rt))
        return -EHOSTUNREACH;  /* source not routable → drop */

    /* Strict: check if expected output interface matches input */
    if (rt->dst.dev != dev) {
        ip_rt_put(rt);
        return -EINVAL;        /* interface mismatch → drop */
    }

    ip_rt_put(rt);
    return 0;                  /* valid source */
}

Relationship to Adjacent Research

CWE-290 absence does not exist in isolation. In enterprise wireless infrastructure, it combines with:

CWE-406 (Insufficient Control of Network Message Volume) — missing source validation enables Smurf amplification, which exploits lack of rate limiting on reflected traffic.

CWE-200 (Exposure of Sensitive Information) — spoofed source allows impersonation of trusted hosts to elicit ICMP Timestamp responses, exposing system time.

CWE-345 (Insufficient Verification of Data Authenticity) — the same infrastructure that lacks uRPF may lack firmware signature verification, creating a consistent pattern of missing validation across protocol layers.

The common thread: source is not verified. Whether the source is an IP address, a firmware archive, or a checksum — the system accepts attacker-supplied identity without cryptographic or topological validation.

Summary

CWE-290 at Layer 3 is not an obscure edge case. It is the default state of enterprise wireless infrastructure, where uRPF is disabled for operational convenience and never re-enabled.

The consequences are not theoretical:

• Smurf amplification requires CWE-290 as a prerequisite
• ICMP information leaks are gated by source validation failure
• Pre-auth reflection uses infrastructure as an unwilling intermediary

The fix is a single configuration line. The deployment gap is measured in years. The mechanism is confirmed in shipping products in 2026.

uRPF is not optional. Its absence is a vulnerability.

Related Research

• RFC 3704 — Ingress Filtering for Multihomed Networks (uRPF)
• RFC 2827 — BCP 38 — Network Ingress Filtering
• RFC 1122 — Requirements for Internet Hosts
• CVE-1999-0513 — ICMP Broadcast Flood
• Smurf Amplification in 2026 — preceding analysis, L2 broadcast domain exploitation
• Ghost Leak: ICMP Timestamp via TTL=0 — CWE-200 enabled by CWE-290 absence

Vesqer / JM00NJ — netacoding.com — github.com/JM00NJ

Legal Disclaimer: All testing described was performed in authorized lab environments. Do not test against systems you do not own or have explicit written permission to test.