[HN Gopher] Malware found on NPM infecting local package with re...
___________________________________________________________________
Malware found on NPM infecting local package with reverse shell
Author : gnabgib
Score : 153 points
Date : 2025-03-26 17:53 UTC (5 hours ago)
(HTM) web link (www.reversinglabs.com)
(TXT) w3m dump (www.reversinglabs.com)
| JTbane wrote:
| Back in the day repositories had 'maintainers' who reviewed
| packages before they became included. I guess no one really cares
| in the web dev world; it's a free-for-all.
| CamJN wrote:
| It's not just web dev: go, rust, swift, ruby, python none of
| them do any checking.
|
| In fact the only repo I know of doing any checking is Java's
| Maven/Sonotype and it's automated not manual.
| debugnik wrote:
| OCaml's opam does have a review process, although I'm not
| sure how exhaustive. It's got a proper maintenance team
| checking for package compatibility, updating manifests and
| removing problematic versions.
|
| I don't think this would be viable if the OCaml community
| grew larger though.
| SunlitCat wrote:
| And people bash c/c++ for not having some kind of central
| package management system. Hah!
| carlmr wrote:
| IMO C/C++ is not much better, sure, no central package
| management system, but then people rewrite everything
| because it's too hard to use a dependency. Now if you do
| want to use one of the 1000 rewrites of a library, you'll
| have a lot more checking to do, and integration is still
| painful.
|
| Painless package management is a good thing. Central
| package repositories without any checking isn't. You don't
| have to throw away the good because of the bad.
| lolinder wrote:
| > Painless package management is a good thing. Central
| package repositories without any checking isn't.
|
| There's a reason why these things come hand in hand,
| though. If the package management is so painless that
| everyone is creating packages, then who is going to pay
| for the thoroughly checked central repository? And if you
| can't fund a central repository, how do you get package
| management to be painless?
|
| The balance that most language ecosystems seem to land on
| is painless package management by way of free-for-all.
| bluGill wrote:
| I have that in C++: we wrote our own in house package
| manager. Painless for any package that has passed our
| review, but since it is our manager we have enforced
| rules that you need to pass before you can get a new
| package in thus ensuring it is hard to use something that
| hasn't been through review.
|
| I'm looking at rust, and that it doesn't work well with
| our package manager (and our rules for review) is one of
| the big negatives!
|
| Note, if you want to do the above just use Conan. We
| wrote our package manager before Conan existed, and it
| isn't worth replacing, but it isn't worth maintaining our
| own. What is important is that you can enforce your
| review rules in the package manager not what the package
| manager is.
| JTbane wrote:
| Correct me if I'm wrong but the usual advice in the C/C++
| world is just grab the source code of any libraries you
| want and build them yourself (or use built-in OS libs).
| This is not great if you have a lot of dependencies.
| bqmjjx0kac wrote:
| I'm curious how much review happens in Nix packages. It seems
| like individual packages have maintainers (who are typically
| not the software authors). I wonder how much latitude they
| have to add their own patches, change the source repo's URL,
| or other sneaky things.
| bamboozled wrote:
| Not a lot in most cases. You're still just grabbing a
| package and blindly building whatever source code you get
| from the web. Unless the maintainer is doing their due
| diligence nothing.
|
| Goes the same for almost all packages in all distros
| though.
|
| I'd say most of us have some connection to what we're
| packaging but there are plenty of hastily approved and
| merged "bump to version x" commits happening.
| jowea wrote:
| Nixpkgs package maintainers don't usually have commit
| rights. I assume that if one tried to include some weird
| patch, the reviewer would at least glance at it before
| committing.
| BrenBarn wrote:
| Some alternative sources for other languages do it. Conda-
| forge has a process that involves some amount of human
| vetting. It's true that it doesn't provide much protection
| against some kinds of attacks, but it makes it harder to just
| drop something in and suddenly have a bunch of people using
| it without anyone ever looking at it.
| reaperducer wrote:
| _Back in the day repositories had 'maintainers' who reviewed
| packages before they became included._
|
| Then "walled garden" became a pejorative, and well... here we
| are.
| skeaker wrote:
| Pardon? Maybe my definition of that term is just different
| but that seems wholly unrelated.
| giantg2 wrote:
| Web dev has always been a hot mess.
| cute_boi wrote:
| I think they should start scanning package with the help of AI.
| user432678 wrote:
| "Let's 10x that shit"?
| SunlitCat wrote:
| Nah! Then we would need to add some blockchain and maybe
| sprinkle some other Buzzwords here and there for good
| measurement!
| nottorp wrote:
| The AI scanner must use blockchain validation and of
| course, be written in Rust.
|
| Actually, just rewrite all the packages on npm in rust and
| that will automatically get rid of any security problem.
| love2read wrote:
| The fact that http fetches and fs reads don't prompt the user are
| continually the craziest part of the `npx` and `package.json`'s
| `postinstall`.
|
| Does anyone have a solution to wrap binary execution (or npm
| execution) and require explicit user authorization for network or
| fs calls?
| 2OEH8eoCRo0 wrote:
| Use Rust
| user432678 wrote:
| According to the comment below, it should be "Use Java".
| 2OEH8eoCRo0 wrote:
| My comment was made in jest
| SCdF wrote:
| Definitely stop using jest
| user432678 wrote:
| I bet someone already had entertained an idea to add
| cryptominer to Jest, nobody would notice slight increase
| to those tests running times on CI. Maybe it could even
| start funding those open source maintainers enough to
| finally make ES6 modules non-experimental.
| 0rzech wrote:
| See https://github.com/rust-
| lang/cargo/issues/13897#issue-228884... and
| https://github.com/rust-
| lang/cargo/issues/13897#issuecomment... .
| teknopaul wrote:
| Just package node_modules subdirectories as tar files.
|
| I stopped using npm a while back and push and pull tar files
| instead.
|
| Naturally I get js modules from npm in the first place, but I
| never run code with it after initial install and testing of a
| library for my own use.
| simpaticoder wrote:
| This is a valid choice, but you must accept some serious
| trade-offs. For one thing, anyone wanting to trust _you_ must
| now scrutinize all of your dependencies for modification.
| Anyone wanting to contribute must learn whatever ad hoc
| method you used to fetch and package deps, and never be sure
| of fully reproducing your build.
|
| The _de facto_ compromise is to use package.json for deps,
| but your distributable blob is a docker image, which
| serializes a concrete node_modules. Something similar (and
| perhaps more elegant) is Java 's "fat jar" approach where all
| dependencies are put into a single jar file (and a jar file
| is just a renamed zip so it's much like a tarball).
| jrmann100 wrote:
| I believe the Deno permission system[0] does what you're
| asking, and more.
|
| (Deno is a JavaScript runtime co-created by Ryan Dahl, who
| created Node.js - see his talk "10 Things I Regret About
| Node.js"[1] for more of his motivations in designing it.)
|
| [0] https://docs.deno.com/runtime/fundamentals/security/
|
| [1] https://www.youtube.com/watch?v=M3BM9TB-8yA
| DimmieMan wrote:
| Yes, explicitly asking you if you want to run the install
| script is the first warning (which pnpm can do too)
|
| Then would halt due to file access or network permissions.
|
| Could still get you if you lazily allow all everywhere though
| and this is why you shouldn't do that.
| bilalq wrote:
| pnpm skips all `postInstall` runs by default now. You can
| explicitly allow-list specific ones.
|
| If you use that, I'd highly recommend configuring it to throw
| an error instead of just silently skipping the postInstall
| though: https://github.com/karlhorky/pnpm-tricks#fail-pnpm-
| install-o...
| eastbound wrote:
| npm should run in Docker containers by default. At least to
| restrict access to the project being built.
|
| But the result of a compiler will run on the machine anyway,
| but once again, it should be in a Docker.
| delusional wrote:
| Docker is not a security boundary.
| fc417fc802 wrote:
| Sure it is. It isn't airtight but then what is?
|
| Even KVM escapes have been demonstrated. KVM is not a
| security boundary ... except that in practice it is (a
| quite effective one at that).
|
| Taken to the extreme you end up with something like
| "network connected physical machines aren't a security
| boundary" which is just silly.
| namaria wrote:
| It blows my mind that developers will install things like
| npm, random libraries and so on on their machine, sometimes
| their personal one with the keys to the kingdom so to speak.
| But then again, people are now installing MCP servers the
| same way and letting LLMs run the show. Incredible really.
| delusional wrote:
| You're already including arbitrary code into your application.
| Supposedly you're intending to run that application at some
| point.
| nextts wrote:
| What is the answer to that? Learn x86 and bootstrap?
| davidmurdoch wrote:
| The lavamoat npm package does something similar. It's
| maintained by the security team at MetaMask (crypto wallet
| extension and app). It's used in the extension runtime as well
| as wraps the build process.
| phito wrote:
| Malware in a crypto-related JavaScript package. _Surprised
| Pikachu face_
| tedd4u wrote:
| I think the industry is going to soon look back on building with
| Wild West open-source repos like we looked back on not having
| absolutely everything running on HTTPS in the Snowden era. I know
| Google has "assured" open source repos for Python and Java [1].
| Are there other similar providers for those and other languages?
|
| [1] https://cloud.google.com/assured-open-source-
| software/docs/o...
| theteapot wrote:
| > npm is a package manager for the JavaScript programming
| language maintained by npm, Inc., a subsidiary of GitHub. --
| [1]
|
| and Microsoft own Github so Microsoft is the provider? Pretty
| sure they're running malware scanners over NPM constantly at
| the least. NPM also has (optional) provenance [2] to a Github
| build workflow which is as strong as being "assured" by Google
| IMO. Only problem is it's optional.
|
| [1]: https://en.wikipedia.org/wiki/Npm [2]:
| https://github.blog/security/supply-chain-security/introduci...
| giantg2 wrote:
| Any reasonable company already knows this and sets up a proxy
| repo of scanned/approved versions (this is important for
| licensing too).
| 0cf8612b2e1e wrote:
| How much is that automated scanning worth? Sure, we have
| mirrored repos, but I assume the malware authors pre test
| their code on a suite of detectors in CI. So infected
| packages will happily be mirrored internally for consumption.
| poincaredisk wrote:
| >I assume the malware authors pre test their code on a
| suite of detectors in CI.
|
| Maybe some do, but you give the average malware developer
| way too much credit.
| thibaut_barrere wrote:
| It is worth a fair bit. If you control the mirroring you
| can ensure the malware is flagged but not deleted, so
| forensics can assess how much damage has been done or would
| have been done, for instance.
| giantg2 wrote:
| At least at my company, I think someone at least has to
| approve/verify the scan results. Of course it's still a
| risk, but so are external emails, vendor files, and
| everything else.
| ohgr wrote:
| Bugger all. We had something go straight through.
| delusional wrote:
| Not much. as you say, static scanning is pretty much a dead
| end strategy. Exploiters have long since realized that you
| can just run the scan yourself and jiggle the bytes around
| to evade the signature detection.
| pletnes wrote:
| Not from what I've seen. What are the relevant products in
| this space? Can't expect every random company to set up
| package scanning from scratch.
| tsm wrote:
| I worked for an IBM acquiree 13 years ago and as part of
| the "Blue-washing" process to get our software up to IBM
| spec we had to use their proprietary tools for verifying
| our dependencies were okay.
| chrisweekly wrote:
| JFrog / Artifactory is one very common provider of private
| npm registries. There are a ton of security-scan vendors
| out there (mend/whitesource, socket, black duck...)
| swatcoder wrote:
| You're absolutely right, but you've just asserted that almost
| all companies making software are unreasonable.
|
| Distressingly, doing what you suggest remains the exception
| by orders of magnitude. Very few people have internalized why
| it's necessary and few of those have the political influence
| in their organizations to make it happen.
| BrenBarn wrote:
| So then instead of knowing nothing, we'll know that Google
| wants us to use it, which . . . is a different problem. :-)
| Kaytaro wrote:
| If you include commercial offerings Red Hat has offered this
| for awhile, and many semi-successful startups have tried
| creating a business model solving this.
| donnachangstein wrote:
| > like we looked back on not having absolutely everything
| running on HTTPS in the Snowden era.
|
| Apples and oranges and this is far, far worse.
|
| You can absolutely ship signed, trusted code over standard
| HTTP. Microsoft did this for years and Debian and OpenBSD to
| name a few still do.
|
| HTTPS does not assure provenance of code.
|
| Anyone who doesn't understand this is very misinformed about
| what HTTPS does and doesn't do.
| genewitch wrote:
| I think this depends on one's definition of "code"
| ohgr wrote:
| Based on the staff I see at the average technology company I
| wouldn't expect this to get any better any time soon. The state
| of things is definitely declining.
| the8472 wrote:
| This is a coordination failure. We have ways to distribute the
| source, but not the reviews. Every time someone does any level
| of reviewing that should be publishable too.
| nextts wrote:
| How does https help with the problems Snowden uncovered? You
| don't run on https, https just does in transit encryption
| between 2 points of the service architecture. That is why you
| can (could?) slap cloudflare atop your http only site and get a
| padlock!
| reactordev wrote:
| Because one of the methods reported was scanning http
| packets. Easily read without ssl from any hop in the chain.
| More importantly, he blew the lid off the fact that
| governments had access to this via the very ISP's everyone
| relies on for telecom. By making everything TLS, they can
| look all they want but they can't read it.
|
| You could do tls offloading at your load balancer but then
| you have to secure your entire network starting with your
| isp. For some workloads, this is fine, you aren't dealing
| with super sensitive data. For others, you are violating
| compliance.
| fc417fc802 wrote:
| > Wild West open-source repos
|
| There's a deeper issue though. I frequently have difficult
| getting things to build from source in a network isolated
| environment. That's _after_ I manually wrangle all the
| dependencies (and sub-deps, and sub-sub-deps, and ...).
|
| Even worse is something like emscripten where you are fully
| expected to run `npm install`.
|
| Any build process that depends on network access is
| fundamentally broken as far as I'm concerned.
| no_wizard wrote:
| Which is nearly all of them, except perhaps C/C++, that I can
| think of, in terms of languages broadly adopted
|
| You can cache and/or emulate the network to go offline but
| fundamentally a fresh build in most languages will want to
| hit a network at least by default
| robinsonb5 wrote:
| In my world (VHDL/Verilog and some C/C++) there's a
| difference between the "fetch" and "build" steps. It's
| perfectly reasonable for the fetch step to require network
| access; the build step should not.
|
| The real problem is that some language ecosystems conflate
| those two steps.
| fc417fc802 wrote:
| > at least by default
|
| Even in C/C++ after changing the relevant parameters to
| non-default values things often break. It seems those
| configurations often go untested.
|
| Google managed repos are a nice exception to this. Clearly
| documented commit hashes for all dependencies for a given
| release.
| megadata wrote:
| Could we start a community review pool?
| dingi wrote:
| Why does NPM always seem to have this kind of issues? Why do we
| rarely hear about similar problems with Maven Central, for
| example?
| carlmr wrote:
| Biggest target had biggest number of issues?
| dlachausse wrote:
| I think a lot of it comes down to attack surface. JavaScript
| famously has a very limited standard library, so it is very
| common to pull in massive dependency chains of modules
| containing trivial functionality.
|
| Contrast this to Java, C#, and Python, where you can write
| robust applications with just the standard libraries.
| thewebguyd wrote:
| Yep. See left-pad from from 2016. Something so trivial it was
| basically part of every other major language's standard
| library (and it is now in JS, but wans't at the time).
|
| Other gems exist in the NPM world like is-odd, isarray, and
| is-negative-zero.
|
| The whole ecosystem developed this absurd culture of micro-
| packages that all do something insanely trivial that's built-
| in to pretty much every other language. All of it is a result
| of trying to force the web into doing things it was never
| really designed for or meant to do.
|
| Browsers were never supposed to be full application runtimes,
| and yet we (as an industry) keep doubling down on it
| whstl wrote:
| The culture of micro-packages is mostly pushed by people
| with financial interests.
|
| The modus operandi is to add a semi-useful package to a
| popular project, and then divide said project into other
| sub-projects just to bump the numbers.
|
| Then those individuals start claiming that they have "25
| packages that are foundational to the web infrastructure",
| while in fact it's just a spinner that has 24 dependencies,
| some of those being one-liner packages.
|
| Parallel to that we also have things like Babel, which has
| hundreds of packages, a huge chunk of them being almost
| empty and only triggering flags in the core package.
| yupyupyups wrote:
| >Browsers were never supposed to be full application
| runtimes, and yet we (as an industry) keep doubling down on
| it
|
| Web technologies are multi-platfrorm, widely accessible,
| has an unmatched UI API, has great tooling and a large
| ecosystem. It's the path of least resistance.
|
| Contrast this with something like Qt, which is an absolute
| pain to compile and is riddled with bugs. It's GUI library
| is mature, but nowhere near the web.
|
| Time is money, and developers are many times more expensive
| than the extra cpu cycles the web consumes.
| dgfitz wrote:
| > Contrast this with something like Qt, which is an
| absolute pain to compile and is riddled with bugs.
|
| Compiling qt is a choice, there are many, many ways to
| get precompiled libs. Also, it is only hard to compile if
| you're not familiar with ./configure, it is actually
| absurdly easy to compile and link against qt.
|
| As for the bugs thing, sure, qt has bugs. So does _all
| other software_ and this is a very strange argument to
| make on your end.
| yupyupyups wrote:
| I would say, for serious development you should know how
| to compile the thing. Because some bugs cannot be worked
| around without actually patching the library.
|
| Qt has many dependencies, and it's not always clear which
| libraries are needed for any particular functionality.
|
| Try compiling the documentation and setting up the code
| examples properly in Qt Creator, it's not that easy and
| the instrucrions on how to do that are incomplete.
|
| >As for the bugs thing, sure, qt has bugs. So does _all
| other software_ and this is a very strange argument to
| make on your end.
|
| Most mature software do not expose their bugs early to
| their users. Qt has occationally some really silly bugs
| that pop up across versions that simply shouldn't be
| there if you have proper QA. When they kept away LTS
| updates from non-paying users, this I would argue risked
| becoming a bigger issue.
|
| I don't want to talk bad about Qt, it's actually a really
| awesome library. But it has its quirks that are
| timeconsuming to work around, which can hinder wider
| adoption. That was all I was trying to say.
|
| Note, I would actually recommend it if someone is
| interrested in building native applications with good
| performance, and is comfortable with C++, alternatively I
| would suggest a Python wrapper such as pyside to mitigate
| many of the issues I was talking about.
| marginalia_nu wrote:
| To be fair Java has a pretty large package ecosystem as well,
| including a significant number of dependencies. Though the
| culture is very different, and you generally tend to avoid
| dependencies if possible. The idea of pulling in a package
| for testing whether a number is even or odd is incredibly
| foreign.
| johnny22 wrote:
| not sure about java land, but we have seen this on pypi and i
| think even on rubygems.
| theteapot wrote:
| Put `ignore-scripts=true` in your .npmrc
| gruez wrote:
| that just delays the exploit. The exploit can still run next
| time you import the file.
| theteapot wrote:
| This mostly defends against name squatting and other
| malicious dependencies that never get imported.
|
| Haven't reviewed code but article says its entry point is
| install script. install scripts don't run on import. I guess
| you saying it triggers from import too.
| deanc wrote:
| I'd like to see a world where the JS community focused more on
| improving the stdlib across the browser and in nodejs - much like
| bun is doing. Common packages for node such as mysql2, axios etc.
| are so widely used and are huge attack vectors should they ever
| be compromised.
| DimmieMan wrote:
| Deno is perhaps a better example with browser API's, part off
| the winterTC committee and a growing set of std packages[1].
|
| Possibly more importantly, it has a security model that defends
| against this kind of exploit.
|
| I will agree with the sentiment though, I get not wanting to
| jump on new shiny things but for some reason I keep getting the
| vibe that the community is closer to crab mentality than
| healthy skepticism, downright hostile towards any project
| making a genuine effort to improve things.
|
| [1]https://jsr.io/@std
| geenat wrote:
| Downloads used in infrastructure... VSCode Extensions, Github
| repos, PyPI, NPM, etc. all need to be scrutinized.
|
| Open source at least has the option to audit; closed source (or
| "closed build" stuff like 7zip) is at far higher risk: mostly
| just VirusTotal which mostly will not catch backdoors of this
| type.
|
| Mainland China, Russia, North Korea, use these vectors for
| corporate and government espionage:
| https://www.youtube.com/watch?v=y27B-sKIUHA ...XZ, Swoole are 2
| examples off the top of my head.
| distalx wrote:
| The open-source ecosystem's strength is also its weakness.
| Relying solely on community vigilance isn't cutting it anymore.
| amelius wrote:
| I'm guessing we have to move to a setup where a developer enters
| code while being watched by an AI. Then the AI can give warnings
| if a line of code appears in the repository that wasn't on the
| developer's screen while they were looking.
| delfinom wrote:
| We will need an AI to watch the AI so that the first AI isn't
| working for the bad guy too
| submeta wrote:
| What's the advice? Only develop in a sandbox environment?
| Otherwise chances are our main machines get compromised?
| Joel_Mckay wrote:
| "I'm shocked, shocked... well not that shocked... "
|
| It is the curse of all out-of-band package managers... where
| eventually some lamer shows up to ruin the fun for everybody. =3
| xyst wrote:
| People wonder why I run their shitty apps in VMs and nuke the VM
| afterwards.
|
| This is why, lol.
___________________________________________________________________
(page generated 2025-03-26 23:00 UTC)