Every outgoing message has an address. If the software gets the address wrong, or lets someone else choose it, the message goes where the attacker wants.
CWE-941 describes this: the product creates a communication channel to initiate an outgoing request to an actor, but does not correctly specify the intended destination for that actor. MITRE lists it as a Base weakness for any platform, including mobile.
How it happens
MITRE names at least two distinct causes.
- The attacker controls the destination. The product can then be made to connect to an untrusted or malicious host. UDP is the textbook case. It is connectionless, so a packet can carry a false source address. A server that replies to the source of the incoming packet ends up sending traffic to the spoofed host. That hides the real attacker and is effective for distributed denial of service. Server side request forgery and XML external entity attacks are related, since they trick a server into making outgoing requests to hosts the attacker cannot reach directly because of firewalls.
- The product specifies the destination incorrectly. An attacker who controls that wrongly chosen destination may be able to spoof trusted servers. MITRE says the most common cause is administrator misconfiguration, but parsing errors count too, such as mishandling an email or IP address and sending sensitive data to an unintended place.
MITRE's example is a Python service that answers DNS requests over UDP:
# Vulnerable: replies go to whatever source address the packet claims
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
while True:
data, addr = sock.recvfrom(1024)
record = resolve_name(parse_packet(data))
sock.sendto(record, addr)
The observed CVEs are all reflection cases. CVE-2013-5211 is an NTP feature that produces large responses to spoofed UDP source addresses. CVE-1999-0513 is the classic Smurf attack using spoofed ICMP packets to broadcast addresses. CVE-1999-1379 is DNS queries with spoofed source addresses returning more traffic than was sent.
What an attacker gains
MITRE records access control impact: gaining privileges or assuming identity, and bypassing protection mechanisms. An attacker can reach any functionality that is inadvertently accessible to the source they impersonate. In the reflection cases, the practical gain is amplified traffic aimed at a victim.
How to find it
MITRE gives no detection methods for this entry. Practical checks:
- Review every place the code builds a destination from input, headers, config or parsed fields.
- Check UDP services for replies larger than requests.
- Check configuration for hosts and addresses pointing to unintended targets.
- Test URL and address parsers with malformed values.
How to fix it
MITRE lists no formal mitigations. Reasonable steps that follow from the weakness:
- Never take an outgoing destination straight from untrusted input. Use an allow list.
- Rate limit UDP replies and keep them no larger than the request, or require a handshake or cookie first.
- Validate and test address parsing.
- Review configuration changes for destination values.
- Block outbound traffic from servers except to known hosts, which limits request forgery.
Keep services and libraries updated. The free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies with no login, and your file stays on your machine.
Quick check
Why is UDP singled out?
It is connectionless, so the source address in a packet can be forged, and a server replying to that address sends traffic to the wrong host.
What is the most common cause when the product picks the wrong destination itself?
According to MITRE, misconfiguration by an administrator, though parsing mistakes can do it too.
