Poisoned Pipeline Execution
Continuous Integration and Continuous Deployment (CI/CD) pipelines are fundamental: they enable rapid development and deployment. However, the increasing reliance on these pipelines introduces significant security vulnerabilities, notably Poisoned Pipeline Execution (PPE).
This vulnerability is a critical concern as highlighted in the OWASP Top-10 CI/CD Security Risks warranting a thorough understanding and robust defensive strategies.
PPE critically undermines software supply chain security by introducing vulnerabilities directly into the CI/CD process. This vulnerability can lead to the unauthorized alteration of software during development, enabling attackers to embed malicious code that can go undetected until after deployment.
Such breaches can have far-reaching impacts, potentially compromising any system that depends on the integrity of the pipeline, disrupting operations, and causing significant reputational and financial damage. This highlights the necessity for stringent security measures and monitoring systems throughout the development and deployment pipeline to protect against such threats.
What is Poisoned Pipeline Execution (PPE)
According to OWASP, Poisoned Pipeline Execution (PPE) is defined as the malicious manipulation of the build process by injecting harmful code into the build pipeline configuration (an attacker can modify the pipeline logic). This manipulation is executed without direct access to the build environment, making detection particularly challenging. PPE can manifest in two primary forms:
- Direct PPE (D-PPE): it occurs when an attacker directly alters the CI configuration file within a repository they have access to. This could be through direct changes to unprotected branches or via pull requests from forks or branches, allowing the execution of malicious commands once the pipeline is triggered.
- Indirect PPE (I-PPE): In scenarios where direct modification is not feasible, attackers may inject malicious code into files that the pipeline references, such as scripts within the configuration file.
In both cases, GitHub will execute the modified pipeline with no need for a previous review or approbation. Early detection of PPE is for that reason something really important and must be required.
Exploiting PPE with a Practical Example
To illustrate how Poisoned Pipeline Execution (PPE) can be exploited, consider a scenario with two types of repository users::
- An internal user, who is a developer within the organization and has write permissions on the repository.
- An external user, is an outsourced developer who has only read permissions and is restricted to working on a fork of the repository.
Imagine both users have malicious intentions. The repository contains sensitive secrets they aim to extract and transmit to a server controlled by hackers. They plan to leverage the vulnerabilities associated with PPE within the pipeline to execute this theft.
In both scenarios, they initiate a Pull Request containing identical changes:
- The pipeline and accompanying shell script are altered to extract the secret from the environment and transmit it to a server under hacker control.
Both users will create a Pull Request with the modifications. Upon creation of the PR, GitHub will execute both modifications (with no need for previous review or approval), resulting in the following:
For both the write and read users, D-PPE and I-PPE are carried out. However, the read user cannot access the secrets. This is due to GitHub’s security measures, which prevent access to repository secrets for pull requests from forks. While the read user cannot view the secrets, they are still able to execute other programs. An example of a potential attack involves submitting pull requests that trigger the download of a cryptocurrency miner, which then runs when the poisoned pipeline is executed.
This scenario compromises safety. To mitigate such risks, the repository administrator might need to take preventive actions. Upon researching, the admin might decide to change the pipeline’s trigger to a pull_request_target event. This adjustment is strategic because, under a pull_request_target trigger, any modifications made to the pipeline by users won’t affect the execution of the original, unaltered pipeline.
Following our example, the attack will be the same as before. What will happen then after this pipeline modification?
As anticipated, D-PPE does not occur; however, I-PPE persists, enabling the read user to access the repository’s secrets. How is this possible? Although the pipeline itself remains unchangeable, the associated shell script can still be altered. When a pipeline is initiated via a pull_request_target event, it runs in a privileged mode, which also extends to the shell script, thereby granting it access to the repository’s secrets.
Watch our Webinar on:
Some Preventive Measures against Poisoned Pipeline Execution
To safeguard against PPE threats, organizations must employ a multifaceted approach:
- Very Strict Access Controls: Implementing rigorous access controls and validation processes for any changes made to pipeline configurations.
- Security Scanning Tools: Utilizing tools that scan for vulnerabilities within the CI/CD pipelines can help identify and mitigate potential threats before they are exploited.
- Continuous Monitoring: Establishing systems to continuously monitor pipeline activities can help detect and address unusual or unauthorized actions indicative of PPE.
There is still a pending question though: how to avoid the I-PPE ?
Workflow Runs and Approval Requirements for GitHub Repositories
For managing external pull requests (PRs) in public repositories, GitHub offers settings to enhance control and security. By default, first-time contributors require approval, which complicates potential malicious attacks. More stringent options like requiring approvals for all outside collaborators are available. For private repositories, settings at both the organization and repo levels allow running workflows from forked PRs with restricted permissions, ensuring security. Critical settings include limiting token permissions and requiring approvals for workflows, mitigating risks associated with forked PRs.
Wrap up
Poisoned Pipeline Execution presents a formidable challenge, and it, emphasizes the necessity for comprehensive security measures. Organizations and teams must remain proactive in employing advanced security strategies and tools to protect their software development lifecycle from such insidious risks.
H2: How can Xygeni help you out?
At the forefront of combating CI/CD security risks, Xygeni offers a sophisticated CLI tool designed to detect and mitigate vulnerabilities such as PPE. This tool is integral to enhancing pipeline security, providing detailed scans, and maintaining an inventory of CI/CD assets. Xygeni facilitates proactive security management, ensuring that pipelines are not only efficient but also secure.
Do you want to know a bit more?
0 Comments