9.2 KiB
| layout | title | date |
|---|---|---|
| post | Package managers - malware delivery as a service | 2025-04-02 |
Using third-party code, such as open source libraries 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 third party code the approach most companies take today to ensure its secure usage 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 the same is not necessary for third party dependencies. The confusing part about this is that in most cases, if someone was 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 would say that it isn't. 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) and monitoring - but we all intuitively know this doesn't reasonably mitigate the associated risks, otherwise supply chain attacks would not be nearly as common.
SAST, monitoring 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 monitoring, 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 and wide open. SAST and monitoring will only reliably detect previously found vulnerabilities, as they are typically rule or behaviour based, and can often be circumvented because the attackers design their attacks to evade detection. The SolarWinds attack occured despite sophisticated monitoring and SAST systems at one of the leading cybersecurity firms in the world. The nature of that compromise is such that full code review likely wouldn't have prevented the attack, reproducible builds would have (more on that another time), but the point is that there is an over-reliance on monitoring. "Nobody else reviews all their dependencies" - yes, and that's why the compromises keep happening so frequently 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 introducing non-vetted
code into an application results in compromise. If a function is imported and
used, its entire call stack comes along with it - which could be hiding
undesirable behavior. It gets worse because package managers such as npm and
pip can often result in full system compromise during the installation step,
before even running any application code. Both of these package managers run
installation life-cycle scripts, which are executed with user permissions. Many
attacks rely on this, and leverage these scripts to 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.Typing "npm malware", "pypi supply chain attack" or similar 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
So next time when installing a package, consider what is being installed. The
issue is that it's usually not just the top level dependency that will end up
being installed - there are often many sub-dependencies, and package managers
like npm will run the installation lifecycle scripts of each one. Of course this
isn't unique to npm, and pip, they are just highlighted as some they are
widely used, but this applies to package managers and third party code in
general.
Who Wrote The Code?
Package managers are part of open ecosystems with contributors from all over the
world, and this means that essentially anyone on this planet can write software,
and offer it as a package. 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 unassuming users, as was the case in the
attack via the event-stream package in 2018, but many
similar attacks have occurred since (ref 1). Our co-founder
and security engineer Lance Vick showed that an attack could be performed to
illustrate how easy it can be to compromise a library by purchasing a domain which could allow control the
foreach npm package. Just because something is widely used
it doesn't mean it's sufficiently reviewed and secure.
Review All The Code...
"All the code? That's just too much code to review". If that's the case, consider cutting down on how much third party code is used in the stack. Look for opportunities to remove libraries which are not necessary, libraries which duplicate functionality, huge libraries where only a small subset of them is used etc. 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 is it possible to meaningfully claim the supply chains is reasonably secure. Of course, even a full audit of code may not surface all code issues and there are other risks stemming, for example, from the way the code is built, or the runtime environment. The idea is to layer all defense mechanisms available, but admit that not reviewing third party code is a bad idea and that this needs to change.
Summary
Here are some high level takeaways to keep in mind:
-
Third party code 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/monitoring is a partial 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 though 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.