During the past decade or, terms like 'spyware', 'bloatware' and 'malware' have become a part of the technology lexicon. And not in a good way. Because if you strip the 'ware' part of those terms, you end up with the underlying intention for each of them. Spy. Bloat. And mal. Just recently, I read about a new kind of potential 'ware' floating around the internet dubbed 'protestware'.
Protestware refers to code that has been published with some form of malicious code intended to cause some level of harm to another party mainly to showcase some form of protest against those parties.
And once again, this malware involves the popular JavaScript package manager NPM. I say 'once again', because this isn't the first time that NPM has faced this exact issue. You can read more about the risks associated with NPM right over here.
The problem
Just recently, as of this writing, a very popular NPM package titled npm-ipc came under scrutiny when its initial author released sabotaged versions of the library that would essentially delete all of the data on its hosts computers. To add insult to injury, it would also create new text files with "peace" messages scattered throughout.
Not every computer was susceptible to this attack however. Because this wasn't your typical 'malware' scenario.
The author purposefully only targeted computers who's IP addresses were located either in Russia or Belarus. In a sense, it was a form of protest against those countries for their recent participation in war with the Ukrainian government.
Lying somewhere in between 'malware' and 'protestware', the update caused mixed emotions from the developer community, with some developers applauding the actions while many others spoke out against it all together.
The author eventually removed the malicious code after outcry from the dev community, many claiming that interrupting mission critical software applications could potentially lead to physical harm to innocent people, regardless of political leanings.
Other cases
While malware in general has been around for decades since the early inception of computing, protestware is a relative newcomer into the scene.
Because its intent isn't to cause complete and total failure of a system to everyone. It's intent is more so to get a message across, at the expense of software functionality. Sometimes that includes only certain people, but other times this may mean that anyone and everyone is a target.
Prior to this incident, another similar event involved two popular NPM libraries named colors.js and faker.js, both developer utilities with millions of weekly downloads. The authors in this case released a build that would essentially enter into an infinite loop and inevitably break any builds.
Looking into the code, developers located the source of the issue and found similar 'protest' like messages embedded.
Developers that morning woke up to potentially broken builds and what I would imagine to be hours of Googling for the answer.
In response to this particular event, GitHub release a security advisory notifying developers to downgrade to a previous functional version.
And there have been other such notable cases as well done for similar reasons.
Should we be worried
The truth is that there is no completely safe and secure system anywhere. All software is written by human people, much like myself and yourself, and we all make mistakes at some point. And often times, developers don't make mistakes, but the logic itself is fundamentally flawed from a business perspective.
In some cases, these mistakes happen on purpose.
The open-sourced community at the end of the day is still based on a labor of love economy and more and more we see developers single-handedly maintaining software used by thousands, if not millions, of developers world wide.
And that can very easily lead to burnout and stress which inevitably will impact the underlying project at hand. Some of the most popular open-sourced packages on NPM currently, with millions of weekly downloads, have not been updated in years.
Overall, I'm a huge fan of NPM and I use it daily for much of my work. But I am more cautious these days and I do my fair share of research before typing in the magical commands 'npm i'.
More so than just the number of downloads per week, I am also interested in the time and date of when the library was last modified and in who did the modifying as well.
Because we shouldn't be needlessly worrying, but we should always be cautious.
What's next
I don't expect the instances of this sub-category of malware to go away anytime soon. And in fact, the odds of it increasing during the next few years is quite high.
Now would be the time to add safety measures to your applications, in order to mitigate any potential future attack. You can start by assessing whether you actually need to use a library for a specific task, or if its something that you yourself can code with a couple of lines.
The next time that you choose to install a library, it might be worthwhile as well to review the list of dependencies that this package will include with it. Because those dependencies are definitely an added vector that could lead to problems down the line.
You can't really stop malicious code from being added to 3rd party code that you use. But you can at least help to reduce the overall impact that it will have when that time comes.