1 yr. ago • 99%

Attackers invite targets to collaborate on a project, convincing them to download and run a repository with malicious npm dependencies.

github.blog Security alert: social engineering campaign targets technology industry employees - The GitHub Blog

GitHub has identified a low-volume social engineering campaign that targets the personal accounts of employees of technology firms. No GitHub or npm systems were compromised in this campaign. We’re publishing this blog post as a warning for our customers to prevent exploitation by this threat actor.

13 comments

Man that’s clever

22
[DO NOT DEVELOP MY APP]

13
- Would you like to develop an app?
  
  3
The really scary thing is probably the malicious npm dependencies. If I think about the projects at work with and all the different packages and the hundreds of dependencies no one knows. And it's probably even worse in really big companies like Microsoft or Facebook, they probably got thousands across their products. I hope for us all that they scan them very regularly.

12
- This is why my work will only use enterprise supported distros like RHEL. We don't have the manpower to stay on top of every single package update to ensure they're absolutely safe.
  
  3
  
  What does RHEL have to do about NPM package dependencies in software projects? A server or a developer’s desktop machine using RHEL would still be pulling the same packages from NPM as another other distro…unless I’m missing something?
  
  4
There goes the argument of non technical users falling for scams. The tables have turned!

I do wonder if this would be negated by containered applications

9
Oo that's a sneaky one, very impressive.

7
Examine dependencies and installation scripts. Very recently published, net-new packages, or scripts or dependencies that make network connections during installation should receive extra scrutiny.

I'm a little surprised npm doesn't already do this and give you a big blinking warning in the install process about it.

5
How do Linux distro's deal with this? I feel like however that's done, I'd like node packages to work in a similar way - "package distro's". You could have rolling-release, long-term service w/security patches, an application and verification process for being included in a distro, etc.

It wouldn't eliminate all problems, of course, but could help with several methods of attack, and also help focus communities and reduce duplication of effort.

1
- Linux distros typically use a key signing party to help shore up their security concerns, but I wonder how github would go about implementing something like that.
  
  1

You've viewed 13 comments.