CAPEC-443: Malicious Logic Inserted Into Product Software by Authorized Developer
Attack Pattern ID: 443
Abstraction: Detailed
Status: Stable
Presentation Filter:
Description
An adversary uses their privileged position within an authorized software development organization to inject malicious logic into a codebase or product. Supply chain attacks from approved or trusted developers are extremely difficult to detect as it is generally assumed the quality control and internal security measures of these organizations conform to best practices. In some cases the malicious logic is intentional, embedded by a disgruntled employee, programmer, or individual with an otherwise hidden agenda. In other cases, the integrity of the product is compromised by accident (e.g. by lapse in the internal security of the organization that results in a product becoming contaminated). In other cases, the developer embeds a backdoor into a product to serve some purpose, such as product support, but discovery of the backdoor results in its malicious use by adversaries.
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 software during the development phase.
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 during development and prior to deployment to ensure that it functions as intended and without any malicious functionality.
Don't assume popular third-party components are free from malware or vulnerabilities. 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
In January 2022 the author of popular JavaScript packages "Faker" and "colors", used for generating mock data and including colored text within NodeJS consoles respectively, introduced malicious code that resulted in a Denial of Service (DoS) via an infinite loop. When applications that leveraged these packages updated to the malicious version, their applications executed the infinite loop and output gibberish ASCI characters endlessly. This resulted in the application being unusable until a stable version of the package was obtained. [REF-705]
References
[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.
Description
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.
Content History
