[HN Gopher] Mischievous NPM Publications
___________________________________________________________________
Mischievous NPM Publications
Author : jwalton
Score : 71 points
Date : 2023-05-05 11:53 UTC (11 hours ago)
(HTM) web link (blog.phylum.io)
(TXT) w3m dump (blog.phylum.io)
| moltar wrote:
| What's the chance Phylum created those packages?
| thenerdhead wrote:
| 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.
| louislang wrote:
| 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...
| louislang wrote:
| 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.
| fnord77 wrote:
| the article author does seem overly gleeful about it
| jannes wrote:
| 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
| skrebbel wrote:
| 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.
| dEnigma wrote:
| As suggested in the current top comment it could even be
| _you_ who writes the blog post as well.
| h1fra wrote:
| 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)
| louislang wrote:
| 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.
| arsome wrote:
| That or someone wrote them just for this blog post...
| vasco wrote:
| 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.
| vorticalbox wrote:
| 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.
| leipert wrote:
| 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.
| louislang wrote:
| This is really cool work, glad to see someone tackling
| this! Can I assume this will get rolled out into gitlab
| natively?
| leipert wrote:
| 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)
| yafbum wrote:
| 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?
| llimos wrote:
| Reminded me of this https://thedailywtf.com/articles/Disgruntled-
| Bomb-Java-Editi...
| hoten wrote:
| 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
| ashishbijlani wrote:
| 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.
| gyf304 wrote:
| 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
| fnord77 wrote:
| this is diabolical.
|
| I feel bad for the poor sods who have to debug the aftermath of
| this, especially the "only on sundays" one
___________________________________________________________________
(page generated 2023-05-05 23:01 UTC)