Microsoft Visual Studio Code flaw lets extensions steal passwords

Microsoft’s Visual Studio Code (VS Code) code editor and development environment contains a flaw that allows malicious extensions to retrieve authentication tokens stored in Windows, Linux, and macOS credential managers.

These tokens are used for integrating with various third-party services and APIs, such as Git, GitHub, and other coding platforms, so stealing them could have significant consequences for a compromised organization’s data security, potentially leading to unauthorized system access, data breaches, etc.

The flaw was discovered by Cycode researchers, who reported it to Microsoft along with a working proof-of-concept (PoC) they developed. Yet, the tech giant decided against fixing the issue, as extensions are not expected to be sandboxed from the rest of the environment.

Stealing secrets with extensions

The security problem discovered by Cycode is caused by a lack of isolation of authentication tokens in VS Code’s ‘Secret Storage,’ an API that allows extensions to store authentication tokens in the operating system.

This is done using Keytar, VS Code’s wrapper for communication with the Windows credential manager (on Windows), keychain (on macOS), or keyring (for Linux).

This means that any extension running in VS Code, even malicious ones, can gain access to the Secret Storage and abuse Keytar to retrieve any stored tokens.

Cycode researcher Alex Ilgayev told BleepingComputer that other than the built-in GitHub and Microsoft authentication, all of the saved credentials from use of third-party extensions.

“Other than the built-in Github/Microsoft authentication, all tokens saved in VSCode come from extensions,” Ilgayev told BleepingComputer.

“They are either defined by official extensions (from Microsoft), such as Git, Azure, Docker/Kubernetes, etc., or by third-party extensions, such as CircleCI, GitLab, AWS.”

Upon discovering the problem, Cycode’s researchers started experimenting by creating a malicious extension to steal tokens for CircleCI, a popular coding platform with VS Code extensions. They did this by modifying CircleCI’s extension to run a command that would expose its secure token and even send it straight to the researcher’s server.

Gradually, they developed a more versatile attack method to extract those secrets without tampering with the target extension’s code.

The key to this process was discovering that any VS Code extension is authorized to access the keychain because it runs from within the application that the operating system has already granted access to the keychain.

Next, the retrieved tokens had to be decrypted, and Cycode found that the algorithm used to encrypt tokens was AES-256-GCM, which is usually safe. However, the key used to encrypt the tokens was derived from the current executable path and the machine ID, making it easy to recreate the key.

The retrieved tokens were decrypted by a custom JS script run in VS Code’s Electron executable, deciphering and printing all passwords of locally installed extensions.

A second flaw discovered by Cycode’s researchers was that the ‘getFullKey’ function retrieves secrets by a given ‘extensionId,’ which is derived from the extension’s name and publisher.

This problem allows anyone to modify these fields and trick VS Code into granting them access to another extension’s secure tokens.

Cycode tested this using a PoC extension that mimicked CircleCI again; however, they noted that replicating any other extension and gaining access to its secrets would be trivial.

Disclosure and (not) fixing

Cycode told BleepingComputer that they disclosed the problem to Microsoft two months ago, even demonstrating their PoC extension and its ability to steal stored extension tokens.

Regardless, Microsoft’s engineers didn’t see this as a security concern and decided to maintain the existing design of VS Code’s secret storage management framework.

BleepingComputer has contacted Microsoft for a comment on the above but has not received a response to our questions.

---

Original Source

---

---