An adversary exploits a sample, demonstration, test, or debug interface that is unintentionally enabled on a production system, with the goal of gleaning information or leveraging functionality that would otherwise be unavailable. Non-production interfaces are insecure by default and should not be resident on production systems, since they may reveal sensitive information or functionality that should not be known to end-users. However, such interfaces may be unintentionally left enabled on a production system due to configuration errors, supply chain mismanagement, or other pre-deployment activities.
Ultimately, failure to properly disable non-production interfaces, in a production environment, may expose a great deal of diagnostic information or functionality to an adversary, which can be utilized to further refine their attack. Moreover, many non-production interfaces do not have adequate security controls or may not have undergone rigorous testing since they were not intended for use in production environments. As such, they may contain many flaws and vulnerabilities that could allow an adversary to severely disrupt a target.
Likelihood Of Attack
This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
Meta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.
Detailed Attack Pattern - A detailed level attack pattern in CAPEC provides a low level of detail, typically leveraging a specific technique and targeting a specific technology, and expresses a complete execution flow. Detailed attack patterns are more specific than meta attack patterns and standard attack patterns and often require a specific protection mechanism to mitigate actual attacks. A detailed level attack pattern often will leverage a number of different standard level attack patterns chained together to accomplish a goal.
Determine Vulnerable Interface: An adversary explores a target system for sample or test interfaces that have not been disabled by a system administrator and which may be exploitable by the adversary.
If needed, the adversary explores an organization's network to determine if any specific systems of interest exist.
Leverage Test Interface to Execute Attacks: Once an adversary has discovered a system with a non-production interface, the interface is leveraged to exploit the system and/or conduct various attacks.
The adversary can leverage the sample or test interface to conduct several types of attacks such as Adversary-in-the-Middle attacks (CAPEC-94), keylogging, Cross Site Scripting (XSS), hardware manipulation attacks, and more.
The target must have configured non-production interfaces and failed to secure or remove them when brought into a production environment.
Exploiting non-production interfaces requires significant skill and knowledge about the potential non-production interfaces left enabled in production.
For some interfaces, the attacker will need that appropriate client application or hardware that interfaces with the interface. Other non-production interfaces can be executed using simple tools, such as web browsers or console windows. In some cases, an attacker may need to be able to authenticate to the target before it can access the vulnerable interface.
This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Bypass Protection Mechanism
Execute Unauthorized Commands
Alter Execution Logic
Ensure that production systems to not contain non-production interfaces and that these interfaces are only used in development environments.
Some software applications include application programming interfaces (APIs) that are intended to allow an administrator to test and refine their domain. These APIs are typically disabled once a system enters a production environment, but may be left in an insecure state due to a configuration error or mismanagement.
Many hardware systems leverage bits typically reserved for future functionality for testing and debugging purposes. If these reserved bits remain enabled in a production environment, it could allow an adversary to induce unwanted/unsupported behavior in the hardware.
A Related Weakness relationship associates a weakness with this attack pattern. Each association implies a weakness that must exist for a given attack to be successful. If multiple weaknesses are associated with the attack pattern, then any of the weaknesses (but not necessarily all) may be present for the attack to be successful. Each related weakness is identified by a CWE identifier.
Hardware Allows Activation of Test or Debug Logic at Runtime
[REF-588] Swarup Bhunia and
Mark M. Tehranipoor. "The Hardware Trojan War: Attacks, Myths, and Defenses". Springer. 2017-11-30.
[REF-589] Boyang Du, Matteo Sonza Reorda, Luca Sterpone, Luis Parra, Marta Portela-Garcia, Almudena Lindoso
and Luis Entrena. "Exploiting the debug interface to support on-line test of control flow errors". Institute of Electrical and Electronics Engineers (IEEE). 2013-07-08.
<https://ieeexplore.ieee.org/document/6604058/authors#authors>. URL validated: 2020-07-13.