N-Day Hijack: Analyzing the lifespan of package hijacking attacks
By
8 min read
Software package hijacking has become a prominent concern for individuals, businesses, and the cybersecurity community at large. We’ve seen this new threat trend rise over the past couple of years, with the potential to severely impact the software supply chain by attackers exploiting software packages to execute malicious code.
This blog post details a case study conducted by our security research team, in an effort to trace the typical time before a package hijack is detected. In these example cases, we discovered that waiting at least 14 days before upgrading to a new package version would have mitigated all of the package hijacking instances described in this blog post. Continue reading to get all the details.
The consequences of a software package hijacking attack can be severe, ranging data theft or corruption to installing malicious software. To reduce the risk of a package hijacking attack, organizations must take steps to ensure their software packages are secure and safe from malicious actors. This includes ensuring the packages are regularly vetted.
For further reading on this subject, learn more about the five examples of infection methods attackers use to spread malicious packages.
Case study – package hijacking in a year’s span (Nov 2021 – Dec 2022)
We can examine software package hijacking from two perspectives:
What is the software package hijacking infection method?
This method involves taking over a legitimate known package and pushing malicious code into it. While this is not an easy task, it’s very effective because it can take advantage of the popularity of available packages for a high infection rate. After the package hijack is detected, usually the package maintainers or the maintainers of the public repository (ex. npm) stop the attack by removing the malicious version, and publishing a new version, making it impossible to pull the infected version.
For example, the colors package hijacked versions 1.4.1, 1.4.2 and 1.4.44-liberty-2 don’t exist anymore.
Colors Package Current Versions Page – Excluding the Malicious Versions
1. External package hijacking
Back to Top >
Software package hijacking is usually performed by hacking the maintainers’ and developers’ accounts or by injecting hidden/obfuscated malicious code as part of a legitimate code contribution to an open-source project.
PyTorch
PyTorch is an exceedingly popular Python machine-learning library, with more than 180 million downloads.
On December 25, 2022, approximately 9 months ago, the PyTorch library was compromised by a dependency hijacking attack that specifically targeted Machine Learning (ML) developers.
The attacker managed to steal the PyTorch maintainer credentials and add a malicious dependency to the project. The malicious dependency package torchtriton potentially affected thousands of machines as it was downloaded more than 3K times in the span of just five days.
The malicious payload sent all Secure Shell (SSH) keys, environment variables, and other sensitive information, to the attacker’s server.
Malicious version creation: December 25th 2022.
Time before detection: 5 days.
Compromised PyTorch Dependency
ua-parser-js
Another example of a notable legitimate package that was attacked and hijacked is the ua-parser-js package.
ua-parser-js is a popular package with almost 1 billion downloads to date.
It was hijacked on October 22, 2021, and the incident was detected after just a few hours.
The intriguing thing about this package is that the malicious code injected into it (a cryptominer) was the same as in another malicious package, named klown, that impersonated the real ua-parser-js package.
Here is the announcement made by the package developer saying that he believes someone hijacked his package and published malicious versions of it.
”ua-parser-js” Hijacked Package Announcement By Owner
This incident and others required GitHub to enforce two-factor authentication for maintainers of popular npm packages:
Malicious version creation: October 22nd 2022.
Time before detection: a few hours.
coa
On November 4, 2021, the popular package coa was hijacked, which was detected after just a few hours. The payload was the same as in ua-parser-js (a cryptominer).
coa, an abbreviation for Command-Option-Argument, boasts a staggering 9 million weekly downloads on npm and serves as a cornerstone for nearly 5 million open-source repositories on GitHub. The attack was particularly insidious due to its exploitation of versions that had lain dormant for years, suddenly surfacing on npm. This unsuspected maneuver threw coa users into disarray, particularly React packages that hinged on this library.
This occurrence draws unsettling parallels to the hijacking of the ua-parser-js npm package, reminding the tech community of the growing vulnerability of software supply chains and the necessity for constant vigilance.
Malicious version creation: November 11th 2021
Time before detection: a few hours.
2. Self package hijacking – Protestware
Back to Top >
Software package hijacking can happen not only by malicious third parties but also by the developers and maintainers of the projects themselves. Usually just for the purpose of protesting for something they believe in.
We examined 3 publicized instances of developers hijacking their popular packages to protest: 1. faker, 2. Colors and 3. node-ipc.
faker and colors
The colors and faker npm packages are very popular with Node.js developers. colors allows developers to add styles, fonts, and colors to the Node.js console, and faker allows them to generate data for testing purposes during development.
These two packages were developed by the same author and are highly popular with millions of weekly downloads.
On January 7th, 2022, this author sabotaged the two packages to protest against large corporations that do not give back to the open-source community. An infinite loop was injected into their code which bricked thousands of projects that depend on them. This was detected 2 days after the release of the malicious versions.
By performing this single modification to the package code, many companies were affected by the malicious code that was added and bricked their products.
colors Hijacked Package Malicious Code in Action
Malicious version creation: January 7th 2022.
Time before detection: 2 days.
node-ipc
In another incident that happened on March 7th, 2022, the developer Brandon Miller added code to the node-ipc package that corrupts the file system of Russian and Belarusian machines, to protest against the 2022 Russian invasion of Ukraine. This was only detected 8 days(!) after the release of the malicious version.
When the malicious code detected that the machine had an IP address in Russia or Belarus, the code started to overwrite arbitrary files in the machine’s filesystem, replacing the file’s entire contents with a single byte – the ❤️ emoji.
Malicious version creation: March 7th 2022.
Time before detection: 8 days.
How long to wait before updating?
The following graph displays the detection time for all of the above hijacking incidents.
Number of days until the package hijack incident was detected
From the graph, it is easy to see that the maximum time for those cases to be caught was just over one week (8 days).
Our Recommendation: It’s safe to say that waiting a minimum of 14 days before downloading and using a new package version, would have mitigated all of the hijacked package cases mentioned above.
Curate software packages entering your organization
JFrog Curation addresses the threat of software supply chain attacks by enabling organizations to ensure packages are vetted before they are included in their software. It enforces a defined set of rules that determine which packages cannot be accessed by developers, 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, with a focus on hijacked packages as illustrated above, there’s a predefined rule to help you block the downloading of all 3rd-party packages whose version was released less than 14 days ago, mitigating the risk of a hijacked package dependency in your project.
JFrog Curation policy conditions
Immature package JFrog Curation policy details and block action
See what JFrog & GitHub can do together
