A security researcher has described how abusing permissions in source code management (SCM) repositories can lead to CI poisoning, or ‘poisoned pipeline attacks’.
Developer environments, including continuous integration (CI) and continuous delivery (CD) platforms, are fundamental building blocks for merging code, automating software builds, testing, and delivering code to DevOps projects.
Omer Gil, head of research at Cider Security, said in a technical blog post dated February 8 that due to the critical functions CI and CD environments play, they are also a “major part of today’s attack surface” and often contain an organization’s secrets and credentials.
Attackers able to compromise CI/CD environments may be able to access production areas or delivery mechanisms for wider supply chain attacks. Recent examples include poisoned software updates delivered by SolarWinds and Codecov, as well as an intrusion at Kaseya.
Poisoned pipeline execution
In July 2021, the European Union Agency for Cybersecurity (ENISA) examined supply chain incidents between 2020 and 2021 and said in a report that roughly 50% of cyber-attacks were attributed to an advanced persistent threat (APT) group, but unknown attacks were responsible for 42% of reported incidents.
ENISA added that over 60% of supply chain attacks “took advantage” of customer trust in their supplier, and 66% of cyber-attacks targeted supplier code to further compromise targeted customers.
The easiest way to access the CI and to perform a supply chain attack is to have direct access. According to Gil, however, a local technique could be also used to tamper with production pipelines without having direct access to CI environments.
Dubbed Poisoned Pipeline Execution (PPE), Gil says the technique focuses on a common way that pipelines are defined, by using CI configuration files hosted in pipeline repositories.
These files – typically found with standard formats including Jenkinsfile, .gitlab-ci.yml, .circleci/config.yml, and GitHub Actions YAML – contain commands that are triggered when pipeline jobs pull code from developer sources.
If attackers can tamper with command lists, they may be able to execute code in the CI.
This is where PPE comes in.
Attacking the CI pipeline
The poisoned pipeline attack vector requires a threat actor to have SCM permissions, such as user credentials or access tokens, to manipulate CI configuration files or similar content, and execute pipeline activity.
Attackers must also be able to tamper with these files without triggering reviews. Gil says that pipelines which execute unreviewed code are more susceptible to PPE attacks.
PPE has been separated into different categories:
- Direct (D-PPE) – Attackers modify CI configuration files located together with target projects
- Indirect (I-PPE) – Malicious code is injected into files invoked indirectly by pipeline configuration files
- Public (P-PPE/3PE) – Attackers need to be able to access repositories hosting pipeline configuration files, by obtaining credentials and/or permission. It may also be possible to compromise public projects through pull requests when unreviewed code is accepted and executed.
Once code execution has been established, attackers could access secrets related to the CI, push malicious jobs, ship malicious code, access external assets job nodes have permissions for, and they may also be able to access additional hosts or assets.
“Access to SCM organizations and repositories is obtained by attackers all the time,” Gil commented.
“Credentials, access tokens, and SSH keys are stolen by any of the classic attack methods such as phishing, credential stuffing, or lateral movement in a company’s internal network.”
He added: “PPE is a vector allowing attackers to leverage that access to execute malicious code in CI pipelines, leading the way for accessing production environments in a matter of minutes, or even seconds.”
On Reddit, some queried whether there is anything new about this attack vector, and whether the prerequisite for permissions negates the overall risk of PPE. Travis Biehn, principal security consultant at Synopsys Software Integrity Group, told The Daily Swig:
Omer Gil provides a non-alarmist view into a poorly understood attack vector. Is it overblown? Perhaps, but not by Omer. It is an unlikely choice for an attacker, and the scenarios where it’s convenient or necessary are few.
“It has been said that every company is a software company,” added Theresa Lanowitz, head of cybersecurity evangelism at AT&T Business. “If the applications that make up the digital experience are not built with a security-first approach, vulnerabilities will make it to production and ultimately be problematic for the business from a revenue, trust, or general security standpoint.
“Therefore, applications or applet – we are no longer writing monolithic back-office applications – created now and into the future need to not only be more compact and purpose-driven, but also built with security-in-mind.”
Source: https://portswigger.net/daily-swig/poisoned-pipelines-security-researcher-explores-attack-methods-in-ci-environments
