diff --git a/_posts/2025-06-07-package-managers.md b/_posts/2025-06-07-package-managers.md index 35d473a..16f2464 100644 --- a/_posts/2025-06-07-package-managers.md +++ b/_posts/2025-06-07-package-managers.md @@ -4,32 +4,32 @@ title: Package managers - malware delivery as a service date: 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. +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 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. +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 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 -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 -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) and monitor - but we all know this doesn't -address the issue, otherwise supply chain attacks would not be nearly as common. +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 and Spiderman +## SAST, monitoring and Spiderman ![](/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 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](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. +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, 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 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 is 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 supply chain attack" will +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 +`pypi` 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: @@ -71,44 +80,48 @@ this year so far: 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. +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? -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](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 -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). +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... -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 only use SAST -and monitoring solutions, it should not be surprised when it gets compromised -by a supply chain attack. +"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 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. * Not reviewing every line of code manually will inevitably lead to compromise