Looks like the malicious commits were made with a fake user account. No identifying information, barely any repos, generic profile picture.
Backdoor in event-stream library dependency
11–20 of 509 posts
Re: Backdoor in event-stream library dependency
#12Is there a way to get stats on suspicious activity on NPM repos? I feel like this is a service that every node.js project is in need of after left-pad and now this.
You could run NPM Audit (https://docs.npmjs.com/cli/audit)
Re: Backdoor in event-stream library dependency
#13Is there a way to get stats on suspicious activity on NPM repos? I feel like this is a service that every node.js project is in need of after left-pad and now this.
check them into your git
How does that help? You still update from time to time get fixes, new features and then you can get some unwanted code which is not discovered yet.
Re: Backdoor in event-stream library dependency
#14Unpinned dependencies are harmful.
If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems.
Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.
Re: Backdoor in event-stream library dependency
#15I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…
>If the original author has no use for the project anymore and someone offers to take it over from them, why should the author be expected to refuse? Isn't adding another potentially unknown maintainer generally better for the community than a project dying?
Depends on the project, I guess. Open source can always be reanimated.
Re: Backdoor in event-stream library dependency
#16Is there a way to get stats on suspicious activity on NPM repos? I feel like this is a service that every node.js project is in need of after left-pad and now this.
You could run NPM Audit ( https://docs.npmjs.com/cli/audit )
But this wouldn’t catch issues with pushing immediately after being granted access, new github accounts pushing changes to libs with thousands of dependents, libs whose dependencies were yanked from npm. Only published vulnerabilities, right?
Re: Backdoor in event-stream library dependency
#17Also note the same user owns this library: https://github.com/right9ctrl/node-scrypt I would be very suspicious of that as well and audit anything that library has touched.
A funny thing is that on README.md, the `Install from source` section has this: `git clone https://github.com/barrysteyn/node-scrypt.git`.
Re: Backdoor in event-stream library dependency
#18Also note the same user owns this library: https://github.com/right9ctrl/node-scrypt I would be very suspicious of that as well and audit anything that library has touched.
Good eyes, but this looks like it may be a red herring. That is a fork of the `scrypt` package, canonically found here:
https://www.npmjs.com/package/scrypt
With one maintainer, Barry Steyn, whose referenced repo is here:
https://github.com/barrysteyn/node-scrypt
Somebody would have to pick it up from a git URL, I think. (Maybe they could typosquat, but we'd have to find that first.)
Re: Backdoor in event-stream library dependency
#19Re: Backdoor in event-stream library dependency
#20This is one of the reasons npm packages with a compiled minified dist js files are a bad idea, makes hiding malicious code surprisingly easy.