At this point, the existence of these attacks should be an expected outcome. (It should have been expected even without the empirical record we now have and the multiple times that we can now cite.)
NPM and NPM-style package managers that are designed to late-fetch dependencies just before build-time are already fundamentally broken. They're an end-run around the underlying version control system, all in favor of an ill-considered, half-baked scheme to implement an alternative approach to version control of the package manager project maintainers' devising.
And they provide cover for attacks like this, because they encourage a culture where, because one's dependencies are all "over there", the massive surface area gets swept under the rug and they never get reviewed (because 56K NPM users can't be wrong).
I know I shouldn’t but I find it hilarious that whoever wrote this wrote the malware so explicitly. Something about functions like exfiltrateCredentials and clear comments for the backdoor makes me chuckle. They went through all the trouble to detect debuggers and sandboxes and did not even bother to obfuscate the code.
These LLM-generated blogs aren't going away – they're everywhere. And the best part? You can now instantly push out garbage content at no cost. Traditional writing is not just dead. It's legacy. The real marketer doesn't care. He just slops.
> the kind of dependency developers install without a second thought
Kind of a terrifying statement, right there.
Using this package is a security failure from the beginning. It doesn’t use the public WhatsApp API, it reimplements the official WhatsApp client auth. Authentication uses a shared secret and it’s obvious that you as a third party obtaining this secret from your users is unsafe and a bad practice (especially if it’s third party code processing it!).
Users should know better as well but you can’t really blame them.
Is there no Apache Commons for Javascript? It'd be nice to have a large library from a 'trusted' group.
> The lotusbail npm package presents itself as a WhatsApp Web API library - a fork of the legitimate @whiskeysockets/baileys package.
> The package has been available on npm for 6 months and is still live at the time of writing.
> (...) malware that steals your WhatsApp credentials, intercepts every message, harvests your contacts, installs a persistent backdoor, and encrypts everything before sending it to the threat actor's server.
If one relies on the JS ecosystem to put food on the table and can't realistically make changes at their job to mitigate this, short of developing on a second airgapped work-only computer what can developers do to at least partially mitigate the risk? I've heard others mention doing all development in docker containers. Perhaps using a Linux VM?
Is there an increasing trend of supply chain attacks? What can developers do to mitigate the impact?
Microsoft either needs to become a better steward of NPM or hand it off to a foundation that can properly maintain it.
I had some dependency of a dependency installing crypto miners: it was pretty scary as we have not had this since wordpress. I saw a lot more people having this issue (there is a weird process consuming all my cpu). Like someone here already says: we need an Apache / NPM commons and when packages use anything outside those, big fat alarm bells should chime.
So is there a list of the most popular apps that made use of the infected lotusbail npm package?
Did any other scanner catch this, and when? A detection lag leaderboard would be neat.
as of this writing, the alleged malware/project is still available on npm and GitHub. I'm surprised koi.ai does not mention in their article if they have reported their findings to npm/GitHub.
isolated-vm (https://www.npmjs.com/package/isolated-vm) here we come for increased sandboxing of node bits and pieces? And we are a year after Java took out the security manager that could sandbox jars in separate classloaders - a standout feature since 1995.
Recently audited a software plan created by an AI tool. NPM dependencies as far as the eye can see. I can only imagine the daunting liability concerns if the suggested "engineering" style was actually put forth to be used in production across the wide userbase. That said, the process of the user creating the "draft" codebase gave them a better understanding of scope of work necessary.
I am seriously surprised developers trust NodeJS to this extend and aren't afraid of being sued for inadvertently shipping malware to people.
It's got to be a matter of time, doesn't it, before some software company gets in serious trouble because of that. Or, NPM actually implements some serious stewardship process in place.
Was anyone actually affected by this? Is this package a dependency of some popular package?
I assume the answer is no because this is clearly clickbait AI slop but who knows.
NPM was a mistake.
We created a minefield of abandonware and called it an ecosystem.
Popularity is never a metric for security or quality….Always verify.
Malicious libraries will drive more code to be written by LLMs. Currently, malicious libraries seem to be typically trivial libraries. A WhatsApp API library is just on the edge of something that can be vibe coded, and avoiding getting pwned may be a good enough tipping point to embrace NIH syndrome more and more, which I think would be a net negative for F/OSS
The incentives are aligned with the AI models companies, which benefit from using more tokens to code something from scratch
Security issues will simply move to LLM related security holes
wonder if this is possible with flutter packages or python? im looking to slowly get away from javascript ecosystem.
ive started using Flutter even for web applications as well, works pretty well, still use Astro/React tho for frontend websites so I can't completely get away from it.
Almost need to run each npm package isolated to the extent possible, or something equivalent.
Once again, just having a better supply chain tool, just reviewing the changed packages could mitigate. Maybe hold back some of the dependencies of dependencies would mitigate.
Why aren't more teams putting some tool in-front of their blind-installs from NPM (et al)
JavaScript fanatics will downvote me, but I will say again. JavaScript is meant to be run in an untrusted environment (think browser), and running it in any form of trusted environment increases the risk drastically [1]
The language is too hard to do a meaningful static analysis. This particular attack is much harder (though not impossible) to execute in Java, Go, or Rust-based packages.
> Traditional security doesn't catch this.
> const backdoorCode = crypto.AES.decrypt( "U2FsdGVkX1+LgFmBqo3Wg0zTlHXoebkTRtjmU0cq9Fs=", "ERROR_FILE" ).toString(crypto.enc.Utf8);
Really? Isn't random garbage string pretty strong indication of someone doing something suspicious?
Just to talk about a different direction here for a second:
Something that I find to be a frustrating side effect of malware issues like this is that it seems to result in well-intentioned security teams locking down the data in apps.
The justification is quite plausible -- in this case WhatsApp messages were being stolen! But the thing is... that if this isn't what they steal they'll steal something else.
Meanwhile locking down those apps so the only apps with a certain signature can read from your WhatsApp means that if you want to back up your messages or read them for any legitimate purpose you're now SOL, or reliant on a usually slow, non-automatable UI-only flow.
I'm glad that modern computers are more secure than they have been, but I think that defense in depth by locking down everything and creating more silos is a problem of its own.