Class · High

CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an...

CWE-441 · Class Level ·8 CVEs ·2 Mitigations

Description

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.

If an attacker cannot directly contact a target, but the product has access to the target, then the attacker can send a request to the product and have it be forwarded to the target. The request would appear to be coming from the product's system, not the attacker's system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests, since the requests would not be coming directly from the attacker. Since proxy functionality and message-forwarding often serve a legitimate purpose, this issue only becomes a vulnerability when:

Potential Impact

Non-Repudiation, Access Control

Gain Privileges or Assume Identity, Hide Activities, Execute Unauthorized Code or Commands

Demonstrative Examples

A SoC contains a microcontroller (running ring-3 (least trusted ring) code), a Memory Mapped Input Output (MMIO) mapped IP core (containing design-house secrets), and a Direct Memory Access (DMA) controller, among several other compute elements and peripherals. The SoC implements access control to protect the registers in the IP core (which registers store the design-house secrets) from malicious, ring-3 (least trusted ring) code executing on the microcontroller. The DMA controller, however, is not blocked off from accessing the IP core for functional reasons.
Bad
The code in ring-3 (least trusted ring) of the
                     microcontroller attempts to directly read the protected
                     registers in IP core through MMIO transactions. However,
                     this attempt is blocked due to the implemented access
                     control. Now, the microcontroller configures the DMA core
                     to transfer data from the protected registers to a memory
                     region that it has access to. The DMA core, which is
                     acting as an intermediary in this transaction, does not
                     preserve the identity of the microcontroller and, instead,
                     initiates a new transaction with its own identity. Since
                     the DMA core has access, the transaction (and hence, the
                     attack) is successful.
The weakness here is that the intermediary or the proxy agent did not ensure the immutability of the identity of the microcontroller initiating the transaction.
Good
The DMA
                     core forwards this transaction with the identity of the
                     code executing on the microcontroller, which is the
                     original initiator of the end-to-end transaction. Now the
                     transaction is blocked, as a result of forwarding the
                     identity of the true initiator which lacks the permission
                     to access the confidential MMIO mapped IP core.

Mitigations & Prevention

Architecture and Design

Enforce the use of strong mutual authentication mechanism between the two parties.

Architecture and Design

Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.

Detection Methods

  • Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE IDDescription
CVE-1999-0017FTP bounce attack. The design of the protocol allows an attacker to modify the PORT command to cause the FTP server to connect to other machines besides the attacker's.
CVE-1999-0168RPC portmapper could redirect service requests from an attacker to another entity, which thinks the requests came from the portmapper.
CVE-2005-0315FTP server does not ensure that the IP address in a PORT command is the same as the FTP user's session, allowing port scanning by proxy.
CVE-2002-1484Web server allows attackers to request a URL from another server, including other ports, which allows proxied scanning.
CVE-2004-2061CGI script accepts and retrieves incoming URLs.
CVE-2001-1484Bounce attack allows access to TFTP from trusted side.
CVE-2010-1637Web-based mail program allows internal network scanning using a modified POP3 port number.
CVE-2009-0037URL-downloading library automatically follows redirects to file:// and scp:// URLs

Taxonomy Mappings

  • PLOVER: — Unintended proxy/intermediary
  • PLOVER: — Proxied Trusted Channel
  • WASC: 32 — Routing Detour

Frequently Asked Questions

What is CWE-441?

CWE-441 (Unintended Proxy or Intermediary ('Confused Deputy')) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an...

How can CWE-441 be exploited?

Attackers can exploit CWE-441 (Unintended Proxy or Intermediary ('Confused Deputy')) to gain privileges or assume identity, hide activities, execute unauthorized code or commands. This weakness is typically introduced during the Architecture and Design phase of software development.

How do I prevent CWE-441?

Key mitigations include: Enforce the use of strong mutual authentication mechanism between the two parties.

What is the severity of CWE-441?

CWE-441 is classified as a Class-level weakness (High abstraction). It has been observed in 8 real-world CVEs.