While perusing StackOverflow's 2023 Developer Survey (yes, we developers have our own version of celebrity gossip), I couldn’t help but notice that our trusty VSCode is still riding high as the undisputed IDE champ. With a whopping 73% of the developer vote, it’s safe to say that VSCode has firmly planted its flag. But, like any superstar, it’s not immune to the spotlight’s glare, especially when it comes to security. And in this blog, we’ll explore the security aspects that every VSCode user should consider.

StackOverflow’s 2023 Developer Survey for IDEs

When discussing the software supply chain, the initial focus should be on securing the developer. By “developer,” I’m referring to more than just ensuring secure code training or phishing awareness; it also encompasses safeguarding the development environment. This includes aspects like IDE security, OS security, and more.

In this blog, we are going to talk about one of the aspect of the developer security - Integrated Developement Environment aka IDE (VSCode).

Our exploration of VSCode security will revolve around three critical components:

  • Extensions
  • Workspace
  • Publicly Known Vulnerabilities (CVEs) in VSCode

Let’s dive into each one of them one by one!

Extensions

Before delving into technical details, let’s first assess the security implications of malicious extensions by examining some real-world incidents.

Extensions Vulnerability Reseach Blog

This research conducted by the Snyk team highlights numerous vulnerabilities in these extensions that can provide attackers with access to the environment. Some of the mentioned examples are -

  • LaTeX Workshop (~ 2,500,000 installs) - Vulnerable to command injection due to unsanitized input from the WebSocket client flowing to the openExternal VS Code API method.
  • Open In Default Browser (~ 990,000 installs) - Vulnerable to path traversal which allowed a malicious actor to steal sensitive files from the victim’s machine.
  • Rainbow Fart (~ 130,000 installs) - Vulnerable to zip slip vulnerability which allows a malicious actor to overwrite arbitrary files on a victim’s machine.

In addition to these, there are also malicious-by-design extensions which when installed can compromise the development environment.

Malicious Extensions Reseach Blog

This CheckPoint research report examines the presence of malicious extensions in the Visual Studio Code marketplace, including:

  • Theme Darcula Dark - Disguised as a tool to enhance Dracula color consistency in VS Code, this extension secretly collected vital developer system data: hostname, OS, CPU platform, memory, and CPU specifics.
  • python-vscode - Initially presented as a Python extension for VSCode, a closer examination of its code revealed its true nature as a C# shell injector capable of executing code or commands on the victim’s machine.
  • Prettiest Java - Under the guise of imitating ‘prettier-java’ it covertly stole saved credentials and authentication tokens from Discord, Discord Canary, Google Chrome, Opera, Brave Browser, and Yandex Browser, then sent them to the attackers via a Discord webhook.

The problem in the aforementioned cases arises from a tactic known as “typo-squatting,” which involves adopting a name similar to that of the original extension to deceive users through impersonation.

VSCode also allows attackers to verify any extension that they upload on the marketplace.

However, in the Marketplace the verified blue check mark merely means that whoever the publisher is has proven the ownership of a domain. That means any domain. In reality, a publisher could buy any domain and register it to get that verified check mark.

For in-depth insights, refer to research on VSCode extensions masquerading by AquaSecurity - Can you trust your VSCode Extensions?

These findings underscore the need for vigilance when it comes to extension security within the VSCode ecosystem.

The magnitude of these concerns became evident through the investigation detailed in VSCode Token Security.

Cycode Secret Token Research

and this was not fixed by Microsoft, stating -

“This scenario relies on a user to download a malicious extension which would compromise their machine prior to performing the described attack. Extensions execute on the user machine under the same privileges as the software program itself and there is no sandboxing for extensions. To help keep customers safe and protected, we scan extensions for viruses and malware before they are uploaded to the Marketplace, and we check that an extension has a Marketplace certificate and verifiable signature prior to being installed. To help make informed decisions, we recommend consumers use extensions from publishers they trust and review information such as domain verification, ratings, and feedback to prevent unwanted downloads.” – a Microsoft spokesperson

Workspace Security

Have you ever seen this pop-up when using VSCode? VSCode Workspace Popup and have you ever just clicked on “Yes, I trust the authors” without any consideration? Yes, I am also guilty of this.

Let’s see what harm it can do.

VSCode Workspace Settings

If we are trusting the author of the code, we are allow them to do basically execute code on our machine. This code execution can be done by

  • Tasks - Tasks in VS Code can execute scripts and tools, and their definitions reside in the workspace’s .vscode folder, making them part of the repository’s code. This exposes users to potential risks, as malicious tasks could be executed unknowingly by those cloning the repository.
  • Debugging - Similar to executing a VS Code task, debug extensions have the capability to run debugger binaries when initiating a debug session. This vulnerability could potentially be exploited by attackers to compromise a developer’s machine and gain extensive access.
  • Workspace Settings - Workspace settings in the .vscode folder are shared with repository clones, and some settings contain executable paths. If an attacker manipulates these paths, they can compromise a developer’s machine. The Workspace Trust editor provides a link to review settings not in effect, accessible through the “@tag:requireTrustedWorkspace” tag.
  • Extentions - Certain extensions come with settings that, if manipulated to run unexpected executables, can be exploited for malicious activities. If an attacker gains access to these extensions or can alter their configurations, they have the potential to compromise a developer’s machine.

To safeguard your machine against compromise, it’s crucial to conduct thorough audits of your code and the associated IDE configurations. If there are trust issues, consider operating in Restricted Mode.

Publicly Known Vulnerabilities (CVEs)

Last but not the least, the problem that every software dread are zero-days or CVEs and VSCode is also not susceptible from it.

In the past, there are several CVEs that are found in VSCode, which can also be used by the attacker to attack the weakest link of the supply chain.

CVEs in VSCode

The easiest way to protect yourself from this problem, is to keep the software up-to-date.

In closing, it’s undeniable that security in the realm of software development, especially within the VSCode environment, is an ever-evolving challenge. We’ve explored the risks posed by malicious extensions, the importance of scrutinizing workspace settings, and the potential impact of inadvertently running tasks and debuggers in Restricted Mode. With the constant threat of zero-day vulnerabilities and CVEs lurking, vigilance and proactive measures are essential. By staying informed, practicing safe extension usage, and embracing Workspace Trust, developers can significantly enhance the security of their VSCode environments. It’s a continuous journey, but one that ensures that our coding experiences remain efficient, productive, and, above all, secure.

Please don’t hesitate to contact me @0xCardinal, if you’d like to delve deeper into any of these topics or engage in practical discussions.

Reference