
Plot to steal cryptocurrency foiled by NPM - soheilpro
https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm
======
MoronInAHurry
NPM foils plot that was only possible due to ridiculous house of cards built
by NPM.

I notice that the NPM blog post also fails to mention that it was actually
_successful_ and resulted in about 1 million KMD (current value ~$1.7M) being
stolen. The Komodo blog post contains that information:
[https://komodoplatform.com/update-agama-
vulnerability/](https://komodoplatform.com/update-agama-vulnerability/)

Even worse, they had also successfully stolen about _9 times more than that_.
The only reason it was prevented was because the seeds were being sent to a
public server, and Komodo was able to access and use them to "steal" the 8
million coins (and 96 BTC) from those wallets before the attacker did.

This was a successful $10M+ theft that NPM is somehow trying to spin into a
positive.

~~~
matthewbauer
I don’t think it’s fair to single npm out here. The truth is any package
manager that lets anyone publish package updates is vulnerable to this type of
attack.

~~~
dtech
npm encourages an auto-upgrading versioning scheme: take version x or higher.

It's great for keeping dependencies up-to-date, but this makes it immensely
vulnerable to the kind of malware injection, as publishing a library version
with payload will immediately propagate throughout the ecosystem.

In most other version managers (e.g. maven) every library and application
specifies a hard-coded version, which requires users to manually upgrade,
giving a window were a malicious version can be detected before it affects
anyone.

~~~
nullandvoid
For a security critical app not locking down the dependencies to audited
versions seems very dangerous indeed and I believe there is some blame to be
had there

~~~
matthewbauer
You’re still vulnerable if you lock down dependencies during the period the
malicious code is wild though. You have to actually audit your locked
dependencies to consider yourself safe.

~~~
undecisive
Isn't that expecting the car to be invented before the wheel?

From what I've seen, quite a few of these have been targetted attacks - the
assailants have targetted specific variables that existed in a specific
codebase that they knew imports their module. Of course, if you've only just
started writing that codebase, your dependencies have no way of knowing where
you're storing private keys (short of somehow scanning the object space for
variable names like "private_key")

But yes, in theory I would love for any *-sensitive code to go through a
thorough audit after every dependency update before a version gets released in
the wild. I'm guessing that next-to-nobody has the resources for that kind of
an effort though.

------
neonate
"The attack was carried out by using a pattern that is becoming more and more
popular; publishing a ‘useful’ package (electron-native-notify) to npm,
waiting until it was in use by the target, and then updating it to include a
malicious payload."

Gary Bernhardt has an interesting comment:
[https://twitter.com/garybernhardt/status/1137459482135416832](https://twitter.com/garybernhardt/status/1137459482135416832)

~~~
jw1224
re: Bernhardt's tweet —

> This is exactly what many of us predicted when NPM introduced a world of
> thousands of separate dependencies per app. The main reactions to that
> skepticism were "stop being so negative" and "don't try to stop progress."

I'm sure "many of us" predicted planes would crash when they first took
flight, but nonetheless the benefits of commercial air travel vastly outweigh
the risks.

npm, having been a huge benefit to developers and the JS ecosystem for many
years, should not have its problems dismissed with an "I told you so"
attitude.

~~~
drngdds
The problems with the JS ecosystem probably could have been solved in a way
that doesn't involve every nontrivial project dynamically downloading
thousands of transitive dependencies by god-knows-who. It's not like package
repositories and dependency management were uncharted waters before npm came
along.

~~~
dboreham
But "this one goes to eleven".

~~~
krapp
You mean it goes to 10.9999999998

------
koolba
Here's a free idea for somebody at NPM or any other third party security
provider: _Tracking changes to network or fs access across versions_

It should be possible to scan JS modules to determine either the fixed set of
dependencies, the fixed set of system dependencies (ex: require('fs')), or
whether it's not determinate (code contains "eval" or otherwise invokes
require(...) with a non-constant). Including a package that has fs or net
access would automatically include that taint as well.

The idea for this is that a malicious package would be more easily noticed as
something like leftpad(...) suddenly requiring net access should be flagged.
It's not a panacea as something malicious that already has fs or net access
could do something new, but it would help add some sanity checks and give a
smaller set of packages and versions to manually review.

I think deno (Node.js creator's new project using Typescript + Golang) has a
similar idea but built in to the individual packages themselves where they
need to explicitly include permissions for fs, net, etc. That'd be a great
idea but getting to that point from the current (and growing) Node.js/NPM
world is going to take a while.

~~~
aasasd
Have a look at JSFuck: [http://www.jsfuck.com](http://www.jsfuck.com)

------
theamk
Does anyone know how this was done? Was it some sort of automatic AI system?
Dedicated people watching update feeds 24/7? Random person noticing github
commit and notifying npm?

~~~
motohagiography
Obvious way to do this would be with some variation of ranking the edit
distance or simple entropy differences, and alerting/prioritizing significant
updates for further scrutiny in another workflow pipeline. Bug fixes are
relatively low distace, where a new module would show up as a bump. It would
FP on code cleanups, but who actually does those. There are more sophisticated
methods than these used in products today, but this is something an amateur
could implement. Compute is huge, but cost/benefit is a product problem.

Some string searches would be easy wins as well, given wallet file names,
detecting new public keys, etc. Can think of a few AV products that would
benefit users by being able to state an app has added an update that resembles
a new module with functionality they might not have signed up for in the
original EULA.

If you are an enterprise customer, I'd ask your AV vendor for it as a feature.
Realistically, the best control is don't put a cryptocurrency wallet on a
device that has automatic updates from untrusted sources.

------
jjn2009
These issues are entirely caused by NPM in the first place. Anyone who starts
a node project ends up with a massive web of unaudited code which can only be
dealt with my moving off NPM and adding packages to your own private repo
after youve audited them yourself. Which is an almost impossible task.

------
progval
I expected the article to explain how they detected it, but it's reduced to
just:

> After being notified by our internal security tooling of this threat

------
GordonS
I posted this a couple of days ago, but I guess at the wrong time of day -
when I saw it got no interest, I thought "I'll bet this is one of those
articles that someone else posts later, that the mods let through"!

This comment is a bit meta, but I actually really like this "second chance"
feature of hacker news. Mods could in theory "boost" such stories by making
them sticky, but I like this kind of hands-off, no-meddling approach :)

~~~
xigency
I received an email from Dan once recommending I repost a Show HN submission I
had made that had no hits. Hacker News is pretty well moderated overall.

------
NetOpWibby
I cannot wait for Entropic[1] to take off so I can just use that (and also
replace my self-hosted Verdaccio with it).

[1] [https://github.com/entropic-dev/entropic](https://github.com/entropic-
dev/entropic)

------
34679
Doesn't add up if you look at the dates they claim the malware was injected
and the dates of the most recent transactions of all the addresses swept. Some
of those addresses hadn't been used in over a year.

------
nwrk
Good write up and great job of NPM security team. Thanks!

------
PunchTornado
if you're dealing with money, you shouldn't install any dependency unless you
run a security check.

you should never update a dependency unless you run a security check.

this isn't npm's fault.

~~~
acdha
I get where you’re coming from, but doesn’t that mean you need at least one
full time security auditor just to keep pace? Node projects seem to pretty
quickly hit hundreds or thousands of dependencies, which means updates happen
most days.

~~~
siriusfeynman
> But doesn’t that mean you need at least one full time security auditor just
> to keep pace

Crazy idea - maybe you shouldn't be writing financial software if you're not
going to audit the code that you're using

