Closed FallingSnow closed 6 years ago
@FallingSnow did you manage to work out what the attack does?
No. I spent a better part of a day trying to get something other than gibberish out of the encrypted AES payload. I've tried executing the gibberish and it errors out.
I believe there are 2 possible reasons I haven't been able to get the actual payload's code.
unpkg link to help other people poke around: https://unpkg.com/flatmap-stream@0.1.1/index.min.js
he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years.
note: I no longer have publish rights to this module on npm.
Please contact npm support and they will take care of the situation.
note: I no longer have publish rights to this module on npm.
npm owner ls event-stream
right9ctrl <right9ctrl@outlook.com>
Transfer publishing rights to the unknown dude, but keep the repo under your username. Well done, mate 👍
@limonte I tried to transfer it to @right9ctrl but github errored because they already had a fork of it at http://github.com/right9ctrl/event-stream
If you guys feel strongly about this, why don't you volunteer to maintain it and contact npm support?
To know if your project is in danger, run:
npm ls event-stream flatmap-stream
The bad actor has publishing rights to event-stream
and flatmap-stream
contains the malicious code (specifically flatmap-stream@0.1.1
, but any future version can't be trusted).
Here is an example result from one of my projects:
[redacted]
└─┬ npm-run-all@4.1.3
└─┬ ps-tree@1.1.0
└─┬ event-stream@3.3.6
└── flatmap-stream@0.1.2
@dominictarr: although I completely disagree with someone else contacting npm support, I contacted npm support myself for now.
You put at risk millions of people, and making something for free, but public, means you are responsible for the package.
Anyway, I don't want to argue about this, I just want the issue to be solved, because this is a popular package.
If you guys feel strongly about this, why don't you volunteer to maintain it and contact npm support?
@dominictarr Apparently, you don't want to take any responsibility for this package. That's fine, it's the free community, do whatever you want. But at least indicate somehow that you're not maintaining this repo anymore, e.g. archive the repo
When you archive a repository, you are letting people know that a project is no longer actively maintained.
There is a huge difference between not maintaining a repo/package, vs giving it away to a hacker (which actually takes more effort than doing nothing), then denying all responsibility to fix it when it affects millions of innocent people.
Probably safe to assume other packages are affected by the same method: Find a package that isn't well maintained + high downloads and simply ask to take control of it.
Now we have to run a background check when someone wants to help? The problem is in the tools.
On the one hand @dominictarr, if you choose not to maintain a package anymore, and don't have a trusted person you can pass the baton on to, I think the sensible, and responsible thing to do is to mark the package as deprecated.
At the same time, I think it's bullshit for so many people to depend on a package with one maintainer, and then try and pin all responsibility on that maintainer, instead of getting involved, with governance, or maintenance of the package.
@rougeth This is really an issue of trust. If you chose to give publishing rights over to a malicious actor, I'm not sure what a tool can do to prevent that.
As an aside has anyone figured out what the injection, was attempting to do? Don't have time to look right now.
Pin your dependencies and bump versions manually after reading changelogs (don't let npm install
auto-bump your dependencies).
Transitive dependencies are a PITA to manage but there's no good alternative [that I'm aware of].
Hi, i use 4.0.x version in one of my project. I can not find the flatmap-stream dependency in the installed node_modules and also in the installed event-stream package.json not contains. Pls can you tell me, my project is in danger?
@XhmikosR Any update from npm support?
I'm willing to maintain this package.
cc @dominictarr
Any update from npm support?
None. Maybe someone else should contact them too.
@devmetal as far as I can tell, if you don't have flatmap-stream@0.1.1
in your dependency tree, you haven't been exposed to this code. You can check for it with npm ls flatmap-stream
.
@shockey and if it's there?
Any update from npm support?
None. Maybe someone else should contact them too.
I've contacted them through Twitter. Hope we get response soon.
@shockey Thank you, its empty so i think the 4.0.x version is not affected. Its possible? I mean, this versions has built top of each other right?:
path/for/my/project
└── (empty)
That was the output
@FallingSnow So the malware is present only in the package version 3.3.6, right? I checked on npmjs package website and it seems that the dependency with flatmap-stream
is present only on 3.3.6
@sorahn if it's there, then you may have executed the (allegedly) malicious code. I have no idea what it does, but since it references the process
object, rotating any credentials you expose through environment variables is a great place to start.
@dominictarr - your work is much too commonly used to give control over to unknown people. By acting like this was fine, you are teaching other attackers to think of you as a productive vulnerability vector.
This is open source 101. Don't give control to strangers.
@devmetal it seems the commit author removed it when bumping the package to 4.x, presumably to ensure future updates to this module don't cause people auto-bumping minor versions to lose the possibile vulnerability.
If you're on 4.x you should be fine but it's best to check your dependency tree as described above. If it is present then it's probably best to migrate to a new package or pin to a known good version of the package (which you should do anyway).
@rougeth - what possible remediation is there for using open source and having ownership, other than making ownership not-transferrable?
i mean i guess i'd like NPM to treat an owner change like a major, but that's not a real security boundary, and very likely could easily be trickily dodged.
@shockey I manually checked the minified source in my node_modules folder and it doesn't appear to contain anything malicious. I also don't think anything running on my dev machine has creds in env variables.
Thanks.
A lot of butthurt people railing on the guy. Maybe he just doesn't care anymore about a dead package he has no intention of maintaining.
Blame yourselves devs, not the author who donated hours and hours of free work for your benefit.
I also just checked the three versions on npm, 0.1.0, 0.1.1, 0.1.2, and none of them have the above code that OP has put. I downloaded the tarballs directly from npm, am I missing something? @FallingSnow where did you find that?
I found it, it's cleverly hidden at the end
Quoting @FallingSnow
I've included a break down of what I have so far on flatmap-stream below. It includes the portion of code not found in the unminified source of flatmap-stream@0.1.1 but found in the minified source. The code has been cleaned up a little to get a better understanding.
If anybody finds malicious code in a package in the future, please also inform the Node.js Security Working Group, not just npm.
This will ensure that the issue is assessed and resolved as fast as possible.
@sergiotapia - this gets different when you actually have companies to maintain, and become legally liable for the safety of your users. it is not that you get it and everyone else doesn't.
gdpr would bankrupt a company caught under this.
So many people who want something for nothing, give Dominic a break. I hand off tons of my modules to people who are willing to maintain them as well, we shouldn't be expected to vet people. OSS authors already spend time providing something for free why should they be required to waste more time, pin and vet your code always if you're concerned about security, there's no way around that.
Yes, you should be expected to vet people if you give them control to code running on my machines.
If you're not willing to vet them, the library should be forked, so that I know I need to vet them.
@StoneCypher then fork it.
This is standard open source policy going back decades in almost every major language for a reason.
You're playing with fire on other peoples' machines. More than one formerly great developer has disappeared because they've caused damage this way by refusing to understand other peoples' needs, as they've realized that the source is not security trustworthy.
@rjhesketh It matters to you, it's not the problem of the original author.
Give that guy a break ffs.
@CKarper - respectfully you seem to be missing the point. A fork happens by the author as an identity change signal. A third party doing so doesn't broadcast anything and is unrelated.
@StoneCypher yeah that's fair, the "inactive" button on GitHub but then you just people complaining that the NPM module name is taken etc. I find it's less of a problem in Go-land where forking is the norm.
Even if the people look legit who knows what their intentions are. If anything NPM promotes this behaviour by having centralized names. I often get requests to use a name for a "stale" package, or to maintain the existing one so the name remains the same.
Do people run important software like banks on implicit trust? I'd sure hope not. I think at the corporate level there's no excuse but to vet and pin all of your code, vulnerabilities are introduced by accident as well, I don't see any way around vetting code that you're actually shipping.
There's projects I've given up on. Even if I'll never work on it again, I'm not going to hand over control to a complete stranger! That's a ridiculous proposition. That's what the Fork button is for.
The buck stops here. Here being defined as the entity choosing this package and using it. You are responsible for what you ship to customers. Vendor your libraries, use git submodules, vet your deps. Its your problem @StoneCypher and co.
@tj - you know, it's actually quite possible to transfer an npm name to a fork
Some of y'all are really quick to forget what this software is licensed under:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND
The buck stops here. Here being defined as the entity choosing this package and using it. You are responsible for what you ship to customers. Vendor your libraries, use git submodules, vet your deps. Its your problem @StoneCypher and co.
Some of y'all are really quick to forget what this software is licensed under:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND
That covers him legally, sure. It doesn't mean he can't be criticised for it.
I see a lot of people whose source no longer seems safe to me
Was going to say it's impossible to properly vet people since somebody that seems trustworthy can suddenly turn out not to be. But then I went to @right9ctrl's profile page and it's a 1yr Chinese blank account with no repos (all forks).
Please stop arguing. Let's focus on understanding what damage the encrypted code is doing. And how we can recover from it.
@FallingSnow I'm trying to look at the decoded payload, if you find something useful please let us know, I'll do the same
EDIT 26/11/2018:
Am I affected?: If you are using anything crypto-currency related, then maybe. As discovered by @maths22, the target seems to have been identified as copay related libraries. It only executes successfully when a matching package is in use (assumed to be copay at this point). If you are using a crypto-currency related library and if you see
flatmap-stream@0.1.1
after runningnpm ls event-stream flatmap-stream
, you are most likely affected. For example:What does it do: Other users have done some good analysis of what these payloads actually do.
What can I do: By this time fixes are being deployed and npm has yanked the malicious version. Ensure that the developer(s) of the package you are using are aware of this post. If you are a developer update your event-stream dependency to
event-stream@3.3.4
. This protects people with cached versions of event-stream.@dominictarr Why was @right9ctrl given access to this repo? He added flatmap-stream which is entirely (1 commit to the repo but has 3 versions, the latest one removes the injection, unmaintained, created 3 months ago) an injection targeting ps-tree. After he adds it at almost the exact same time the injection is added to
flatmap-stream
, he bumps the version and publishes. Literally the second commit (3 days later) after that he removes the injection and bumps a major version so he can clear the repo of havingflatmap-stream
but still have everyone (millions of weekly installs) using 3.x affected.@right9ctrl If you removed flatmap-stream because your realized it was an injection attack why didn't you yank
event-stream@3.3.6
from npm and put a PSA? If you didn't know, why did you choose to use a completely unused/unknown library (0 downloads on npm until you use it)? If I had the exact date from npm in whichflatmap-stream@0.1.1
was published I wouldn't be asking you questions.I've included a break down of what I have so far on
flatmap-stream
below. It includes the portion of code not found in the unminified source offlatmap-stream@0.1.1
but found in the minified source. The code has been cleaned up a little to get a better understanding.The worst part is I still don't even know what this does... The decrypted data n[0] is byte code or something, not regular javascript, or maybe I'm just not handling it correctly.