To conduct a successful OSS supply chain attack, an attacker is required to:
- Create a malicious package that is available to downstream users.
- Get the victim to install/download the malicious artifact.
- Get the victim to run the malicious code.
In our previous work, we presented a taxonomy that describes how attackers can inject malicious code into OSS components (for an interactive view, you can visit the Risk Explorer). This taxonomy comprehensively covers the first two requirements listed above.
In this project, we enhance this description by providing runnable examples for multiple ecosystems, explaining how a 3rd-party dependency can trigger execution in downstream projects, ultimately resulting in OSS supply chain attacks. For further details, you can refer to our paper (description to be added later).
In general, 3rd-party dependencies can achieve Arbitrary Code Execution (ACE) in two stages of their lifecycle:
- Install time: When downstream users/projects install a 3rd-party dependency using popular package managers (e.g., npm, composer, pip).
- Runtime: When downstream users/projects actually use (and invoke) the code of the 3rd-party dependency.
This project covers the following programming languages and their respective (reference) package managers:
- Python (pip)
- JavaScript (npm)
- Ruby (gem)
- PHP (composer)
- Rust (cargo)
- Go (go)
- Java (mvn)
This release aims to support fellow researchers in devising protective measures against such threats. We believe it may also assist penetration testers in evaluating whether the offensive techniques explored in this work can be replicated within their organizations.
The project is structured as follows:
-
install-time
: This folder contains examples related to the "tactic" of achieving Arbitrary Code Execution during the installation of a 3rd-party dependency. It is further divided into subfolders, each representing different techniques explained in the paper:i1-technique
(Run command/scripts leveraging install-hooks): This subfolder contains "practices" (i.e., implementations) for the following programming languages:javascript
(npm): Includes 7 examplesphp
(composer): Includes 6 examples
i2-technique
(Run code in build script):python
(pip): Includes 2 examplesrust
(cargo): Includes 1 example
i3-technique
(Run code in build extension(s)):ruby
(gem): Includes 1 example
-
runtime
: This folder contains examples related to the "tactic" of achieving Arbitrary Code Execution during the runtime of a 3rd-party dependency. It is also divided into subfolders, each representing different techniques explained in the paper:r1-technique
(Insert code in methods/scripts executed when importing a module): This contains "practices" (i.e., implementations) for the following programming languages:javascript
: Includes 1 examplepython
: Includes 1 exampleruby
: Includes 1 examplego
: Includes 1 example
r2-technique
(Insert code in commonly-used methods): This contains "practices" (i.e., implementations) for the following programming languages:go
: Includes 1 examplejava
: Includes 1 examplejavascript
: Includes 1 examplephp
: Includes 1 examplepython
: Includes 1 exampleruby
: Includes 1 examplerust
: Includes 1 example
r3-technique
(Insert code in constructor methods (of popular classes)): This contains "practices" (i.e., implementations) for the following programming languages:go
: Includes 1 examplejava
: Includes 1 examplejavascript
: Includes 1 examplephp
: Includes 1 examplepython
: Includes 1 exampleruby
: Includes 1 examplerust
: Includes 1 example
r4-technique
(Run code of 3rd-party dependency as build plugin): As this technique is mostly specific to Java, there is only one subfolder:java
: Includes 1 example
To execute the provided examples, it is essential to ensure that your system has the following programming languages and their associated package managers installed:
- Python with
pip
- JavaScript with
npm
- Ruby with
gem
- PHP with
composer
- Rust with
cargo
- Go with
go
- Java with
mvn
Create an issue in this repository if you find a bug or have questions about the content.
For additional support, ask a question in SAP Community.
If you wish to contribute code, offer fixes or improvements, please send a pull request. Due to legal reasons, contributors will be asked to accept a DCO when they create the first pull request to this project. This happens in an automated fashion during the submission process. SAP uses the standard DCO text of the Linux Foundation.
Copyright (c) 2023 SAP SE or an SAP affiliate company. All rights reserved. This project is licensed under the Apache Software License, version 2.0 except as noted otherwise in the LICENSE file.