1-Click GitHub Token Stealing via a VSCode Bug
103 points by ammar2 13 hours ago | 14 comments
NagatoYuzuru 53 minutes ago
> the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed the bug
replyClassic MSRC. It has figured out that researchers will report for free regardless. Why change?
natpalmer1776 36 minutes ago
It was the status quo for a long time, then the pesky security researchers started asking for compensation instead of clout.
replyammar2 32 minutes ago
> instead of clout
replyI'm catching up on the infosec twitter side but it seems like it was even worse. A lot of people have the same story as me in 2023 of "they silently patch the bug and don't even credit you" which really stinks.
natpalmer1776 26 minutes ago
It definitely reminds me of the stereotypes of big business types stepping on the little guys to climb the ladder.
replyI hope you get credit where credit is due in future endeavors.
pier25 49 minutes ago
The MSRC situation is really unbelievable.
replyThere are probably better sources but I think this video by The Primeagen is a good introduction.
Noumenon72 2 hours ago
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.
reply
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 actually exactly what they do for codespaces. The token only has read/write on the repo you activated for the codespace [1]. They should definitely consider doing that for github.dev as well.
[1] https://orca.security/resources/blog/hacking-github-codespac...
But then someone else on the team should have to manually approve that MR to allow it to be merged to main.
This kind of defeats the ability of malware to push stuff out automatically.