| 1 | --- |
| 2 | title: "Supply chain attacks & how industry never learns" |
| 3 | date: 2022-09-22T20:45:00+03:00 |
| 4 | 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)." |
| 5 | tags: ['rant','opinion'] |
| 6 | type: blog |
| 7 | draft: false |
| 8 | --- |
| 9 | |
| 10 | If you have been in the industry for the last several years, you may have noticed an ever-increasing trend of |
| 11 | "convenient package managers for your favourite programming language". It's very much relevant in languages |
| 12 | such as Python, JavaScript, Rust and almost every new emerging programming language. However, |
| 13 | [all](https://thehackernews.com/2022/09/malicious-npm-package-caught-mimicking.html) [of](https://thehackernews.com/2022/05/researchers-uncover-rust-supply-chain.html) |
| 14 | [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) |
| 15 | [much](https://thehackernews.com/2022/07/researchers-uncover-malicious-npm.html) |
| 16 | [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) |
| 17 | [of](https://snyk.io/blog/open-source-maintainer-pulls-the-plug-on-npm-packages-colors-and-faker-now-what/) |
| 18 | [supply](https://thehackernews.com/2021/07/several-malicious-typosquatted-python.html) |
| 19 | [chain](https://thehackernews.com/2021/11/11-malicious-pypi-python-libraries.html) |
| 20 | [attacks](https://thehackernews.com/2022/03/a-threat-actor-dubbed-red-lili-has-been.html). |
| 21 | Those are just *some* of the examples. There are countless instances of this happening and they will continue to |
| 22 | happen due to low effort, high value and medium success. |
| 23 | |
| 24 | ## Surely this isn't as common? |
| 25 | It is much more common than you think. All a hacker needs to do is either hijack an existing registry user or |
| 26 | "typosquat" a package on very popular packages. This is further made easier by registries listing statistics such |
| 27 | as the "Weekly Downloads" and "Total Downloads" giving you a rough idea of how large of a pie you could poison. |
| 28 | All of this is doable by social engineering or betting on people making typos, which we all do make. |
| 29 | |
| 30 | ## What's your proposed solution? |
| 31 | Reduce amount of dependencies in your code. That's the easiest thing you can do to minimize attack vectors. |
| 32 | Usually libraries are created with "cover-all" functionality in mind, rather than just catering to your specific |
| 33 | use case, and even if it does cater to your use case, chances are it's overengineered. You will much more benefit |
| 34 | in performance, security and code quality by creating a lot of those said dependencies yourself - an added bonus |
| 35 | is becoming a much more versed programmer. |
| 36 | |
| 37 | Another solution is to fork the dependencies if you do need them, **audit the code of what you're going to be using**, |
| 38 | use **direct verifiable links rather than just package name** and if the package manger supports any form of hash checking |
| 39 | or other means to do so, use it! |
| 40 | |
| 41 | Which brings me to another point, the way a lot of current registries work are on blind trust basis - you trust the registry |
| 42 | to retrieve you code by a simple prompt - the package name and version, you do not ask for any hash verification, neither do you |
| 43 | 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 |
| 44 | data can be overwritten by the package author. There are so many clear design flaws with these package managers that are essentially |
| 45 | dumb downloaders without any regard to safety. |
| 46 | |
| 47 | Even the simplest sha256 check would improve the situation, if nothing else. ReactOS Applications Manager is a lot more secure |
| 48 | by design compared to all of the afforementioned package managers just by the hash check alone. |
| 49 | |
| 50 | ## Okay, but how does the industry "never learn"? |
| 51 | Simple, the package managers are still growing in popularity, there is no blowback, new developers are still being lead to use |
| 52 | NPM, PyPi, Rust crates, public CDN CSS/JavaScript libraries, etc. There is no practice of auditing the code you are pulling at all. |
| 53 | The industry is increasing their bet on blind trust to save a penny in developer hour cost to achieve their desired result. |
| 54 | In this industry, money speaks, so reducing costs by using fewer developers and shortcuts with these package managers is going to |
| 55 | be the standard going forward. Maybe this will one day change with more rapid supply chains that cost companies millions or more per |
| 56 | year in ransoms. |
| 57 | |
| 58 | |
| 59 | ### Hater. |
| 60 | Yes. You can't always skip the hard work. If this post offended you, I'm not sorry either. |
| 61 | |
| 62 | # |
| 63 | Thanks for reading, |
| 64 | - Cernodile |