Mischievous NPM Publications | Hacker News Reader

Mischievous NPM Publications

blog.phylum.io

78 pointsjwalton25 comments

Who would actually use these packages? The README files are empty and the packages don't export anything. I don't see anyone using these by accident.

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

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.

As suggested in the current top comment it could even be you who writes the blog post as well.

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.

The trick is to change the package-lock.

What you do it fork a popular package that the project uses and make some changes.

Then update the package-lock so that it points to your GitHub fork.

This file is normally ignored in PR due to the amount of line changes in there so you can have quite a bit of fun.

We‘ve been writing a tool to check lock files against the registry: https://www.npmjs.com/package/@gitlab/untamper-my-lockfile

For now it only supports yarn, but npm support shouldn’t be too hard.

This is really cool work, glad to see someone tackling this! Can I assume this will get rolled out into gitlab natively?

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)

That or someone wrote them just for this blog post...

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 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)

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.

Reminded me of this https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...

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.

see: https://juejin.cn/post/7133134875426553886

To clarify 996 refers to requiring employees to work 9am to 9pm 6 days a week.

This is super interesting! How'd you stumble on this?

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.

[1] https://github.com/connorjclark/totally-fair-rng

[2] https://github.com/connorjclark/npm-package-repro

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.

1. http://github.com/ossillate-inc/packj flags vulnerable/malicious NPM/PyPI/Rubygems packages.

What’s the chance Phylum created those packages?

the article author does seem overly gleeful about it

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...

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.

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.

this is diabolical.

I feel bad for the poor sods who have to debug the aftermath of this, especially the "only on sundays" one

Reply on news.ycombinator.com