Revival Hijack | |
Type of Malware | Dropper |
Date of Initial Activity | 2024 |
Motivation | Cyberwarfare |
Attack Vectors | Supply Chain |
Targeted Systems | Windows |
Overview
In the ever-evolving landscape of open-source software, security threats continue to grow in sophistication, targeting both developers and the platforms they rely on. A recent discovery by JFrog’s security research team has brought attention to a dangerous new attack vector, dubbed “Revival Hijack,” which poses a significant risk to users of the Python Package Index (PyPI). This newly identified exploit takes advantage of the platform’s policy regarding removed packages, allowing attackers to hijack package names that were previously deleted. By re-registering these names under their own accounts and replacing legitimate code with malicious payloads, attackers can easily distribute harmful code to developers who trust the integrity of the packages they use.
The Revival Hijack technique leverages a unique loophole within PyPI’s package management system. When a package is deleted by its original developer, its name becomes immediately available for re-registration. This allows malicious actors to swoop in and claim the same name, effectively replacing the original package with a malicious version. Developers who had previously used the legitimate package may unknowingly install or update to the hijacked version, believing it to be safe. This exploit is particularly dangerous because it doesn’t rely on user error, like typosquatting, but instead on a flaw in the platform’s design that permits easy package hijacking once the original package is removed.
Targets
Individuals
Information
How they operate
The attack begins when a package author deletes a previously published package from PyPI. Normally, this removal action is intended to retire outdated or abandoned projects. However, once a package is deleted, its name becomes available for anyone else to claim. This is where the Revival Hijack technique comes into play. Malicious actors, after identifying deleted but popular packages, quickly re-register the package name under their own account. They then upload a new version of the package containing malicious code, which can be easily disguised as a legitimate update.
When developers who previously used the original package attempt to update their dependencies using tools like pip, they may unknowingly install the hijacked version. In many cases, these packages are marked as outdated or in need of an update, triggering an automatic upgrade in CI/CD pipelines or during routine maintenance. This creates a pathway for attackers to distribute malicious code widely, as the new “update” is considered legitimate and trusted by the development environment. Since the hijacked package retains the same name as the original, users are unaware of the change, and no warning is triggered by tools like pip during the installation process. This silent installation of malicious packages is a key component of the Revival Hijack campaign’s success.
To illustrate how the attack works, consider the following steps involved in a typical Revival Hijack exploit: an attacker begins by creating a legitimate package with a name that mirrors a deleted, popular package. Once the original package is removed from PyPI, the attacker re-registers the same name and uploads a new version of the package. This new version contains malicious code, which is now distributed as part of the package’s legitimate update. Developers who had previously used the legitimate package, upon running their typical update commands, inadvertently install the malicious version without any indicators of compromise.
In their research, JFrog found that over 22,000 packages on PyPI were vulnerable to this attack, with thousands of developers unwittingly at risk. While this figure represents a concerning number, it is important to note that the vulnerability is particularly dangerous for packages that have been removed but remain actively used in development projects. For instance, developers may still rely on these packages in automated systems, and the likelihood of these developers installing the malicious version increases as they update their dependencies. The attack’s success is therefore amplified in environments where packages are regularly updated or reinstalled, such as in CI/CD pipelines, which can propagate the malicious code far and wide without manual intervention.
The technical risk associated with the Revival Hijack campaign has prompted immediate action from the security community. In response to this vulnerability, JFrog took the proactive step of securing thousands of abandoned and vulnerable packages by reserving their names under a “security_holding” account. This action ensured that the hijacked packages could not be re-registered by malicious actors. The reserved packages were replaced with empty, benign versions, effectively neutralizing the threat of a malicious package taking control of the package name. While this approach temporarily mitigates the risk, it highlights the need for better safeguards within PyPI’s package management system to prevent this kind of abuse in the future.
In conclusion, the Revival Hijack campaign represents a unique and effective attack vector in the open-source ecosystem. By exploiting the re-registration of removed packages, attackers can hijack trusted package names and distribute malicious code without any interaction from the victim. As this technique relies on the natural behavior of automated systems like CI/CD pipelines, its impact can be widespread and devastating. Developers and maintainers must remain vigilant, ensuring they adopt proper security practices and tools to mitigate the risks posed by such vulnerabilities. Additionally, platform administrators must work to implement stronger safeguards that prevent the hijacking of package names and protect the integrity of open-source software repositories.
