based.quest – Supply chain attacks & how industry never learns

Posted on 22/09/2022 20:45:00

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 of them are very much possible targets of supply chain attacks. 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 the package names 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 the 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 nothing more than just dumb downloaders without any regard to security.

Even the simplest sha256 check would improve the situation, if nothing else. The ReactOS Applications Manager is a lot more secure by design compared to all of the afforementioned package managers just by the hash check alone.

So, don’t share code at all?

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 audited before being integrated into a project and re-checked on updates. Personally, my interests align for open source being a net positive - I share scripts for projects I do and even the source code for this very website.

If you fork a project using the above advice, please respect the license terms, give credit where due and if feasible, open a pull request upstream with your improvements.

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 hours 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 chain attacks 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