Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all. Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find.

In a perfect world, it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope or token that allowed only pull and push to the repo in question; no github.com web session whatsoever. If you want the full GitHub web UI experience, well .... go back to github.com; make github.dev a single-repo service.

I'm assuming that's a) inconvenient for users, b) hard to implement, and c) a historical assumption baked into a lot of the github.dev tooling, though. Ah well.

That's probably one of the fastest responses I've seen from a vendor.

Classic MSRC. It has figured out that researchers will report for free regardless. Why change?

github token got stolen and also cloudflare tokens

guys even if you take security seriously you are going to get hit on a long enough time frame

best thing to do is segregate and control damage

trust no one, nothing, use orbstack, and always operate under the assumption that your token is going to get leaked at some point

it knocked off my entire momentum. fortunately seemed like it was just a spam bot that took my tokens and created bunch of fake spam pages and trying to mine crypto

the biggest feeling is the one of feeling violated

take care fellow travelers

There are probably better sources but I think this video by The Primeagen is a good introduction.

https://www.youtube.com/watch?v=9kxx5xp5nTQ

The author said:

You cannot just use the shortcut trick to install the evil extension directly because of new publisher trust system;

You can bypass this by using local workspace extensions which has no publisher screening, but CSP blocks it;

The solution seems to be that installing a local workspace extension which binds a shortcut of 'install extension without checking publisher'.

So I assume it means:

1. you need two extensions, 1st one is local and only for the keybinding, and 2nd one is the 'real' evil one and it doesn't need to (actually can't, because of CSP) be local anymore?

2. the CSP only prevents the JS in local extension but nothing about its package.json (or the ability to add shortcuts), right?

It's so refreshing to read technical articles that are clearly written by a knowledgeable human and explained perfectly like this. By walking the reader through this with the example screenshots it unfolds and gets more interesting as you continue reading.

It's also strange to realize that these days, most articles are not like this.

Maybe it’s just my preference, but I like having a small setup where I know what is installed and what is running. With VSCode, browser IDEs, extensions, sync, tokens, and random plugins, it gets hard to tell what actually has access to what.

Like, disclose it, wait a week, publish it. That seems, to me, like it would avoid almost all the bad press this is getting, and shows that the researcher DOES care about actual security and not just recognition from MSFT.

Small nitpick, but it's also possible to communicate by changing the location.anchor property (by either the iframe or its parent window.)

Github creds or the computer, can't decide which one is worse.

Very cool.

Someone is going to be blacklisted by Microsoft.