Lotusbail npm package found to be harvesting WhatsApp messages and contacts

Posted by sohkamyung 12 hours ago

Lotusbail npm package found to be harvesting WhatsApp messages and contacts(www.koi.ai)

278 points | 169 commentspage 3

jameslk 10 hours ago||

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

Kwpolska 3 hours ago|

The library in question is a malicious fork of a library which reverse engineered the undocumented WhatsApp Web API. Good luck making a slop generator reverse engineer an API.

jameslk 2 hours ago||

I would wager LLMs in a good enough tool/eval loop would actually do pretty well at that task. But they may also be pretty good at just replicating existing libraries wholesale, sans the malicious bits

runningmike 11 hours ago||

Popularity is never a metric for security or quality….Always verify.

criddell 11 hours ago||

Verify? Verify what?

user34283 11 hours ago|||

Verify what? I certainly don't have the capacity to thoroughly review my every dependency's source code in order to detect potentially hidden malware.

In this case more realistic advice would probably be to either rely on a more popular package to benefit from swarm intelligence, or creating your own implementation.

bdangubic 11 hours ago||

also scrutinize every dependency you introduce. I have seen sooooo many dependencies over the years where a library was brought in for one or two things which you can write yourself in 5 minutes (e.g. commons-lang to use null-safe string compare or contains only)

notKilgoreTrout 11 hours ago|||

Sure but you basically need a different ecosystem to bring in a popular package and not expect to end up with these trivial libraries indirectly through some of the dependencies.

user34283 11 hours ago|||

Said scrutinizing from my side consists of checking the number of downloads and age of the package, maybe at best a quick look at the GitHub.

Yes, I'm sure many dependencies aren't very necessary. However, in many projects I worked on (corporate) which were on the older Webpack/Babel/Jest stack, you can expect node_modules at over 1 GB. There this ship has sailed long ago.

But on the upside, most of those packages should be fairly popular. With pnpm's dependency cooldown and whitelisting of postinstall scripts, you are probably good.

k8sToGo 11 hours ago|||

But... GitHub stars!

sneak 11 hours ago||

Over a certain popularity it is. 56k downloads is nowhere near the threshold.

agentifysh 11 hours ago||

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.

paularmstrong 11 hours ago||

The code is literally right there for you. It doesn't matter what ecosystem or package manager. Someone could distribute the same thing anywhere — it's up to those pulling it in to actually start auditing what they're accepting.

The_President 11 hours ago|||

PyPI has had compromised or fake packages in the past.

johnny22 11 hours ago||

yes it is possible with rust, python, php, and likely many others

j45 7 hours ago||

Almost need to run each npm package isolated to the extent possible, or something equivalent.

edoceo 11 hours ago|

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)

More comments...