Open source software libraries are frequent targets of hackers, who see them as an attractive path for stealing credentials and distributing malware.
Hundreds of thousands of software projects depend on these open source packages – and each of these dependencies has its own dependencies, a complex web that some call “dependency hell” – so hackers know that any new version they successfully compromise will be downloaded by countless developers when they run npm, composer, pip, or other updates.
These software supply chain attacks are pretty hard to detect and mitigate, as the software supply chain is deeply integrated into the lifecycle of applications and websites.
In a week that saw some of the strangest supply chain attacks yet – more on those in a minute – a new open-source security initiative was launched to give developers some control over these sprawling libraries and dependencies.
Also read: Top Code Debugging and Code Security Tools
Pyrsia: A New Era for Open-source Security?
The developers of the JFrog DevOps platform this week announced the creation of project Pyrsia, a package network “designed to be entirely decentralized to give developers a reliable and secure package network that has full provenance of all the packages and artifacts they depend upon.”
The JFrog team collaborated with Docker, DeployHub, Futurewei, Huawei and Oracle to build Pyrsia. The main purpose of the new platform is to have “detailed transparent information across the supply chain” to make it more reliable.
With Pyrsia validating the source and security of open-source software packages. JFrog says developers “can confidently use open-source software knowing their components have not been compromised, without needing to build, maintain, or operate complex processes for securely managing dependencies.”
The project hopes it will help prevent supply chain attacks through signed commits, immutable history, “verifiable integrity of the packages and sources,” and open standards. Developers will be able to use digital signatures to “receive an immutable chain of evidence for their code, providing peace of mind from knowing the exact source of their package.”
Pyrsia is already available if you want to test it, just type the following in the terminal, per a tutorial:
curl -sS https://pyrsia.io/install.sh | sh
There’s also a GitHub repository if you want to discover the technology behind the platform. Developers will be able to indicate the chain of provenance of their software thanks to blockchain technology.
It appears to be the first initiative of its kind to secure package networks globally and give a decentralized infrastructure to developers to validate builds. The Pyrsia team focuses on integrating the tool into existing pipelines and workflows:
The platform also takes into account popular package managers, so developers do not have to modify CI/CD pipelines too much.
It should be noted that the project is in its early stages, so be careful and do not hesitate to give some feedback to the Pyrsia team. Nevertheless, the project has great potential to improve the current software supply chain significantly.
Also read: How Hackers Compromise the Software Supply Chain
PyPI, PHPass Hit in Latest Attacks
This week, a popular CTX package with around 20,000 downloads per week on PyPI has been compromised to steal a developer’s environment variables that can contain credentials like Amazon AWS keys.
The phpass package, a portable version of the widely-used PHPass framework (2.5 million downloads), has been attacked too. The malicious version was programmed to exfiltrate Amazon credentials, likely for the same actorâs profit, as the destination domain and the codeâs logic were identical.
Both libraries have been shut down by hosting platforms, but the damage is done. Developers should check their projects to determine if they have the hijacked versions and look for IoCs (indicator of compromise).
An Unusual Hack
Researcher Yunus Aydin, who goes by âSockpuppet,â claimed the attack and declared his intent was to prove the danger of the vulnerabilities he exploited.
Such a gray hat approach is unusual for a security researcher, but in his post, he describes in detail how he took over popular packages on various platforms such as PyPI, Composer (PHP), or Cargo (Rust).
According to Aydin, the maintainer of the CTX package was using a fake email on PyPI, âfiglief@figlief.com,â so he registered the fake domain to make that email usable and reset the password and take over the package:
The researcher said he used other known techniques to compromise platforms such as crates.io (Rust) or Packagist (PHP). For example, he created GitHub profiles with the same name as existing packages to leverage the functionality called âlogin with your GitHub accountâ and take over the packages.
His post is worth reading but be careful with any links, of course.
How to Protect Against Package Hijacking
If youâre a packageâs maintainer, you are strongly encouraged to apply the platform’s recommendations to mitigate or prevent attacks on your account.
All platforms and programming languages are suspect. The Rust Security Response WG has published a security advisory against malicious crate rustdecimal, a package with a name âintentionally similar to the name of the popular [`rust_decimal`][2] crate, hoping that potential victims would misspell its name (an attack called “typosquatting”).â
Indeed, domain takeovers and typosquatting techniques are known vectors of compromise. Thatâs why platforms scan repositories regularly to detect specific patterns and freeze (or remove) suspicious accounts.
Enabling two-factor or multi-factor authentication can also stop hackers who might have stolen your credentials.
If youâre a developer, youâd better have a strict vendor policy and ensure no update is running silently, which is unfortunately pretty common with package managers.
The software supply chain is becoming increasingly complex, as there are more and more interdependencies between packages and other reusable components. Pyrsia offers some hope here, but best practices remain important.
Further reading:
Application Security Vendor List
