An attacker with access to an open source code project (OSS) and knowledge of its particular use for in a system being developed, manufactured, or supported for the victim, can insert malicious code into the open source software used for math libraries in anticipation of inclusion into the system for the purpose of disruption or further compromise within the victim organization.
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.
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.
Determine the relevent open-source code project to target: The adversary will make the selection based on various criteria:
The open-source code currently in use on a selected target system.
The depth in the dependency graph of the open source code in relationship to other code bases in use on the target system. Choosing an OSS lower in the graph decreases the probability of discovery, but also decreases the scope of its use within the target system.
The programming language in which the open source code is implemented. Different languages present different opportunities for using known software weaknesses.
The quality of processes in place to make a contribution. For instance, some contribution sites use static and dynamic analysis tools, which could increase the probability of discovery.
The security requirments necessary to make a contribution. For instance, is the ownership lax allowing unsigned commits or anonymous users.
Develop a malicious contribution plan: The adversary develops a plan to contribute the malicious code, taking the following into consideration:
The adversary will probably avoid easy-to-find software weaknesses, especially ones that static and dynamic analysis tools are likely to discover.
Common coding errors or missing edge cases of the algorithm, which can be explained away as being accidental, if discovered, will be preferred by the adversary.
Sometimes no identity is required to make a contribution. Other options are to steal an existing identity or create one. When creating a new identity strike a balance between too little or too much detail. Using an stolen identity could cause a notification to be sent to the actual user.
Execute the malicious contribution plan: Write the code to be contributed based on the plan and then submit the contribution. Multiple commits, possibly using multiple identities, will help obscure the attack. Monitor the contribution site to try to determine if the code has been uploaded to the target system.
Access to the open source code base being used by the manufacturer in a system being developed or currently deployed at a victim location.
Advanced knowledge about the inclusion and specific usage of an open source code project within system being targeted for infiltration.
An attacker with access to an open source code project introduces a hard-to-find bug in the software that allows under very specific conditions for encryption to be disabled on data streams. The attacker commits the change to the code which is picked up by a manufacturer who develops VPN software. It is eventually deployed at the victim's location where the very specific conditions are met, and the attacker is able to sniff plaintext traffic thought to be encrypted, allowing the attacker to gain access to sensitive data of the victim.