A security researcher has released exploit code for a Visual Studio Code (VS Code) zero-day vulnerability that allows attackers to steal GitHub authentication tokens by tricking users into clicking a link.
Microsoft classifies a software flaw as a zero-day if it is publicly disclosed and/or actively exploited with no official patch currently available.
As researcher Ammar Askar explained in a blog post on Tuesday, this VS Code vulnerability allows attackers to install malicious extensions that steal GitHub OAuth tokens when they are passed to github.dev (a browser-based version of Visual Studio Code used to work on GitHub repositories) by exploiting VS Code’s sandboxed webview message-passing system.
The proof-of-concept exploit he also released on Tuesday abuses this system by running malicious JavaScript inside a webview to simulate keypresses in the main editor and install an extension that extracts the GitHub OAuth token sent to github.dev and queries the GitHub API to enumerate all private repositories the victim can access.
“This functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf,” Askar said. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to.”
While the vulnerability is not yet patched and has not yet been assigned a CVE ID, VS Code users can protect themselves by clearing cookies and local site data for github.dev in their browser by clicking the Settings icon in the URL bar, and then going into Cookies and site data > Manage on-device site data.
This will ensure that they will get a “The extension ‘GitHub Repositories’ wants to sign in using GitHub.” warning when clicking on links attempting to exploit this flaw.
Askar said they notified GitHub one hour before disclosing the bug and noted that they chose immediate public disclosure due to a prior negative experience with Microsoft’s security response process, in which a previously reported VS Code bug was silently fixed without credit or acknowledgment of the security impact.
“That was mostly a courtesy to GitHub, the intent here was full public disclosure. In my past experience reporting github.dev bugs to them, they tell you that it’s out of scope and go report it to MSRC. And as I outlined in the article, I really don’t want to deal with MSRC on VSCode bugs,” he added.
“To summarize the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed ‘the bug I pointed out without any credit. They also marked it as not having any security impact.
“As I mentioned in that post, going forward I would be doing full public disclosure for any security bugs I found in VSCode.”
This follows another stream of zero-days in various Microsoft products disclosed by an anonymous security researcher using the ‘Nightmare Eclipse’ online handle who also expressed his discontent with how the Microsoft Security Response Center (MSRC) handles the disclosure process.
Over the past several months, Nightmare Eclipse disclosed the BlueHammer, RedSun, GreenPlasma, and MiniPlasma privilege escalation zero-day flaws (the first two now being exploited in attacks), YellowKey (a Windows BitLocker zero-day that grants access to protected drives), and UnDefend (another zero-day that can be exploited to block Microsoft Defender definition updates).
Initially, Microsoft reacted to Nightmare Eclipse’s zero-day leaks with threats of legal action, followed by a tweet stating it would work “with law enforcement as appropriate” when “an individual breaks the law and engages in malicious activity causing real harm to our customers.”
BleepingComputer reached out to Microsoft for a comment on the VS Code zero-day flaw disclosed by Askar, but a response was not immediately available.
Automated pentesting tools deliver real value, but they were built to answer one question: can an attacker move through the network? They were not built to test whether your controls block threats, your detection rules fire, or your cloud configs hold.
This guide covers the 6 surfaces you actually need to validate.
