A service that answers a small request with a large reply, to an address the requester can fake, becomes a weapon aimed at somebody else. CWE-406 is the weakness where the product does not sufficiently monitor or control transmitted network traffic volume, so an actor can cause it to transmit more traffic than should be allowed for that actor.
It is the network flavor of asymmetric resource consumption (CWE-405). It matters to anyone who runs a public UDP or datagram style service, a broadcast capable network, or any API that fans out messages on a client's behalf.
How it happens
MITRE explains that without a policy to restrict asymmetric resource consumption, the application or system cannot tell legitimate transmissions from traffic meant to amplify an attack on a target. Systems can often be configured to limit traffic sent out for a client based on origin or access level, usually through a resource allocation policy. Without a mechanism that tracks transmissions, the system can easily be abused to send asymmetrically more traffic than the request or client should allow.
The record gives two examples:
- CVE-1999-0513: the classic Smurf attack, using spoofed ICMP packets to broadcast addresses.
- CVE-1999-1379: a DNS query with a spoofed source address causes more traffic to be returned to the spoofed address than was sent.
In both, the attacker forges the source address. The reply goes to the victim, and the service pays the bandwidth for it.
A code level version is a notification service that sends to whatever address the caller names:
@app.post("/invite")
def invite():
for addr in request.json["recipients"]: # unbounded list
send_email(addr, big_template) # no per client limit
return "ok"
One request becomes thousands of messages, and the sender pays nothing.
What an attacker gains
MITRE lists availability impact: DoS through amplification, crash, exit or restart, and CPU, memory or other resource consumption. System resources can be consumed quickly, leading to poor application performance or a crash, and network performance may suffer too, for both the abused service and the victim.
How to find it
MITRE says automated static analysis (SAST) can find some instances of this weakness by analyzing source code. Add these checks:
- List every feature where one inbound request causes many outbound messages, or a reply much larger than the request.
- Test whether the service accepts requests from unauthenticated or unverified sources and replies to addresses the requester controls.
- Compare request size and response size for each public protocol endpoint. A ratio well above one deserves attention.
- Check whether broadcast replies are enabled on your network devices.
How to fix it
MITRE's mitigations, in plain terms:
- Make network resources available to a client in line with its access level, so unknown clients get the least.
- Define a clear policy for network resource allocation and consumption.
- Track network resources at all times and meter their use appropriately.
In practice this means per client rate and volume limits, caps on recipient counts and response size, and verifying the requester before sending anything to an address they named.
MAX_RECIPIENTS = 20
if len(recipients) > MAX_RECIPIENTS:
abort(400)
if not quota.try_consume(client_id, len(recipients)):
abort(429)
For datagram protocols, require a handshake or token before sending large replies, and make the first response no larger than the request.
Quick check
Why does spoofing matter in amplification attacks?
The attacker sets the source address to the victim, so replies go to the victim while the abused service uses its own bandwidth.
How does this differ from CWE-405?
CWE-405 covers amplification of any resource. CWE-406 is the network traffic case: sending more messages than the client should be allowed to cause.
