| Name |
Open-Source Library Manipulation |
|
| Likelyhood of attack |
Typical severity |
| Low |
High |
|
| Summary |
Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems. |
| Prerequisites |
Access to the open source code base being used by the manufacturer in a system being developed or currently deployed at a victim location. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Determine the relevant 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 requirements necessary to make a contribution. For instance, is the ownership lax allowing unsigned commits or anonymous users. |
|
| 2 |
Experiment |
[Develop a plan for malicious contribution] The adversary develops a plan to contribute 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. |
|
| 3 |
Exploit |
[Execute the plan for malicious contribution] 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. |
|
|
| Solutions | |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-494 |
Download of Code Without Integrity Check |
| CWE-829 |
Inclusion of Functionality from Untrusted Control Sphere |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-444 |
An adversary modifies a technology, product, or component during its development to acheive a negative impact once the system is deployed. The goal of the adversary is to modify the system in such a way that the negative impact can be leveraged when the system is later deployed. Development alteration attacks may include attacks that insert malicious logic into the system's software, modify or replace hardware components, and other attacks which negatively impact the system during development. These attacks generally require insider access to modify source code or to tamper with hardware components. The product is then delivered to the user where the negative impact can be leveraged at a later time. |
|
| Taxonomy: ATTACK |
|
Entry ID
|
Entry Name
|
| 1195.001 |
Supply Chain Compromise: Software Dependencies and Development Tools |
|