7 ms·

Where is all the Node.js malware?

57 points by reedlaw 13y ago

seppo0010 13y ago
Is there any difference with Python and PIP, or Ruby and gems?
- cnp 13y ago
  Yes, there is a difference: there's been a ton of malware released on both.
  - rmoriz 13y ago
    Can you name some? I'm only aware of the single rubygem.org-issue…
- pudquick 13y ago
  Python does have a relatively easy to find page regarding reporting security issues: https://pypi.python.org/security https://pypi.python.org/security I was not (easily) able to find something similar for ruby gems.
gizmo686 13y ago
Isn't this the case with any package management system. In most linux distributions it is common to be able to do (the equivelent of) "apt-get install X" just to try out X. Almost every programing language I've used had its own package manager that installs things just as simply.
- stormbrew 13y ago
  Apt is probably a bad example here, as there's a fairly large amount of key verification involved in it. If you're installing from the main package repository you're pretty safe. PPAs you at least know what you're getting and that someone hasn't hijacked it. It's the dynamic language and other ones that run untrusted code to verify or install things that you have to be worried about.
  - ricardobeat 13y ago
    npm uses https by default. The risk is the same, a package you get from apt-get can later install malicious code on it's own.
    - pyre 13y ago
      | npm uses https by default SSL just protects against man-in-the-middle attacks. | a package you get from apt-get can later | install malicious code on it's own. The package that you install using apt-get is signed, using public key cryptography. Those keys would have to be compromised for someone to upload a malicious package. As for installed software installing malicious code, that's something that a user can do manually too. Installed software could be compromised as well.
      - ricardobeat 13y ago
        Or the publisher's machine has been compromised. Or maybe he accepted a malicious patch. I don't see any difference here.
        nknighthb 13y ago
        Or maybe he's been infected by a mind-control slug. Why don't we just dispense with all security since it's always possible someone might do something stupid?
        bradleyland 13y ago
        I think you're missing the point. Security is achieved through layers of protection that an attacker must defeat in order to take a malicious action. The technologies being discussed here solve different problems: SSL - Validates that you are actually connecting to the server represented by the URL and that no one is listening/inserting information in between. Author signed packages - Validates that the package contains only what the author has released. Yes, it's possible for both to be compromised with enough work, but that's the point: "with enough work". We can't prevent attacks 100%, but we can layer up security so that an attacker's chances of finding a usable exploit approach zero when looking at the full chain.
jjtheblunt 13y ago
A contagious organism needs an adequate density of susceptible hosts to survive, or a long incubation period to wait for opportunity to strike and infect a new host, effectively allowing it to perceive adequate density of hosts. Perhaps "nodejs" is not adequately prevalent, perhaps malware for it is very clever, perhaps both?
- brazzy 13y ago
  This is not about self-propagating viruses or worms, but about trojan horses in the original sense - seemingly useful but harmless modules that secretly open a backdoor to your server.
imissmyjuno 13y ago
Why not read the source of whatever you're using before running it?
- gingerlime 13y ago
  laziness? :) more seriously: 1. Reading the full source code can be quite difficult and time consuming, and being able to spot security issues is even harder. Some experts miss those until someone stumbles upon it, or is dedicated enough to look deeper... 2. there's an underlying assumption that if something is open-source, then the 'many eyes principle' applies, and someone has looked at the code. So whilst it's generally true, it might not always apply to security. Many might have looked at the code, but unless they were specifically looking for security, and were qualified enough to find the more subtle, hidden security issues - those will go unnoticed. The general rule of thumb to look for stability indicators, applies to security to a large extent: activity on the project, number of 'stars' on github, reputation of the core committers etc. But even then there's no guarantee. If you want to stand on shoulders of giants, you'd have to trust those giants to support you.
- roryokane 13y ago
  Because almost all plugins will have too much code to read carefully in a reasonable amount of time. Malicious behavior such as uploading the contents of files at certain paths might take only three lines of code, and those lines could be spread out at different points in a long function, and have misleading variable names. It would take a prohibitive amount of time for a developer who just wants to use a plugin to spot such errors.
- louischatriot 13y ago
  It would take too much time to do it yourself, and if you're no security expert you will miss vulnerabilities anyway. This project is a better answer: http://nodesecurity.io/ http://nodesecurity.io/
- damon_c 13y ago
  I was recently astounded by the sheer number of dependencies and attendant files that get downloaded when starting up a new node.js project. The notion of reading all the source is... quaint!
cobookman 13y ago
I'd wager it primarily is due to market share. Why infect .001% of the Node.js community when you could infect .0001% of the PHP community. Given that its a newer language, its likely that node.js users are more technically skilled. Few people learn node.js as their first language. In PHP for instance, we've all seen code online from novices with horrible SQL injections (...a $_GET or $_POST directly in the query). Node.js has a lot less legacy code. (E.g. Linux has 1000s of exploits over the years, if left unpatched you're in for a bad day).
stormbrew 13y ago
> By necessity, you are also also giving it access to your domain certificates and private keys. By necessity? I'd argue the opposite, by necessity don't do this at all or ever. Is this person terminating SSL at their node app? Because for anything but a toy that's probably a bad idea.
prezjordan 13y ago
It happened once (by accident) on the popular "n" package. https://github.com/visionmedia/n/issues/86 https://github.com/visionmedia/n/issues/86
- reedlaw 13y ago
  This is the kind of thing I'm more concerned about. npm is configured by default to require sudo/root to install globally. I would rather install as a regular user, like Go packages.
  - seppo0010 13y ago
    Isn't npm default ./node_modules? $ npm install socket.io socket.io@0.9.14 node_modules/socket.io ├── base64id@0.1.0 ├── policyfile@0.0.4 ├── redis@0.7.3 └── socket.io-client@0.9.11 (xmlhttprequest@1.4.2, uglify-js@1.2.5, active-x-obfuscator@0.0.1, ws@0.4.25) $ ls node_modules
    - pork 13y ago
      Yes, npm installs to a node_modules/ subdirectory. GP is off the mark. It's possible that people mistakenly use sudo with npm because the syntax is reminiscent of apt. This is absolutely not necessary.
      - reedlaw 13y ago
        As of version 0.3, it is recommended to run npm as root. This allows npm to change the user identifier to the nobody user prior to running any package build or test commands. [1] npm modules that are used from the command line are often installed with the -g, or global switch so they can be used anywhere. Yeoman [2], for example, is installed to /usr/lib/node_modules/yo/bin/yo and owned by nobody:users on my system. While it's reassuring that these files are chowned to nobody, I confess I don't understand npm enough to tell if running it as sudo will not give modules root access in other ways to my machine. 1. https://npmjs.org/doc/README.html https://npmjs.org/doc/README.html 2. http://yeoman.io/ http://yeoman.io/
lancestout 13y ago
This is actually goes to the point behind the http://nodesecurity.io http://nodesecurity.io initiative - building up the security mindedness of the node community by auditing npm modules for various vulnerabilities and making it easy to responsibly disclose vulnerabilities to module maintainers [1]. We're in the process for the first audit wave (checking for things like child_process.exec), and have already had several modules get patched. IIRC, the npm maintainers have expressed interest at the recent node confs/meetups about incorporating security advisory information into the npm package results, to alert people about potential issues when installing modules. [1] http://blog.liftsecurity.io/post/52010883123/security-md-improved-security-disclosure http://blog.liftsecurity.io/post/52010883123/security-md-imp...
ricardobeat 13y ago
the many eyes theory might not apply as a whole, but when every contribution to a codebase has a small surface area, and goes through a github pull-request, it is thoroughly examined by at least one person, usually a handful in popular modules. It'd be much harder to slip something malicious through.
- curiousdannii 13y ago
  But if a popular package's author is malicious they can add bad code, push a patch release, and most packages depending on it will install it. Pull requests are easy to check. Automatically installed patch releases aren't.
bifrost 13y ago
Malware I don't know, but I know for sure that its trivial to write a DDoS tool with it. I blew my NSP network out of the way with line-rate small packets on a low-end box which made me reconsider my dislike for node :) I wrote something similar for PHP and it was pretty slow which was kinda surprising. C/PY/PL is fairly easy, and I only got multi-Gbps out of C, but in fairness its a lot easier in C...
jacques_chester 13y ago
Where is all the FreeBSD malware?
- jdoss 13y ago
  Screw FreeBSD... where is all of the NetBSD malware???
agilebyte 13y ago
Many (most?) packages are on GitHub. If one is popular with the community, I am less likely to believe it is a malware. http://eirikb.github.io/nipster/ http://eirikb.github.io/nipster/ For now, the ease at which we can build npm modules allows the ecosystem to grow. When it gets popular, we can rethink our approach.
fomojola 13y ago
There are infinitely simpler targets for malware with better returns than writing a package to be used by developers in the hope you'd be able to scoop up random certs and database credentials of limited value. It is POSSIBLE your package would get installed on a server run by an organization with credentials that a malware author would care about: but unlikely, and quite frankly not worth waiting for the day when you can make more money (for example) breaking into CMS servers and distributing browser exploits.
jplyle 13y ago
Hi all, Thanks for all the comments, they are very much appreciated. I'm going to write a follow-up piece soon - if you want to send me feedback directly, please feel free. I tend to agree with the point that NPM isn't a big enough target yet to make writing subtly malicious modules worthwhile. However, I don't think that's particularly reassuring. I also suspect that more people are using SSL/TLS directly from node (and running as root) than you might think. Malware targeted at developers may well become more of a big deal in the future. The issue is generic with most package management systems. What I really wanted to talk about was why malware is an apparent problem in some projects and 'ecosystems' and why it isn't in others. The general consensus when talking to other security researchers is that a decent package management system is vital to security. Much like the Google Play store is a key part of Android security. However, NPM (sadly) doesn't really support that hypothesis, as (when I wrote the piece) it wasn't obvious how to report bad modules. I'd also like to applaud the work that nodesecurity.io is doing - it's a very worthwhile project. Best wishes, John

57 points by reedlaw 13y ago

seppo0010 13y ago

Is there any difference with Python and PIP, or Ruby and gems?

cnp 13y ago
Yes, there is a difference: there's been a ton of malware released on both.
- rmoriz 13y ago
  Can you name some? I'm only aware of the single rubygem.org-issue…
pudquick 13y ago
Python does have a relatively easy to find page regarding reporting security issues: https://pypi.python.org/security https://pypi.python.org/security I was not (easily) able to find something similar for ruby gems.

gizmo686 13y ago

Isn't this the case with any package management system. In most linux distributions it is common to be able to do (the equivelent of) "apt-get install X" just to try out X. Almost every programing language I've used had its own package manager that installs things just as simply.

stormbrew 13y ago
Apt is probably a bad example here, as there's a fairly large amount of key verification involved in it. If you're installing from the main package repository you're pretty safe. PPAs you at least know what you're getting and that someone hasn't hijacked it. It's the dynamic language and other ones that run untrusted code to verify or install things that you have to be worried about.
- ricardobeat 13y ago
  npm uses https by default. The risk is the same, a package you get from apt-get can later install malicious code on it's own.
  - pyre 13y ago
    | npm uses https by default SSL just protects against man-in-the-middle attacks. | a package you get from apt-get can later | install malicious code on it's own. The package that you install using apt-get is signed, using public key cryptography. Those keys would have to be compromised for someone to upload a malicious package. As for installed software installing malicious code, that's something that a user can do manually too. Installed software could be compromised as well.
    - ricardobeat 13y ago
      Or the publisher's machine has been compromised. Or maybe he accepted a malicious patch. I don't see any difference here.
      - nknighthb 13y ago
        Or maybe he's been infected by a mind-control slug. Why don't we just dispense with all security since it's always possible someone might do something stupid?
      - bradleyland 13y ago
        I think you're missing the point. Security is achieved through layers of protection that an attacker must defeat in order to take a malicious action. The technologies being discussed here solve different problems: SSL - Validates that you are actually connecting to the server represented by the URL and that no one is listening/inserting information in between. Author signed packages - Validates that the package contains only what the author has released. Yes, it's possible for both to be compromised with enough work, but that's the point: "with enough work". We can't prevent attacks 100%, but we can layer up security so that an attacker's chances of finding a usable exploit approach zero when looking at the full chain.

jjtheblunt 13y ago

A contagious organism needs an adequate density of susceptible hosts to survive, or a long incubation period to wait for opportunity to strike and infect a new host, effectively allowing it to perceive adequate density of hosts. Perhaps "nodejs" is not adequately prevalent, perhaps malware for it is very clever, perhaps both?

brazzy 13y ago
This is not about self-propagating viruses or worms, but about trojan horses in the original sense - seemingly useful but harmless modules that secretly open a backdoor to your server.

imissmyjuno 13y ago

Why not read the source of whatever you're using before running it?

gingerlime 13y ago
laziness? :) more seriously: 1. Reading the full source code can be quite difficult and time consuming, and being able to spot security issues is even harder. Some experts miss those until someone stumbles upon it, or is dedicated enough to look deeper... 2. there's an underlying assumption that if something is open-source, then the 'many eyes principle' applies, and someone has looked at the code. So whilst it's generally true, it might not always apply to security. Many might have looked at the code, but unless they were specifically looking for security, and were qualified enough to find the more subtle, hidden security issues - those will go unnoticed. The general rule of thumb to look for stability indicators, applies to security to a large extent: activity on the project, number of 'stars' on github, reputation of the core committers etc. But even then there's no guarantee. If you want to stand on shoulders of giants, you'd have to trust those giants to support you.
roryokane 13y ago
Because almost all plugins will have too much code to read carefully in a reasonable amount of time. Malicious behavior such as uploading the contents of files at certain paths might take only three lines of code, and those lines could be spread out at different points in a long function, and have misleading variable names. It would take a prohibitive amount of time for a developer who just wants to use a plugin to spot such errors.
louischatriot 13y ago
It would take too much time to do it yourself, and if you're no security expert you will miss vulnerabilities anyway. This project is a better answer: http://nodesecurity.io/ http://nodesecurity.io/
damon_c 13y ago
I was recently astounded by the sheer number of dependencies and attendant files that get downloaded when starting up a new node.js project. The notion of reading all the source is... quaint!

cobookman 13y ago

I'd wager it primarily is due to market share. Why infect .001% of the Node.js community when you could infect .0001% of the PHP community. Given that its a newer language, its likely that node.js users are more technically skilled. Few people learn node.js as their first language. In PHP for instance, we've all seen code online from novices with horrible SQL injections (...a $_GET or $_POST directly in the query). Node.js has a lot less legacy code. (E.g. Linux has 1000s of exploits over the years, if left unpatched you're in for a bad day).

stormbrew 13y ago

> By necessity, you are also also giving it access to your domain certificates and private keys. By necessity? I'd argue the opposite, by necessity don't do this at all or ever. Is this person terminating SSL at their node app? Because for anything but a toy that's probably a bad idea.

prezjordan 13y ago

It happened once (by accident) on the popular "n" package. https://github.com/visionmedia/n/issues/86 https://github.com/visionmedia/n/issues/86

reedlaw 13y ago
This is the kind of thing I'm more concerned about. npm is configured by default to require sudo/root to install globally. I would rather install as a regular user, like Go packages.
- seppo0010 13y ago
  Isn't npm default ./node_modules? $ npm install socket.io socket.io@0.9.14 node_modules/socket.io ├── base64id@0.1.0 ├── policyfile@0.0.4 ├── redis@0.7.3 └── socket.io-client@0.9.11 (xmlhttprequest@1.4.2, uglify-js@1.2.5, active-x-obfuscator@0.0.1, ws@0.4.25) $ ls node_modules
  - pork 13y ago
    Yes, npm installs to a node_modules/ subdirectory. GP is off the mark. It's possible that people mistakenly use sudo with npm because the syntax is reminiscent of apt. This is absolutely not necessary.
    - reedlaw 13y ago
      As of version 0.3, it is recommended to run npm as root. This allows npm to change the user identifier to the nobody user prior to running any package build or test commands. [1] npm modules that are used from the command line are often installed with the -g, or global switch so they can be used anywhere. Yeoman [2], for example, is installed to /usr/lib/node_modules/yo/bin/yo and owned by nobody:users on my system. While it's reassuring that these files are chowned to nobody, I confess I don't understand npm enough to tell if running it as sudo will not give modules root access in other ways to my machine. 1. https://npmjs.org/doc/README.html https://npmjs.org/doc/README.html 2. http://yeoman.io/ http://yeoman.io/

lancestout 13y ago

This is actually goes to the point behind the http://nodesecurity.io http://nodesecurity.io initiative - building up the security mindedness of the node community by auditing npm modules for various vulnerabilities and making it easy to responsibly disclose vulnerabilities to module maintainers [1]. We're in the process for the first audit wave (checking for things like child_process.exec), and have already had several modules get patched. IIRC, the npm maintainers have expressed interest at the recent node confs/meetups about incorporating security advisory information into the npm package results, to alert people about potential issues when installing modules. [1] http://blog.liftsecurity.io/post/52010883123/security-md-improved-security-disclosure http://blog.liftsecurity.io/post/52010883123/security-md-imp...

ricardobeat 13y ago

the many eyes theory might not apply as a whole, but when every contribution to a codebase has a small surface area, and goes through a github pull-request, it is thoroughly examined by at least one person, usually a handful in popular modules. It'd be much harder to slip something malicious through.

curiousdannii 13y ago
But if a popular package's author is malicious they can add bad code, push a patch release, and most packages depending on it will install it. Pull requests are easy to check. Automatically installed patch releases aren't.

bifrost 13y ago

Malware I don't know, but I know for sure that its trivial to write a DDoS tool with it. I blew my NSP network out of the way with line-rate small packets on a low-end box which made me reconsider my dislike for node :) I wrote something similar for PHP and it was pretty slow which was kinda surprising. C/PY/PL is fairly easy, and I only got multi-Gbps out of C, but in fairness its a lot easier in C...

jacques_chester 13y ago

Where is all the FreeBSD malware?

jdoss 13y ago
Screw FreeBSD... where is all of the NetBSD malware???

agilebyte 13y ago

Many (most?) packages are on GitHub. If one is popular with the community, I am less likely to believe it is a malware. http://eirikb.github.io/nipster/ http://eirikb.github.io/nipster/ For now, the ease at which we can build npm modules allows the ecosystem to grow. When it gets popular, we can rethink our approach.

fomojola 13y ago

There are infinitely simpler targets for malware with better returns than writing a package to be used by developers in the hope you'd be able to scoop up random certs and database credentials of limited value. It is POSSIBLE your package would get installed on a server run by an organization with credentials that a malware author would care about: but unlikely, and quite frankly not worth waiting for the day when you can make more money (for example) breaking into CMS servers and distributing browser exploits.

jplyle 13y ago

Hi all, Thanks for all the comments, they are very much appreciated. I'm going to write a follow-up piece soon - if you want to send me feedback directly, please feel free. I tend to agree with the point that NPM isn't a big enough target yet to make writing subtly malicious modules worthwhile. However, I don't think that's particularly reassuring. I also suspect that more people are using SSL/TLS directly from node (and running as root) than you might think. Malware targeted at developers may well become more of a big deal in the future. The issue is generic with most package management systems. What I really wanted to talk about was why malware is an apparent problem in some projects and 'ecosystems' and why it isn't in others. The general consensus when talking to other security researchers is that a decent package management system is vital to security. Much like the Google Play store is a key part of Android security. However, NPM (sadly) doesn't really support that hypothesis, as (when I wrote the piece) it wasn't obvious how to report bad modules. I'd also like to applaud the work that nodesecurity.io is doing - it's a very worthwhile project. Best wishes, John