ashishbijlani / risk-explorer-execution-pocs

A collection of proof-of-concepts in multiple languages and for different package managers, showcasing how third-party dependencies trigger code execution on downstream projects, leading to potential open-source software supply chain attacks.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Risk Explorer - Execution Proof-of-Concepts

License REUSE status

Description

To conduct a successful OSS supply chain attack, an attacker is required to:

  1. Create a malicious package that is available to downstream users.
  2. Get the victim to install/download the malicious artifact.
  3. 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.

Project Structure

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 examples
      • php (composer): Includes 6 examples
    • i2-technique (Run code in build script):
      • python (pip): Includes 2 examples
      • rust (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 example
      • python: Includes 1 example
      • ruby: Includes 1 example
      • go: 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 example
      • java: Includes 1 example
      • javascript: Includes 1 example
      • php: Includes 1 example
      • python: Includes 1 example
      • ruby: Includes 1 example
      • rust: 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 example
      • java: Includes 1 example
      • javascript: Includes 1 example
      • php: Includes 1 example
      • python: Includes 1 example
      • ruby: Includes 1 example
      • rust: 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

Requirements and Usage

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

How to obtain support

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.

Contributing

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.

License

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.

About

A collection of proof-of-concepts in multiple languages and for different package managers, showcasing how third-party dependencies trigger code execution on downstream projects, leading to potential open-source software supply chain attacks.

License:Apache License 2.0


Languages

Language:Java 21.5%Language:Python 19.0%Language:Rust 16.0%Language:Ruby 12.3%Language:Go 12.3%Language:JavaScript 10.7%Language:PHP 8.1%