First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.
The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:
1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.
2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about:
"presentation": {
"reveal": "never",
"echo": false,
"focus": false,
"close": true,
"panel": "dedicated",
"showReuseMessage": false}
3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.
Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).
My main hesitation here was that really it's just a false sense of security though. Tasks is just one of the things this enables, and in the core codebase we are unable to determine what exactly it enables as extensions could do all sorts of things. At a certain point, it's really on the user to not dismiss the giant modal security warning that describes the core risk in the first sentence and say they trust things they don't actually trust.
I've also created these follow ups based on this thread:
Oh wow that's the first time I've heard about those tasks. I would never consent to that and that they are enabled by default and shipped in the .vscode folder where most people probably nevereven would have thought about looking for malicious things that's kind of insane.
This malware is a full-featured RAT that uses Telegram for C2 and is only 143 lines of code. It's "RAT-as-a-library" design means that we are already seeing criminals build more complext, customized malware on top of Scopper.
The undelete package lets you recover NPM packages that have been removed and are no longer in the NPM registry. Works for both the tarballs and metadata. I use it for malware research, but you can use it for whatever you want!
I wrote this blog article to address several misconceptions I hear when I talk to engineering or infosec teams. The problem of malicious software packages isn't really well understood, so I thought I would try and tackle some misconceptions head on. I hope you enjoy it!
Thanks! Lots of tooling out there, but not much uptake. I mean, npm itself has better, more secure alternatives, but is still the most popular registry on the planet. Like, wtf?!
Transitive dependencies, yeah, but top-level dependencies that you are installing with npm i or via your manifest file are areas that you do control and can manage.
It's not a smoking gun. It is just one of a number of signals you look for when identifying potentially malicious packages. Other things you look for are number of collaborators, how long it existed, domains it talks to, and artifacts it pulls in.
Also, snyk doesn't scan code that isn't on github, because they are under the impression that all the code in the world is on github, so things like gnome.org, debian salsa or codeberg are completely ignored.
So you won't get reliable data from snyk.
edit: snyk doesn't scan code at all, they rely on unrelated "metrics" to give a rating that is not very useful.
Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.
> The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.
I don't actually think that is a bad thing.
The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.
The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.
First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.
The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:
1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.
2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about: "presentation": { "reveal": "never", "echo": false, "focus": false, "close": true, "panel": "dedicated", "showReuseMessage": false}
3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.
Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).
Just search github and you'll see what I mean: https://github.com/search?q=path%3Atasks.json+vercel.app&ref...
There are dozens and dozens of bad guys using this technique right now. Microsoft needs to step up. End of story.