1-Click GitHub Token Stealing via a VSCode Bug

Noumenon72

Thank you for essentially donating the time you spent on this exploit to raise awareness on improving VS Code's security response. You could have just given up on them but you're still trying to help.

zbentley

This is a very good writeup. 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.

fg137

> To those folks, I am sorry, but this is one of the few levers I have to try to influence MSRC and the security posture of VSCode Someone is going to be blacklisted by Microsoft.

NagatoYuzuru

> the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed the bug Classic MSRC. It has figured out that researchers will report for free regardless. Why change?

pier25

The MSRC situation is really unbelievable. There are probably better sources but I think this video by The Primeagen is a good introduction. https://www.youtube.com/watch?v=9kxx5xp5nTQ

october8140

If you like VSCode but don't like Microsoft, try Zed (zed.dev).

thrdbndndn

Very good write up but I lost it a little at the end. Could someone clarify for me? 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?

zuzululu

I had this happen to me recently 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

antimony51

> if you had some other XSS in a webview that you can get a victim to open, you get effectively full RCE on their computer. Github creds or the computer, can't decide which one is worse.