content/posts/supply-chain-attacks-industry-never-learns.md

   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 the package names** 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 the 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 nothing
  45 more than just dumb downloaders without any regard to security.
  46
  47 Even the simplest sha256 check would improve the situation, if nothing else. The 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 ## 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
  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.
  61 The industry is increasing their bet on blind trust to save a penny in developer hours to achieve their desired result.
  62 In this industry, money speaks, so reducing costs by using fewer developers and shortcuts with these package managers is going to
  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.
  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