public
/
website
5
0
Fork 0
Code Issues 6 Pull Requests 4 Packages Projects Releases Wiki Activity

improve content

This commit is contained in:
Anton Livaja 2025-06-13 04:48:22 -07:00
parent 2b198a29b2
commit 5bfae12d6e
Signed by: anton
GPG Key ID: 44A86CFF1FDF0E85
1 changed files with 76 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

139
_posts/2025-06-07-package-managers.md
View File

@ -4,32 +4,32 @@ title: Package managers - malware delivery as a service
date: 2025-04-02 date: 2025-04-02
--- ---
Open source software has made it much easier to rapidly develop software as it Using third-party code, such as open source libraries has made it much easier to
allows the reuse of code to solve particular problems. There is no need to write rapidly develop software as it allows the reuse of code to solve particular
the same software from scratch over and over again - and in some cases, such as problems. There is no need to write the same software from scratch over and over
when implementing cryptographic libraries, the likelihood an implementation again - and in some cases, such as when implementing cryptographic libraries,
error is made are high - making open source software the obvious choice. 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 While it does make sense to use third party code the approach most companies
optimal way to develop technologies in a way most equitable and helpful for the take today to ensure its secure usage is insufficient.
advancement of humanity, the approach most companies take today to ensure
the secure usage of open source software is insufficient.
## The "Industry Standard" ## The "Industry Standard"
While most responsible companies have policies around reviewing first party While most responsible companies have policies around reviewing first party
code from their developers, there is a widely held belief that that is not 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 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 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 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 without revision, most would say that it isn't. When the same question arises
same question arises about whether it's okay for millions of lines of code by about whether it's okay for millions of lines of code by hundreds or even
hundreds or even thousands of developers from around the globe to introduce thousands of developers from around the globe to introduce changes to a
changes to a codebase, most companies shrug and say that they use Static codebase, most companies shrug and say that they use Static Application Security
Application Security Testing (SAST) and monitor - but we all know this doesn't Testing (SAST) and monitoring - but we all intuitively know this doesn't
address the issue, otherwise supply chain attacks would not be nearly as common. reasonably mitigate the associated risks, otherwise supply chain attacks would
not be nearly as common.
## SAST and Spiderman ## SAST, monitoring and Spiderman
![](/assets/base/spiderman-meme.png) ![](/assets/base/spiderman-meme.png)
@ -39,26 +39,35 @@ 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 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, handling digital assets. If a tech stack has the ability to move digital assets,
or handles otherwise valuable data, different security measures are required. or handles otherwise valuable data, different security measures are required.
Using SAST and claiming it's a complete security control for supply chain Using SAST and monitoring, and claiming it's a complete security control for
risks is akin to putting a security guard at the front door of the building supply chain risks is akin to putting a security guard at the front door of the
while the backdoor is unguarded. SAST will only reliably detect previously found building while the backdoor is unguarded and wide open. SAST and monitoring
vulnerabilities, as it is rule based. "Nobody else reviews all their dependencies" - will only reliably detect previously found vulnerabilities, as they are
yes, and that's why the compromises keep happening so frequntly and why attackers typically rule or behaviour based, and can often be circumvented because the
spend so much energy on this attack vector. According to a study by 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/)
[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 occured despite sophisticated monitoring and SAST systems at one of the leading
in the number of threats in software packages between 2020 and 2023 alone. 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, 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 ## Getting Pwned via Package Managers
There is nothing sophisticated or mysterious about how package managers such as There is nothing sophisticated or mysterious about how introducing non-vetted
`npm` and `pypi` result in full system compromise. Both of these package managers code into an application results in compromise. If a function is imported and
run installation lifecycle scripts, which run under user permissons. Many attacks used, its entire call stack comes along with it - which could be hiding
rely on this, and simply run arbitrary code on the user's machine when they undesirable behavior. It gets worse because package managers such as `npm` and
install a given package. Unfortunately because privilege escalation attacks are `pypi` can often result in full system compromise during the installation step,
often fairly simple to do, the risk is exacerbated. The other common way that before even running any application code. Both of these package managers run
packages can compromise a target is by modifiying the flow of regularly invoked installation life-cycle scripts, which are executed with user permissions. Many
functions to perform additional actions or entirely change the expected attacks rely on this, and leverage these scripts to run arbitrary code on the
behavior of software. Typing "npm malware" or "pypi supply chain attack" will 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 yield seemingly endless results but here are some "fun" highlights just from
this year so far: this year so far:
@ -71,44 +80,48 @@ this year so far:
So next time when installing a package, consider what is being installed. The 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 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 being installed - there are often many sub-dependencies, and package managers
like npm will run the installation lifecycle scripts of each one. like npm will run the installation lifecycle scripts of each one. Of course this
isn't unique to `npm`, and `pypi`, 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? ## Who Wrote The Code?
Package managers are open ecosystems with contributors from all over the world, Package managers are part of open ecosystems with contributors from all over the
and this means that essentially anyone on this planet can create a package and world, and this means that essentially anyone on this planet can write software,
upload it to `npm` or `pypi`, amongst other package managers. Some of these and offer it as a package. Some of these individuals happen to be threat actors,
individuals happen to be threat actors, whether individuals, or state funded whether individuals, or state funded actors. In fact, in some cases attackers
actors. In fact, in some cases attackers will purchase a library or use an will purchase a library or use an expired domain to take over a library that is
expired domain to take over a library that is already widely used, to attack already widely used, to attack its unassuming users, as was the case in the
its unexpecting users, as was the case in the [attack via the `event-stream` [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
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 occured 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
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 and security engineer Lance Vick showed that an attack could be performed to
Vick showed that an attack could be performed to illustrate how easy it can be illustrate how easy it can be to compromise a library by [purchasing a domain which could allow control the
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
`foreach` npm package](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble). it doesn't mean it's sufficiently reviewed and secure.
## Review All The Code... ## Review All The Code...
Some of you may be saying "you can't be serious, that's just too much code". If "All the code? That's just too much code to review". If that's the case,
that's the case, you should likely consider cutting down on how much third party consider cutting down on how much third party code is used in the stack. Look
code is used in your stack. To reasonably secure a system, at the least, one for opportunities to remove libraries which are not necessary, libraries which
should know what software is running in it. Rather than relying on the absence duplicate functionality, huge libraries where only a small subset of them is
of a discovered exploit to certify an application’s security, organizations used etc. To reasonably secure a system, at the least, one should know what
should mandate a comprehensive audit of every single line of code—both their software is running in it. Rather than relying on the absence of a discovered
own and in every supply-chain dependency. Only once this exhaustive review is exploit to certify an application’s security, organizations should mandate a
complete can we meaningfully claim the software is reasonably secure. Today’s comprehensive audit of every single line of code—both their own and in every
typical 1–2-week audit windows, however, fall dramatically short of the time supply-chain dependency. Only once this exhaustive review is complete is it
required to manually vet millions of lines of code, exposing a fundamental gap possible to meaningfully claim the supply chains is reasonably secure. Of course,
in our security assurance process. If an organization chooses to only use SAST even a full audit of code may not surface all code issues and there are other
and monitoring solutions, it should not be surprised when it gets compromised risks stemming, for example, from the way the code is built, or the runtime
by a supply chain attack. 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 ## Summary
Here are some high level takeways to keep in mind: Here are some high level takeaways to keep in mind:
* Package managers can easily run arbitrary code on a machine, both during * Third party code can easily run arbitrary code on a machine, both during
installation and during runtime resulting in complete compromise. installation and during runtime resulting in complete compromise.
* Not reviewing every line of code manually will inevitably lead to compromise * Not reviewing every line of code manually will inevitably lead to compromise