CAPEC-446: Malicious Logic Insertion into Product via Inclusion of Third-Party Component
Attack Pattern ID: 446
Abstraction: Detailed
View customized information:
Description
An adversary conducts supply chain attacks by the inclusion of insecure third-party components into a technology, product, or code-base, possibly packaging a malicious driver or component along with the product before shipping it to the consumer or acquirer.
Extended Description
The result is a window of opportunity for exploiting the product until the insecure component is discovered. This supply chain threat can result in the installation of malicious software or hardware that introduces widespread security vulnerabilities within an organization. Additionally, because software often depends upon a large number of interdependent libraries and components to be present, security holes can be introduced merely by installing Commercial off the Shelf (COTS) or Open Source Software (OSS) software that comes pre-packaged with the components required for it to operate. It is also worth noting that this attack can occur during initial product development or throughout a product's sustainment.
Likelihood Of Attack
Medium
Typical Severity
High
Relationships
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.
Nature
Type
ID
Name
ChildOf
Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.
Access to the product during the initial or continuous development. This access is often obtained via insider access to include the third-party component after deployment.
Consequences
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.
Scope
Impact
Likelihood
Authorization
Execute Unauthorized Commands
Mitigations
Assess software and hardware during development and prior to deployment to ensure that it functions as intended and without any malicious functionality. This includes both initial development, as well as updates propagated to the product after deployment.
Don't assume popular third-party components are free from malware or vulnerabilities. For software, assess for malicious functionality via update/commit reviews or automated static/dynamic analysis prior to including the component within the application and deploying in a production environment.
Example Instances
From mid-2014 to early 2015, Lenovo computers were shipped with the Superfish Visual Search software that ultimately functioned as adware on the system. The Visual Search installation included a self-signed root HTTPS certificate that was able to intercept encrypted traffic for any site visited by the user. Of more concern was the fact that the certificate's corresponding private key was the same for every Lenovo machine. Once the private key was discovered [REF-709], an adversary could then conduct an Adversary-in-the-Middle (AitM) attack that would go undetected by machines that had this certificate installed on it. Adversaries could then masquerade as legitimate entities such as financial institutions, popular corporations, or other secure destinations on the Internet. [REF-708]
In 2018 it was discovered that Chinese spies infiltrated several U.S. government agencies and corporations as far back as 2015 by including a malicious microchip within the motherboard of servers sold by Elemental Technologies to the victims. Although these servers were assembled via a U.S. based company, the motherboards used within the servers were manufactured and maliciously altered via a Chinese subcontractor. Elemental Technologies then sold these malicious servers to various U.S. government agencies, such as the DoD and CIA, and corporations like Amazon and Apple. The malicious microchip provided adversaries with a backdoor into the system, which further allowed them to access any network that contained the exploited systems, to exfiltrate data to be sent to the Chinese government.[REF-713]
Related Weaknesses
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.
CWE leads to CAPEC: This entry highlights the rare case where a CAPEC creates an instance of a CWE, as opposed to the usual other way around. At this time, this field only includes mappings to weaknesses that cause the CAPEC, instead of CWEs that could arise due to the CAPEC.
Taxonomy Mappings
CAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
[REF-379] Jon Boyens, Angela Smith, Nadya Bartol, Kris Winkler, Alex Holbrook
and Matthew Fallon. "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (2nd Draft)". National Institute of Standards and Technology (NIST). 2021-10-28.
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1-draft2.pdf>. URL validated: 2022-02-16.