How npm Stopped a Malicious Upstream Code Update From Stealing Cryptocurrency

"If you're a cryptocurrency startup, would you face a huge backlash by hacking your own customers to keep their funds safe if you know that a hacker is about to launch an attack and steal their funds?" asks ZDNet: This is exactly what happened yesterday when the Komodo Platform learned about a backdoor in one of its older wallet apps named Agama. Knowing they had little time to act, the Komodo team said it used the same backdoor to extract users' funds from all impacted wallets and move them to a safe location, out of the hacker's reach.

The tactic paid off, and 8 million Komodo coins and 96 bitcoins, worth nearly $13 million, were taken from users' vulnerable accounts before the hacker could get a chance to abuse the backdoor and steal users' funds... While initially, it did not make any sense for a library with a very limited feature-set to contain such an advanced functionality, after investigating the issue, npm staffers realized they were dealing with a supply-chain attack aimed at another app downstream, which was using the now-backdoored library... The npm team said the malicious code would work as intended and collect Agama wallet app seeds and passphrases, and upload the data to a remote server.
These malicious-payload updates are "becoming more and more popular," according to a post on the official npm blog (a point they later emphasized in a press release).

"After being notified by our internal security tooling of this threat we responded by notifying and coordinating with Komodo to protect their users as well as remove the malware from npm."

Javascript and cryptocurrencies

[xack]

The bad ideas keeping getting made up. Javascript's multiple points of failures due to importing megabytes of dependencies from random servers are a disaster. One day we will get a Javascript powered botnet that will be impossible to shut down. I just hope it takes the cryptobubble down with it.

Re:

[K. S. Kyosuke]

I've read that as

One day we will get a Javascript powered boner that will be impossible to shut down

and got terrified. I guess I should get some sleep finally. But I approve of your bubble-bursting idea.

Re:

[ras]

This isn't a bug peculiar to the npm model. Every system that lets randoms upload to a central repository is easy to compromise using this method. It's happened to Python's PyPi and Perl's cspan. Casting further afield the Android play store functions in an exactly the same way - randoms upload to it, and not surprisingly some of those randoms upload malicious apps. They also place malicious apps in the Chrome's store, and the iTunes store, and the Windows store. If you mention using a docker image fro

Re: Is Rust vulnerable in the same way?

[Zero__Kelvin]

The minute you say Linux isn't "technically" more secure than Windows you lose all credibility. The best part is how you go on to point out that Linux distributions have well policed repositories. You want some third party apps for Windows? Better hope you found the right download link!

Re:

[themusicgod1]

The reality is people who are not developers should not be using anything other than the software in Debian stable. This attack is exactly why.

Re: Is Rust vulnerable in the same way?

[Anonymous Coward]

It's happened to Python's PyPi and Perl's cspan.

Perl has a module for handling government proceedings? Is it available on cpan?

Re:

[ras]

:)

Re:

[Anonymous Coward]

Javascript is bad enough by itself, but the real cesspool is nodejs/npm. So help me, the nodejs.org website directs users wanting to install the two on Debian or Ubuntu to a page of instructions that include sourcing a script directly from a website into a root shell! [github.com] (Hint: typing 'sudo bash' instead of just 'bash' does not magically make you safe.)
Then, if you get past that root-level opening for exploits, you've made it to npm-land, where there are thousands of packages, all from different sources and u

Re:

[znrt]

how is sourcing a rempote script different from downloading and running any other instalation script or executable, security wise?

this is a very convenient and streamlined installation method, there's nothing wrong with it and nothing prevents you from inspecting the script before use ... as you surely always do with all installation scripts, right? :D

Re:

[Anonymous Coward]

Yes, I do. Others do.

People just don't "get" it. Mostly, people like yourself, and you are very, very much not alone. It's like you can't see, and you're surrounded by others just like you..

People mock debian. "Old stuff", they laugh. "Outdated".

That's what something called SECURITY and STABILITY requires. Because what debian does? Is vet packages, is catch issues with installs, is ensure that packages are OSS friendly, and ensures that "many eyes" are on each update.

Is it perfect? HELL NO! But so

Re:

[znrt]

no, i'm the guy who asked you to back your nonsensical statement about instalations using curl.

and you're the guy who didn't back that nonsensical statement but went on a wild rant against 'people', then fantazising about the type of guy i am.

Re:

[ArchieBunker]

How about gnome desktop using javascript plugins? Sounds like a recipe for disaster.

The Lesson

[duke_cheetah2003]

Cryptocurrency aside for a moment, let us take a look at the lesson we should be learning: Do not use turnkey web apps from untrusted sources. Period. I would personally go as far as don't use turnkey ANYTHING from ANY source. But, that's somewhat extreme.

If you don't know how to roll your own apps and services for an internet connected server, please, just stop right there. Don't download pre-made packages and/or canned software and services. You just don't know what you're getting. Learn how to do

Re:

[account_deleted]

Comment removed based on user account deletion

How NPM is easily hackable

[phantomfive]

Node/NPM is a nice user interface but the problems are multitude. Besides the security problems mentioned here, the major one is the complete lack of stability. Then the massive bloat and you start wishing you were back in Java/Maven land so you could get stuff done in an OK environment.

Debian packaging and chain of trust

[lkcl]

When will people realise that there are very very good reasons why Debian's packaging is as it is. We hear of stupid complaints that debian does not keep up to date, by eg arch users, and then an arch developer drops their github account, a malicious hacker re-register it, recreates the packages and inserts malware that is automatically picked up by arch packaging.

Debian has an extremely comprehensive chain of trust that starts with keysigning parties. Debian developers are REQUIRED to show valid ID (passport) before GPG signing is exhanged. Anyone trying to compromise that when there are so many people involved is just plain stupid.

The keys and the ring of signatures are uploaded as a debian package (this is recursive, see below, note that the sigs are treated *as* a debian package)

Then the built package is GPG signed by the developer - bear in mind that this is the same developer that has had multiple people confirm their real identity.

The developer then "uploads" the package to FTP Masters. *After* the developer GPG Key is checked, it is then GPG signed by the FTP Masters, indirectly as below:

The FTP Masters scripts create a "Release" file. This file contains the SHA256 checksums of every single package in the "Release", and is ITSELF GPG signed. Note that the FTP Masters are themselves in the exact same GPG Keyring.

Note that the debian keyring package goes through *exactly* the same process.

Note that there is absolutely no hard dependency on networking, here. The upload and download could actually be done by couriering, USB sticks or carrier pigeons.

Thus, DVD or USB stick releases are just as safe as downloads, because the checkpoint is the GPG signatures *NOT HTTPS OR SSL*.

This fundamentally is failed to be comprehended by pretty much every n00b in cryptography, and sadly, such n00bs blithely go ahead and develop things like

* Mozilla B2G package distribution (which relied exclusively on HTTPS, immediately making the servers a hot hacking target as well as being a major bottleneck. I did warn them. They did not listen)
* archlinux pacman, which has GPG signing on the package releases but not the actual packages themselves. This was how a malware package was uploaded to arch binary distribution
* and we have npm. I'm not even going to look at how it works. They almost certainly assume that because it's HTTPS it's secure.

Debian is basically one of the very few uncompromiseable distros available, not just because of the correct use of GPG and its procedures, it's a succesful *distributed* use of GPG that has no central control authority. Ubuntu by contrast may be compromised, despite being based on debian, because it has fewer developers and they are paid to do what they are told.

Some debian developers take protecting their GPG keys to an extreme. They don't just disconnect the machine from a network when doing GPG signing, they have the GPG key on a USB stick that is locked in a safe, and the machine it gets plugged into has NEVER been connected to the internet. Files to be GPG Signed are copied to and from USB sticks that are plugged into the disconnected machine.

And people complain about debian, not having a single clue the extent to which the developers - all unpaid - go to give you a properly secured uncompromiseable distro.

Re:

[lkcl]

And despite all of that effort, Debian was still infected by systemd, rendering Debian completely unusable for anything serious.

Debian switching to systemd was the best thing to ever happen to FreeBSD.

i use angband.pl's "nosystemd" packages, they work well. however, i often have to recompile some packages from source, which can get quite hair-raising, as kilobyte has created the nosystemd packages for a server environment, and i run a desktop one (fvwm2, started from .xinitrc, with "startx")

you may be interested to know that the triple-layer vote on which init system to use had systemd DEAD LAST, under all cascading-votes. sadly, the historic and very dangerous precedent was set to IGNORE the expressed

npm?

[JustAnotherOldGuy]

For those of you like me who didn't instantly recognize what "npm" is or was, Wikipedia says:

"npm is a package manager for the JavaScript programming language. It is the default package manager for the JavaScript runtime environment Node.js. It consists of a command line client, also called npm, and an online database of public and paid-for private packages, called the npm registry."

Npm didn't prevent anything?

[DCFusor]

As it said in the story, it was Komodo who used the backdoor itself to save their customer's cryptos...then npm pulled it down. As far as I can tell, NPM didn't even know till someone told them - after the fact, much less prevent anything.

Re:

[h33t l4x0r]

The someone that told them was their own software, but yeah. It doesn't seem like such a big deal to be able to detect libs that dial home.

This can't be legal

[iceco2]

Imagine if this was your physical home. The manufacturer of your door lock discovers an imminent plot to burglarize your home.
Are they justified in breaking in and stealing all your Jewlery preemptively? I would hope not.
They should try to notify the home owner and the police, and hope they can react in time.
They obviously meant well, it is even likely the results are favorable (though we never know what might have been). But I'm not sure a utilitarian view is valid.
Where are all the lawyers on this?
This al

Those who don't understand package managers

[TeknoHog]

are condemned to reimplement them, poorly. Besides npm, I'm thinking of projects like hunter2 (or maybe it was just hunter, somehow I mix up the two).