Commit | Line | Data |
---|---|---|
a45ecef0 JM |
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**, | |
0c65633d | 38 | use **direct verifiable links rather than just the package names** and if the package manger supports any form of hash checking |
a45ecef0 JM |
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 | |
0c65633d | 42 | to retrieve you the code by a simple prompt - the package name and version, you do not ask for any hash verification, neither do you |
a45ecef0 | 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 |
0c65633d JM |
44 | data can be overwritten by the package author. There are so many clear design flaws with these package managers that are essentially nothing |
45 | more than just dumb downloaders without any regard to security. | |
a45ecef0 | 46 | |
0c65633d | 47 | Even the simplest sha256 check would improve the situation, if nothing else. The ReactOS Applications Manager is a lot more secure |
a45ecef0 JM |
48 | by design compared to all of the afforementioned package managers just by the hash check alone. |
49 | ||
44160764 JM |
50 | ## So, don't share code at all? |
51 | I never said that. There is nothing wrong with sharing code, but code should still be under scrutiny, be it open or not, it must be | |
52 | audited before being integrated into a project and re-checked on updates. Personally, my interests align for open source being a net | |
53 | positive - I share [scripts for projects I do](/ssh-alerts-landchad-style/) and even the [source code for this very website.](https://git.based.quest/?p=web-hugo.git;a=shortlog;h=HEAD) | |
54 | ||
55 | If you fork a project using the above advice, please respect the license terms, give credit where due and if feasible, open a pull | |
56 | request upstream with your improvements. | |
57 | ||
a45ecef0 JM |
58 | ## Okay, but how does the industry "never learn"? |
59 | Simple, the package managers are still growing in popularity, there is no blowback, new developers are still being lead to use | |
60 | NPM, PyPi, Rust crates, public CDN CSS/JavaScript libraries, etc. There is no practice of auditing the code you are pulling at all. | |
0c65633d | 61 | The industry is increasing their bet on blind trust to save a penny in developer hours to achieve their desired result. |
a45ecef0 | 62 | In this industry, money speaks, so reducing costs by using fewer developers and shortcuts with these package managers is going to |
0c65633d JM |
63 | be the standard going forward. Maybe this will one day change with more rapid supply chain attacks that cost companies millions or |
64 | more per year in ransoms. | |
a45ecef0 JM |
65 | |
66 | ||
67 | ### Hater. | |
68 | Yes. You can't always skip the hard work. If this post offended you, I'm not sorry either. | |
69 | ||
70 | # | |
71 | Thanks for reading, | |
72 | - Cernodile |