CWE-420 describes a product that protects a primary channel but does not use the same level of protection for an alternate channel. Attackers test the side doors first, because they are often the least defended.
How it happens
Systems rarely have one way in. There is a web interface and an API, a data bus and an instruction bus, an application and the database behind it. Controls get added to the path everyone thinks about. The others inherit nothing.
MITRE's observed examples show it clearly:
- Internal flash was protected by blocking access on the data bus, yet was still reachable indirectly through the instruction bus (CVE-2020-8004).
- A database server assumed local clients had already authenticated, so an attacker could connect directly to the process or a socket interface (CVE-2002-0567).
- A product did not restrict access to its underlying database, so restrictions were bypassed by querying it directly (CVE-2002-1578).
- A user avoided lockouts by using an API instead of the GUI for brute force password guessing (CVE-2003-1035).
What an attacker gains
Per the record: gaining privileges or assuming identity, and bypassing protection mechanisms. The attacker gets everything the weaker channel exposes.
How to find it
The record lists no detection methods. Do an inventory exercise:
- List every interface to a protected resource: UI, API, CLI, database port, message queue, debug port.
- For each security control, such as authentication, lockout and logging, check that it applies on every interface.
- Test the control through the weakest interface, not the main one.
How to fix it
- Enforce controls in the shared layer beneath all channels, not in one front end.
- Apply the same lockout, rate limit and logging to every interface.
- Close or firewall interfaces nobody needs, such as direct database access from user networks.
- Never assume a local or internal client has already authenticated.
Quick check
Where should an access check live?
As close to the resource as possible, so every channel passes through it.
