Security researcher Omer Gil, head of research at Cider Security, has demonstrated a new way to abuse the permissions inside Source Code Management (SCM) repositories. This technique, called Poisoned Pipeline Execution (PPE), may lead to Continuous Integration (CI) poisoning or poisoned pipeline attacks.
About the PPE technique
PPE focuses on a general way how the pipelines are defined, by utilizing CI configuration files hosted in pipeline repositories.
These files are usually found with standard formats, including Jenkinsfile and .gitlab-ci[.]yml.
These formats include commands that are executed when pipeline jobs pull code from developer sources.
Therefore, if an attacker successfully tampers with command lists, they may execute malicious code in the CI.
How does the attack work?
The attack vector needs SCM permissions (user credentials or access tokens) for the manipulation of CI configuration files or similar content and execution pipeline activity.
An attacker is required to tamper with these files without triggering reviews. The pipelines that execute unreviewed code are more exposed to PPE attacks.
PPE can be carried out in three ways: Direct (D-PPE) (tampering of CI configuration files), Indirect (I-PPE) (Malicious code is injected into files involved indirectly), and Public (P-PPE/3PE) (targeting the repositories hosting pipeline configuration files).
Once code execution is done, the attackers can access secrets and even access additional hosts.
Recent attacks on CI/CD environments
There are many recent examples of poisoned software updates delivery, such as SolarWinds, Codecov, and Kaseya, that have highlighted the seriousness of this threat.
Applications not developed with a security-first approach are deemed to face challenges related to PPE. Thus, applications should be created in a compact, purpose-driven, and security-first manner. Doing so may lower the possibility of any vulnerabilities making it to production.