7.8 KiB
| layout | title | date |
|---|---|---|
| post | Package Managers - How To Install Malware On Your Systems | 2025-04-02 |
Open source software has made it much easier to rapidly develop software as it allows the reuse of code to solve particular problems. There is no need to write the same software from scratch over and over again - and in some cases, such as when implementing cryptographic libraries, the likelihood an implementation error is made are high - making open source software the obvious choice.
While it does make sense to use open source software, and it's the most optimal way to develop technologies in a way most equitable and helpful for the advancement of humanity, the approach most companies take today to ensure the secure usage of open source software is insufficient.
The "Industry Standard"
While most responsible companies have policies around reviewing first party code from their developers, there is a widely held belief that that is not necessary for third party dependencies. The confusing part about this is that in most cases, if you were to point out the window at a random person walking by and ask if it would be okay for that individual to make changes to a codebase without revision, most individuals would say that that it isn't okay. When the same question arises about whether it's okay for millions of lines of code by hundreds or even thousands of developers from around the globe to introduce changes to a codebase, most companies shrug and say that they use Static Application Security Testing (SAST) - but we all know this doesn't address the issue, otherwise supply chain attacks would not be nearly as common.
SAST and Spiderman
The industry participants point to each other for examples of how things are meant to be done. The problem is that not all companies have the same risk exposure. For some companies, they may tolerate attacks because they don't have assets that are as valuable as other's. A great example of this are companies handling digital assets. If a tech stack has the ability to move digital assets, or handles otherwise valuable data, different security measures are required. Using SAST and claiming it's a complete security control for supply chain risks is akin to putting a security guard at the front door of the building while the backdoor is unguarded. SAST will only reliably detect previously found vulnerabilities, as it is rule based. "Nobody else reviews all their dependencies" - yes, and that's why the compromises keep happening so frequntly and why attackers spend so much energy on this attack vector. According to a study by ReversingLabs, there has been a 1300% increase in the number of threats in software packages between 2020 and 2023 alone.
Getting Pwned via Package Managers
There is nothing sophisticated or mysterious about how package managers such as
npm and pypi result in full system compromise. Both of these package managers
run installation lifecycle scripts, which run under user permissons. Many attacks
rely on this, and simply run arbitrary code on the user's machine when they
install a given package. Unfortunately because privilege escalation attacks are
often fairly simple to do, the risk is exacerbated. The other common way that
packages can compromise a target if by modifiying the flow of regularly invoked
functions to perform additional actions or entirely change the expected
behavior of software. Typing "npm malware" or "pypi suppl chain attack" will
yield seemingly endless results but here are some "fun" highlights just from
this year so far:
-
March 26 2025: "These were simple downloaders whose malicious payload was cleverly hidden, with a second stage that “patches” the legitimate npm package ethers, installed locally, with a new file containing the malicious payload. That patched file ultimately serves a reverse shell." ref
-
April 1 2025: "... the official XPRL (Ripple) NPM package was compromised by sophisticated attackers who put in a backdoor to steal cryptocurrency private keys and gain access to cryptocurrency wallets" ref
-
June 5 2025: "One collection of PyPI packages is designed to "monkey patch" Solana key-generation methods by modifying relevant functions at runtime without making any changes to the original source code." ref
Who Wrote The Code?
Package managers are open ecosystems with contributors from all over the world,
and this means that essentially anyone on this planet can create a package and
upload it to npm or pypi, amongst other package managers. Some of these
individuals happen to be threat actors, whether individuals, or state funded
actors. In fact, in some cases attackers will purchase a library or use an
expired domain to take over a library that is already widely used, to attack
its unexpecting users, as was the case in the attack via the event-stream
package in 2018, but many similar attacks have occured
since (ref 1. Our co-founder and security engineer Lance
Vick performed an attack to illustrate how easy it can be to compromise a library
by purchasing a domain which allowed him to control the foreach npm package.
Review All The Code...
Some of you may be saying "you can't be serious, that's just too much code". If that's the case, you should likely consider cutting down on how much third party code is used in your stack. To reasonably secure a system, at the least, one should know what software is running in it. Rather than relying on the absence of a discovered exploit to certify an application’s security, organizations should mandate a comprehensive audit of every single line of code—both their own and in every supply-chain dependency. Only once this exhaustive review is complete can we meaningfully claim the software is reasonably secure. Today’s typical 1–2-week audit windows, however, fall dramatically short of the time required to manually vet millions of lines of code, exposing a fundamental gap in our security assurance process. If an organization chooses to just use SAST, it should not be surprised when it gets compromised by a supply chain attack.
Summary
Here are some high level takeways to keep in mind:
-
Package managers can easily run arbitrary code on a machine, both during installation and during runtime resulting in complete compromise.
-
Not reviewing every line of code manually will inevitably lead to compromise given a long enough time horizon.
-
SAST is a feel good measure that is not sufficient for ensuring code security.
-
If it can be done with the standard language library avoid adding dependencies.
-
Evaluate cost of using third party libraries based on how much it costs to review them rather than assigning them cost of $0 as they are free to use.
-
Consider donating to maintainers of your most important third party dependencies, both for development, and to pay for security assessments.