I think the next step is creating a PR to another, higher profile package introducing a problematic dependency among other changes. It existing on its own doesn't prove intention of doing that, but it enables it. If I were doing this I'd start by creating an actually useful package and then later change it's behavior, but same principle.
If you were just trying to get people to install it directly you'd go for name collisions / typos / namesquatting in your package name instead.
Actually good point, will talk to the respective PMs next week. Mainly been using it in CI in order to protect our own projects (thus yarn only for now)
I’ll never understand blog posts like these. I feel like I could make an npm package called “lodash-extra-turbo” that does nothing but shell out to call “rm -rf” and someone will write a blog post about how this evil npm package by a scary hacker will wipe your system.
We've seen a handful of individuals just go to PyPi or NPM and search for _something_ loosely related to what they need, and just blindly install it. I got a report yesterday of someone that did this with a Python package; similar setup: loosely related name, no README... guy still ran it.
I think there is small but non-zero chance that someone might do it, and that's enough.
Can easily happen if you were not paying attention when looking for a lodash in npmjs.com, or using the autocomplete on vscode, codesandbox that don't provide more context anyway.
They could also write tutorial or stackoverflow answers linking those packages, it would definitely pass the moderation as the rest of the code would be okay and people copy/paste a lot.
Or maybe they are just assessing what's possible. (or wrote for this article)
They're apparently named after a couple of popular actual npm packages, lodash and tailwindcss. So I guess it's possible some people will try these out as the "simple" version of lodash, or as the version that is meant to work with tailwindcss?
I know exactly where this is from. This has been floating around the Chinese Internet for a bit. The repo is originally at https://github.com/wheatup/evil.js but has been made private since then. A few variants of this was made and uploaded to NPM.
Here's a English translation of the README.md in that specific repo.
> What? The notorious 996 company wants you to hit the road?
>
> Do you want to leave a small "gift" for your project before you go?
>
> Let's sneak this project into yours, and your project will have, but not limited to, the following magical effects:
>
> - When the length of the array is divisible by 7, Array.includes will always return false.
> - When it's Sunday, the result of the Array.map method always loses the last element.
> - There is a 2% chance that the result of Array.filter will lose the last element.
> - setTimeout will always trigger one second slower than expected.
> - 10% of Promise.then will not register on Sundays.
> - JSON.stringify will change uppercase I to lowercase l.
> - The result of Date.getTime() will always be one hour behind.
> - There is a 5% chance that localStorage.getItem will return an empty string.
I went a different route with my "malicious" NPM package. See if you can figure it out [1].
Years ago I played around with the idea of verifying that a npm package is the same code found in the source repo [2]. Because there is often a build step, that requires trying to reproduce the building of any arbitrary package, and flagging when there is any delta between the build output and the code distributed via NPM. In more reasonable package managers, this is true by default given that you provide the source code and the package manager builds it for you ... as opposed to NPM, which just asks for the executable code directly.
This is a great idea! What have been your findings comparing packaged code vs repo code? If you're interested, I'd love to integrate this in Packj tool.
Full disclosure: I'm one of the co-founders of Phylum.
I can absolutely assure you, we have no affiliation with these packages. We end up reporting much more malicious packages than these every single day. We wouldn't risk harming our reputation to publish three dumb packages. Just thought these were interesting in a diabolical sort of way.
Definitely not zero. Security researchers and SSC companies are pretty notorious for self-promotion. I would not be surprised if some of these "detected packages" are from researchers who want attention.
You're not wrong. We (Phylum) have seen and called out a security company for typosquatting a popular package as a means of advertising. It felt gross to impact random devs for marketing...
For the love of God, use verifiable package namespaces already.
With package namespaces, you can call your package anything you like that sounds like you're the real thing - lodash-2, lodash-the-one-and-only, lodash-mccloud-of-the-clan-mccloud, go nuts.
But for as long as you don't control lodash.com, then you can't publish your package under the com.lodash namespace, so it's obvious you're not the actual Lodash team.
Baffles me no end. I have no idea why PyPi and Cargo and probably so many others don't do this either, it removes an entire class of supply chain risk, and also prevents people creating dumb packages just to squat on the "good" package names.
I guess its meant to play a sick joke on some co-workers?
https://www.npmjs.com/package/lodash-simple
https://www.npmjs.com/package/lodash_tailwind