New to CAPEC? Start Here
Home > CAPEC List > CAPEC-673: Developer Signing Maliciously Altered Software (Version 3.5)  

CAPEC-673: Developer Signing Maliciously Altered Software

Attack Pattern ID: 673
Abstraction: Detailed
Status: Draft
Presentation Filter:
+ Description

Software produced by a reputable developer is clandestinely infected with malicious code and then digitally signed by the unsuspecting developer, where the software has been altered via a compromised software development or build process prior to being signed. The receiver or user of the software has no reason to believe that it is anything but legitimate and proceeds to deploy it to organizational systems.

This attack differs from CAPEC-206, since the developer is inadvertently signing malicious code they believe to be legitimate and which they are unware of any malicious modifications.

+ Likelihood Of Attack

Medium

+ Typical Severity

High

+ Relationships
Section HelpThis 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.
NatureTypeIDName
ChildOfStandard Attack PatternStandard 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.444Development Alteration
CanFollowStandard Attack PatternStandard 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.669Alteration of a Software Update
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Prerequisites
An adversary would need to have access to a targeted developer’s software development environment, including to their software build processes, where the adversary could ensure code maliciously tainted prior to a build process is included in software packages built.
+ Skills Required
[Level: High]
The adversary must have the skills to infiltrate a developer’s software development/build environment and to implant malicious code in developmental software code, a build server, or a software repository containing dependency code, which would be referenced to be included during the software build process.
+ Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Read Data
Modify Data
Access Control
Authorization
Gain Privileges
Execute Unauthorized Commands
+ Mitigations
Have a security concept of operations (CONOPS) for the IDE that includes: Protecting the IDE via logical isolation using firewall and DMZ technologies/architectures; Maintaining strict security administration and configuration management of configuration management tools, developmental software and dependency code repositories, compilers, and system build tools.
Employ intrusion detection and malware detection capabilities on IDE systems where feasible.
+ Example Instances

An adversary who has infiltrated an organization’s build environment maliciously alters code intended to be included in a product’s software build via software dependency inclusion, part of the software build process. When the software product has been built, the developer electronically signs the finished product using their signing key. The recipient of the software product, an end user/customer, believes the software to reflect the developer’s intent with respect to functionality unaware of the adversary’s malicious intent harbored within.

+ References
[REF-658] "Defending Against Software Supply Chain Attacks". Cybersecurity and Infrastructure Security Agency (CISA). 2021-04. <https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf>. URL validated: 2021-06-22.
[REF-659] Dr. Charles Clancy, Joe Ferraro, Robert A. Martin, Adam G. Pennington, Christopher L. Sledjeski and Dr. Craig J. Wiener. "Deliver Uncompromised: Securing Critical Software Supply Chains". The MITRE Corporation. 2021-01. <https://www.mitre.org/publications/technical-papers/deliver-uncompromised-securing-critical-software-supply-chains>. URL validated: 2021-06-22.
+ Content History
Submissions
Submission DateSubmitterOrganization
2021-06-24CAPEC Content TeamThe MITRE Corporation
More information is available — Please select a different filter.
Page Last Updated or Reviewed: June 24, 2021