A 2-Week Prescription for Eliminating Supply Chain Threats
Hijacking opensource software packages to insert malicious code has become a popular way for attackers to spread malware rapidly across the software supply chain. But now new research has found that if users wait about 14 days before updating these software packages to new versions, they can avoid the downstream effects of package-hijack attacks.
Researchers at JFrog investigated the compromise of various open source software packages, some with hundreds of millions of downloads. They analyzed the timespan it took for the attack to be discovered, and how many times the package was downloaded before the malicious activity could be mitigated.
Ultimately, they found that can take from mere hours to more than a week for project developers or maintainers of those packages to discover the malicious code and produce an update that fixes the problem, according to a report shared with Dark Reading.
This means that waiting about two weeks before updating to any new version of an open source software package is generally a safe bet.
“Users that will wait about 14 days before updating to the latest version of a package (counting from the day that the latest version was published), should be immune from package-hijacking attacks, since in that timeframe the attack should be discovered and the malicious versions of the package will be removed,” Shachar Menashe, senior director of security research at JFrog, tells Dark Reading.
Rise of Package Hijacking
Package hijacking occurs when either an external threat actor or a project developer or maintainer himself or herself injections malicious code into an update of the package. Once this occurs, it’s only a matter of time before the users of the package figure out something is wrong, “either because of the hijack’s payload or simply by auditing the change to the package’s code,” Menashe explains.
The rise in popularity of package repositories such as npm and PyPI has given attackers a direct route to infecting tens of thousands of users in a matter of days with a package-hijack attack by compromising the opensource code that developers use to build a piece of software, he says.
It’s also easier to compromise the account of a developer on a repository site than it is to find a critical zero-day vulnerability and exploit it, making package hijacking both easier and a way to cause more widespread impact than a classic vulnerability attack, Menahse says.
Time to Detection Matters
JFrog researchers set out to find out how long it takes from when the package hijack is active to when users of the package figure out there is a problem and work with project developers to release an update.
“This timeframe is very significant since this is the timeframe where users of the package are actually susceptible to the attack,” Menashe says.
To identify a general timeframe for detection, they evaluated various package hijacking examples from two perspectives: external package hijacking and self-package hijacking.
The former occurs when a third party injects malicious code into the package — by hijacking a code-maintainer’s account of obfuscating malicious code as a legitimate contribution to the project. The latter occurs when legitimate developers or maintainers inject malicious code into a package as a form of protest.
External Package Hijacks
Cases of external package hijacking that JFrog researchers examined included hijacking of the PyTorch Python library using a malicious code dependency last December that targeted machine learning (ML) developers; and the separate compromises of the “ua-parser-js” and “coa” software packages with a cryptominer in October 2021 and November 2021, respectively.
The hijacks had the potential for significant ramifications for the developer community, as PyTorch has more than 180 million downloads and ua-parser-js nearly a billion, while coa is a cornerstone for more than 5 million open source repositories on GitHub and is downloaded about 9 million times weekly.
In the case of the PyTorch hijacking, it took users five days to discover that something was amiss, during which time the package was downloaded more than 3,000 times; users of the parser and coa took only hours to detect the malware in the packages, the researchers found.
Self-Package Hijacks
The JFrog team also investigated three examples of self-package hijacking, two of which — the “colors” and “faker” npm packages that are popular with Node.js developers — occurred simultaneously in January 2022 when the author sabotaged the packages with an infinite loop to protest against large corporations not contributing to the open source community.
The hijacking effectively bricked the software projects that depend on the packages, and were detected two days after the release of the malicious versions, the researchers found.
In March 2022, a developer 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. In this case, it took quite a while in developer time — roughly eight days — to discover the issue after the release of the malicious version of the package, according to JFrog.
Further Mitigations
Aside from a general rule of waiting about two weeks to update a software package to the latest version, developers and organizations also can address the threat of software supply chain attacks by vetting packages carefully before including them in their software, according to JFrog.
Curation tools are available that can help organizations define a set of rules to determine which packages developers can access or to block the downloading of third-party packages released less than 14 days ago. This can help prevent the download of packages from public repositories that carry potential security risks—such in cases of hijacked packages.
JFrog has also published a blog post to help developers and organizations detect how malicious code is hidden within software packages so they can avoid using them in their projects.
Read More HERE