143 lines
9.2 KiB
Markdown
143 lines
9.2 KiB
Markdown
---
|
||
layout: post
|
||
title: Package managers - malware delivery as a service
|
||
date: 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](http://web.archive.org/web/20250226000211/https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/)
|
||
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](https://web.archive.org/web/20240806233532/https://3375217.fs1.hubspotusercontent-na1.net/hubfs/3375217/Documents/The-State-of-Software-Supply-Chain-Security-2024.pdf), 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](https://web.archive.org/web/20250118001432/https://www.reversinglabs.com/blog/a-lurking-npm-package-makes-the-case-for-open-source-health-checks)
|
||
|
||
* 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](https://web.archive.org/web/20250423022218/https://www.aikido.dev/blog/xrp-supplychain-attack-official-npm-package-infected-with-crypto-stealing-backdoor)
|
||
|
||
* 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](https://web.archive.org/web/20250605205948/https://thehackernews.com/2025/06/malicious-pypi-npm-and-ruby-packages.html)
|
||
|
||
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](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble) in 2018, but many
|
||
similar attacks have occurred since ([ref 1](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble)). 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](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble). 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.
|
||
|
||
|