Researchers Demo New CI/CD Attack in PyTorch Supply-Chain that Exploiting GitHub Self-Hosted Action Runner
The new guidelines to secure GitHub repositories are being followed by every enterprise. These new protocols were circulated after discovering a vulnerable loophole in the self-hosted action runner in August 2023.
To know more about the vulnerability, how and who discovered it, and its mitigation, read further.
Must To Understand Attack Prerequisites
Before you learn about the exact vulnerability and its exploitation, it’s necessary to gain an overview of one of the crucial terms: GitHub Self-Hosted Action Runner.
On the GitHub platform, multiple pre-configured runners are available for Windows, macOS, and Linux operating systems. Organizations can utilize these runners to commit, manage, and deploy their code to the production ecosystem.
Further, one of the runners on GitHub is a self-hosted runner. It allows enterprises to connect the GitHub repository with their on-premises infrastructure. It aids them to run multiple operating systems simultaneously and utilize additional software and hardware as required.
Primary Highlights of GitHub Self-Hosted Action Runner Exploitation
The GitHub vulnerability announced in December 2023 was the result of research concluded in August 2023 by two security researchers – Adnan Khan and John Stawinski.
During the research, it was discovered that GitHub self-hosted runners are vulnerable, and their unauthorized access can be effortlessly gained. With only a fork pull request, an attacker can gain access, execute arbitrary code and workflows, and retain its presence in the internal repositories.
While both Khan and Stawinski were drilling down the vulnerability, their victim list increased to the following repositories:
- Microsoft Deepspeed
- TensorFlow
- PyTorch
- Cloudflare application
- Crypto Wallets
- Blockchain nodes
Above all, PyTorch repository exploitation made this research popular, as it’s the most used machine learning algorithm.
The researchers submitted a fork pull request to the PyTorch repository, and they were added to the contributors list. It led them to access other workflows inside the repo and perform actions of their choice. In addition, admin credentials, AWS secrets, and security tokens were breached while analyzing the exploit.
Furthermore, the vulnerability was so easy to exploit that researchers only corrected a typo and submitted the pull request. Following this, the request was approved, and the privilege to execute malicious code was automatically handed over. Also, they were able to execute GitHub PATs, modify branch paths, and upload malicious releases to production.
However, there’s a twist to exploiting this self-hosted runner vulnerability. The attacker’s pull request must be approved once so that while performing the attack, they don’t get detected as first-time contributors.
The Final Result of the Research
The final conclusion of the research is as follows:
- The settings of fork pull requests being committed without approval make the repositories vulnerable.
- Once exploited, confidential data inside the repository can be accessed by a contributor.
- If weak security mechanisms are implemented, attackers can gain entry into on-premises infrastructure.
- An attacker can use the vulnerable loophole to add malicious code in the final source code repo. It will lead the customer base to be a victim of a malware attack.
- Immediate action is required by enterprises to patch the vulnerability.
What Happened After Reporting the Vulnerability?
After conducting research and performing all significant exploitation methods, Khan and Stawinski reported the issue to GitHub and all other repository owners.
They mirrored the procedures and modified the pull request approval settings to mitigate the attacks. Also, GitHub published new guidelines for companies using the same settings as PyTorch to help them prevent CI/CD attacks.
Moreover, after the report was validated, researchers got a bounty of $20,000 and $5,000 from GitHub and Meta AI (PyTorch developer company), respectively.
Concluding Up: What You Should Execute Next?
To safeguard your GitHub repos and associated on-premises infrastructure, you should modify the pull request settings from “Require approval for first-time contributors” to “Require approval for all outside collaborators.”
In addition, you must check the content of every pull request and the contributor’s history and authenticity before approval. As a result, the chances of suffering a cyber-attack and compromising the software supply chain will be reduced.
