From: Joann Mõndresku Date: Thu, 22 Sep 2022 17:52:06 +0000 (+0300) Subject: Supply chain attacks. X-Git-Url: https://git.based.quest/%24%24URL?a=commitdiff_plain;h=a45ecef072f6603768d96efcdb598dfb7b7d7c9f;p=web-hugo.git Supply chain attacks. --- diff --git a/content/posts/supply-chain-attacks-industry-never-learns.md b/content/posts/supply-chain-attacks-industry-never-learns.md new file mode 100644 index 0000000..a7a828b --- /dev/null +++ b/content/posts/supply-chain-attacks-industry-never-learns.md @@ -0,0 +1,64 @@ +--- +title: "Supply chain attacks & how industry never learns" +date: 2022-09-22T20:45:00+03:00 +description: "If you have been in the industry for the last several years, you may have noticed an ever-increasing trend of convenience package managers. They all come riddled with design flaws at expense of your security (or lack thereof)." +tags: ['rant','opinion'] +type: blog +draft: false +--- + +If you have been in the industry for the last several years, you may have noticed an ever-increasing trend of +"convenient package managers for your favourite programming language". It's very much relevant in languages +such as Python, JavaScript, Rust and almost every new emerging programming language. However, +[all](https://thehackernews.com/2022/09/malicious-npm-package-caught-mimicking.html) [of](https://thehackernews.com/2022/05/researchers-uncover-rust-supply-chain.html) +[them](https://jfrog.com/blog/python-wheel-jacking-in-supply-chain-attacks/) [are](https://thehackernews.com/2022/04/npm-bug-allowed-attackers-to-distribute.html) [very](https://thehackernews.com/2022/07/over-1200-npm-packages-found-involved.html) +[much](https://thehackernews.com/2022/07/researchers-uncover-malicious-npm.html) +[possible](https://thehackernews.com/2022/05/malicious-npm-packages-target-german.html) [targets](https://thehackernews.com/2022/03/over-200-malicious-npm-packages-caught.html) +[of](https://snyk.io/blog/open-source-maintainer-pulls-the-plug-on-npm-packages-colors-and-faker-now-what/) +[supply](https://thehackernews.com/2021/07/several-malicious-typosquatted-python.html) +[chain](https://thehackernews.com/2021/11/11-malicious-pypi-python-libraries.html) +[attacks](https://thehackernews.com/2022/03/a-threat-actor-dubbed-red-lili-has-been.html). +Those are just *some* of the examples. There are countless instances of this happening and they will continue to +happen due to low effort, high value and medium success. + +## Surely this isn't as common? +It is much more common than you think. All a hacker needs to do is either hijack an existing registry user or +"typosquat" a package on very popular packages. This is further made easier by registries listing statistics such +as the "Weekly Downloads" and "Total Downloads" giving you a rough idea of how large of a pie you could poison. +All of this is doable by social engineering or betting on people making typos, which we all do make. + +## What's your proposed solution? +Reduce amount of dependencies in your code. That's the easiest thing you can do to minimize attack vectors. +Usually libraries are created with "cover-all" functionality in mind, rather than just catering to your specific +use case, and even if it does cater to your use case, chances are it's overengineered. You will much more benefit +in performance, security and code quality by creating a lot of those said dependencies yourself - an added bonus +is becoming a much more versed programmer. + +Another solution is to fork the dependencies if you do need them, **audit the code of what you're going to be using**, +use **direct verifiable links rather than just package name** and if the package manger supports any form of hash checking +or other means to do so, use it! + +Which brings me to another point, the way a lot of current registries work are on blind trust basis - you trust the registry +to retrieve you code by a simple prompt - the package name and version, you do not ask for any hash verification, neither do you +ask for means to verify the author. You can't even be sure that package v0.0.1 is the same thing as it was a week ago, because that +data can be overwritten by the package author. There are so many clear design flaws with these package managers that are essentially +dumb downloaders without any regard to safety. + +Even the simplest sha256 check would improve the situation, if nothing else. ReactOS Applications Manager is a lot more secure +by design compared to all of the afforementioned package managers just by the hash check alone. + +## Okay, but how does the industry "never learn"? +Simple, the package managers are still growing in popularity, there is no blowback, new developers are still being lead to use +NPM, PyPi, Rust crates, public CDN CSS/JavaScript libraries, etc. There is no practice of auditing the code you are pulling at all. +The industry is increasing their bet on blind trust to save a penny in developer hour cost to achieve their desired result. +In this industry, money speaks, so reducing costs by using fewer developers and shortcuts with these package managers is going to +be the standard going forward. Maybe this will one day change with more rapid supply chains that cost companies millions or more per +year in ransoms. + + +### Hater. +Yes. You can't always skip the hard work. If this post offended you, I'm not sorry either. + +# +Thanks for reading, +- Cernodile