CWE-941: Incorrectly Specified Destination in a… | Glexia
CWE-941 (Incorrectly Specified Destination in a Communication Channel) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE…
Glexia's Take · Automated analysis
CWE-941: Incorrectly Specified Destination in a Communication Channel
Incorrectly Specified Destination in a Communication Channel represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control Other: Gain Privileges or Assume Identity Varies by Context Bypass Protection Mechanism: An attacker can access any functionality that is inadvertently accessible to the source.
Developer Pattern
CWE-941 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-941, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-941: Incorrectly Specified Destination in a Communication Channel
The product creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.
Attackers at the destination may be able to spoof trusted servers to steal data or cause a denial of service. There are at least two distinct weaknesses that can cause the product to communicate with an unintended destination: If the product allows an attacker to control which destination is specified, then the attacker can cause it to connect to an untrusted or malicious destination. For example, because UDP is a connectionless protocol, UDP packets can be spoofed by specifying a false source address in the packet; when the server receives the packet and sends a reply, it will specify a destination by using the source of the incoming packet - i.e., the false source. The server can then be tricked into sending traffic to the wrong host, which is effective for hiding the real source of an attack and for conducting a distributed denial of service (DDoS). As another example, server-side request forgery (SSRF) and XML External Entity (XXE) can be used to trick a server into making outgoing requests to hosts that cannot be directly accessed by the attacker due to firewall restrictions. If the product incorrectly specifies the destination, then an attacker who can control this destination might be able to spoof trusted servers. While the most common occurrence is likely due to misconfiguration by an administrator, this can be resultant from other weaknesses. For example, the product might incorrectly parse an e-mail or IP address and send sensitive data to an unintended destination. As another example, an Android application may use a "sticky broadcast" to communicate with a receiver for a particular application, but since sticky broadcasts can be processed by *any* receiver, this can allow a malicious application to access restricted data that was only intended for a different application.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- This code listens on a port for DNS requests and sends the result to the requesting address. This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.
Remediation
- Use safe APIs
- Centralize the control
- Add regression tests
- Review logs and telemetry for attempted abuse
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.