In recent years, the issue of software package hijacking has gained considerable prominence, posing a substantial threat to individuals, businesses, and the global cybersecurity community. This dynamic and evolving menace has the capacity to profoundly disrupt the software supply chain by enabling malicious actors to execute harmful code through exploited software packages.
In this blog post, we present a comprehensive case study meticulously conducted by our dedicated security research team. Our primary objective is to provide valuable insights into the average duration it takes to identify a package hijacking incident. This analysis underscores the critical significance of maintaining a vigilant stance within the Indian software ecosystem.
The consequences of a software package hijacking attack can be dire, ranging from data theft or corruption to the installation of malicious software. To mitigate the risk of such attacks, organizations in India and around the world must take proactive steps to secure their software packages, including regular vetting.
For further insights into this topic, we delve into the five examples of infection methods employed by attackers to disseminate malicious packages.
We can examine software package hijacking from two perspectives:
- External package hijacking.
- Self package hijacking.
“JFrog Curation addresses the threat of software supply chain attacks by empowering organizations to vet packages before inclusion in their software.“
Prasanna Raghavendra – Sr. Director R&D, JFrog India.
Understanding Software Package Hijacking Infection Methods
This method involves commandeering a reputable and widely-used package and inserting malicious code into it. Although not a straightforward endeavor, it yields significant efficacy owing to the widespread adoption of such packages, resulting in a high rate of infection. Upon the detection of a package hijacking, it is customary for package maintainers or administrators of public repositories (e.g., npm) to promptly intervene by removing the compromised version and releasing a new one, thereby rendering the tainted version inaccessible.
For instance, versions 1.4.1, 1.4.2, and 1.4.44-liberty-2 of the “colors” package no longer exist.
External Package Hijacking
Typically, software package hijacking is carried out by hacking the accounts of maintainers and developers or by injecting hidden or obfuscated malicious code as part of a legitimate code contribution to an open-source project.
PyTorch
PyTorch, a widely used Python machine-learning library with over 180 million downloads, experienced a dependency hijacking attack on December 25, 2022, approximately nine months ago. This attack specifically targeted Machine Learning (ML) developers.
The attacker gained access to PyTorch maintainer credentials and introduced a malicious dependency called “torchtriton” into the project. The malicious package was downloaded over 3,000 times within just five days.
The malicious payload transmitted all Secure Shell (SSH) keys, environment variables, and other sensitive information to the attacker’s server.
ua-parser-js
Another notable example is the ua-parser-js package, a widely used package with nearly 1 billion downloads to date.
This package was hijacked on October 22, 2021, and the intrusion was detected within a few hours. Notably, the injected malicious code was a cryptominer, identical to one found in another malicious package called “klown,” which impersonated the genuine ua-parser-js package.
The package developer issued a statement, suspecting that his package had been hijacked and that malicious versions had been published. This incident and others prompted GitHub to enforce two-factor authentication for maintainers of popular npm packages.
Malicious version created: October 22nd, 2022.
Time before detection: a few hours.
coa
On November 4, 2021, a noteworthy event unfolded within the software development community. The widely-used “coa” package was the victim of a hijacking incident, and its compromise was swiftly detected within a matter of hours. The payload of this attack closely resembled that of ua-parser-js, involving the illicit implementation of a crypto-miner.
The significance of “coa” cannot be overstated; it commands an impressive user base with a staggering 9 million weekly downloads on npm, serving as a foundational component for nearly 5 million open-source repositories hosted on GitHub. What makes this breach all the more disconcerting is that it targeted versions of “coa” that had remained dormant for years, suddenly reappearing on npm’s radar. This unexpected resurgence left coa users, particularly those reliant on React packages, in a state of confusion and vulnerability.
This incident serves as a stark reminder of the parallels it shares with the hijacking of the ua-parser-js npm package. It underscores the escalating threats faced by software supply chains and emphasizes the imperative need for an unwavering commitment to vigilance in our ever-evolving digital landscape.
Self Package Hijacking – Protestware
Software package hijacking can occur not only due to malicious third parties but also as a result of actions by developers and project maintainers themselves, often as a form of protest for causes they believe in.
We examined three publicized instances of developers hijacking their popular packages to protest: faker, Colors, and node-ipc.
faker and Colors
The “colors” and “faker” npm packages are highly popular among Node.js developers. “colors” allows developers to add styles, fonts, and colors to the Node.js console, while “faker” enables them to generate data for testing purposes during development.
Both packages were developed by the same author and are extensively used with millions of weekly downloads.
On January 7th, 2022, the author sabotaged both packages as a protest against large corporations that did not contribute to the open-source community. An infinite loop was injected into their code, rendering thousands of projects that depended on them unusable. Detection occurred two days after the release of the malicious versions.
A single modification to the package code had widespread consequences, affecting many companies and their products.
node-ipc
In another incident on March 7th, 2022, developer Brandon Miller added code to the “node-ipc” package to corrupt the file systems of Russian and Belarusian machines. This was done to protest against the 2022 Russian invasion of Ukraine and was only detected eight days after the release of the malicious version.
When the malicious code detected a machine with an IP address in Russia or Belarus, it began overwriting arbitrary files in the machine’s filesystem, replacing their entire contents with a single character: the ❤️ emoji.
How Long Should You Wait Before Updating?
The graph below illustrates the time it took to detect the various hijacking incidents mentioned above.
From the graph, it is evident that the maximum time for detection in these cases was just over one week (8 days).
Our Recommendation: It is advisable to wait a minimum of 14 days before downloading and using a new package version, as this would have mitigated all the package hijacking cases discussed here.
JFrog Curation addresses the threat of software supply chain attacks by empowering organizations to vet packages before inclusion in their software. It enforces predefined rules that determine which packages developers can access, effectively preventing the download of packages carrying potential security risks or licensing conflicts from public repositories to internal remote repositories. When considering instances of malicious packages, particularly hijacked packages, as highlighted in this analysis, there is a predefined rule that can assist in blocking the downloading of all third-party packages with versions released less than 14 days ago. This proactive measure mitigates the risk of depending on a hijacked package in your project, making it a vital consideration for the Indian software ecosystem.
