CWE-300 is the formal name for a familiar attack shape: someone who is not one of the two parties gets access to, or influence over, the channel between them. It happens when the product does not adequately verify the identity of actors at both ends, or does not ensure the integrity of the channel.
Any client and server pair, service to service call, or device to cloud link can be affected.
How it happens
MITRE explains the logic. To communicate securely, each party should confirm who is at the other end. If verification is missing or inconsistent, one side may trust the wrong entity. An attacker then interposes between the two, masquerades as each to the other, and can eavesdrop and potentially modify the traffic.
Typical causes:
- One-way authentication only. The client checks the server but the server never checks the client, or the reverse.
- Certificate checks that are disabled or incomplete (see CWE-295).
- Plain text channels, where nothing authenticates either end.
- Verification done once at the start while later messages are unprotected.
The one observed example is CVE-2014-1266, the Apple "goto fail" bug, a chain in which an incorrect goto bypassed certificate validation and allowed an adversary-in-the-middle attack.
What an attacker gains
An attacker can pose as one of the entities and read or possibly modify the communication. MITRE lists impacts on confidentiality, integrity and access control: reading application data, modifying application data, and gaining the identity of a party.
How to find it
MITRE describes three useful techniques:
- Proxy-based testing. Tools that act as a proxy let a tester intercept packets or messages, inspect and modify them, and see whether the receiver still accepts the altered versions.
- DAST tools can detect network traffic without encryption or verification, where the protocol may be open to adversary-in-the-middle attacks.
- Static analysis can find some instances by examining source or compiled code.
How to fix it
- Always fully authenticate both ends of any communications channel, as MITRE says.
- Apply the principle of complete mediation: check authenticity on every access, not once.
- Use certificates, which bind an identity to a cryptographic key, and validate them completely. Mutual TLS is a common way to give both ends a certificate.
- Protect message integrity so that a change in transit is detected.
- Test with an intercepting proxy as part of release checks.
Quick check
Is encryption alone enough?
No. Encryption without authentication can mean an encrypted tunnel straight to the attacker. Both ends must prove identity.
What does complete mediation mean here?
Every use of the channel is checked, instead of trusting a connection because it passed a check earlier.
