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

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.

Submission Date :

July 19, 2006, midnight

Modification Date :

2023-06-29 00:00:00+00:00

Organization :

MITRE
Extended Description

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:

  • The product runs with different privileges or on a different system, or otherwise has different levels of access than the upstream component;
  • The attacker is prevented from making the request directly to the target; and
  • The attacker can create a request that the proxy does not explicitly intend to be forwarded on the behalf of the requester. Such a request might point to an unexpected hostname, port number, hardware IP, or service. Or, the request might be sent to an allowed service, but the request could contain disallowed directives, commands, or resources.

Example Vulnerable Codes

Example - 1

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 severalother compute elements and peripherals. The SoC implementsaccess control to protect the registers in the IP core(which registers store the design-house secrets) frommalicious, ring-3 (least trusted ring) code executing onthe microcontroller. The DMA controller, however, is notblocked off from accessing the IP core for functionalreasons.

The code in ring-3 (least trusted ring) of themicrocontroller attempts to directly read the protectedregisters in IP core through MMIO transactions. However,this attempt is blocked due to the implemented accesscontrol. Now, the microcontroller configures the DMA coreto transfer data from the protected registers to a memoryregion that it has access to. The DMA core, which isacting as an intermediary in this transaction, does notpreserve the identity of the microcontroller and, instead,initiates a new transaction with its own identity. Sincethe DMA core has access, the transaction (and hence, theattack) is successful.

The weakness here is that the intermediary or theproxy agent did not ensure the immutability of theidentity of the microcontroller initiating thetransaction.

The DMAcore forwards this transaction with the identity of thecode executing on the microcontroller, which is theoriginal initiator of the end-to-end transaction. Now thetransaction is blocked, as a result of forwarding theidentity of the true initiator which lacks the permissionto access the confidential MMIO mapped IP core.

Visit http://cwe.mitre.org/ for more details.