Snyk uncovers supply chain security vulnerabilities in Visual Studio Code extensions

We have been witnessing an ever growing amount of supply chain security incidents in the wild. Everything from open source package managers security flaws being exploited to continuous integration systems being compromised to software artifacts being backdoored. And now, those incidents are starting to extend to the place where developers spend most of their time: their integrated development environment, and specifically the Visual Studio Code IDE.

In this article:

• Intro: A vulnerable Visual Studio Code Extensions Marketplace

• Setting the stage: The impact of vulnerable Visual Studio Code extensions on developers

• Proof of concept exploitation: Attacking Visual Studio Code extensions

• Security research disclosure: Snyk releases Visual Studio Code supply chain security research findings

• What can we do about it? Mitigating VS Code extensions security concerns

Until recently, no security vulnerabilities had been discovered in VS Code extensions, creating a sense of security for millions of developers. But now, Snyk has discovered and disclosed vulnerabilities that pose a real and imminent threat to developers who use these extensions and then interact with a malicious actor. The potential compromise is so significantly severe that a remote code execution on a developer’s machine is possible by simply tricking the developer to click a link.

This new VS Code extensions supply chain security threat has the potential to become a new attack playground, potentially impacting over 2,000,000 developers. Let’s take a deeper look.

A vulnerable VS Code Extensions Marketplace

The VS Code Extension Marketplace features about 25,000 extensions. These are essentially compressed archives of JavaScript code that resemble npm packages, and in fact, even rely on the npm ecosystem as a source of third-party dependencies to help build the extensions.

Similar to the npm registry, the VS Code Extensions Marketplace is an open ecosystem, allowing any developer to sign up and submit their extensions. Once uploaded and confirmed, these extensions are available to developers from the VS Code IDE.

For some of these exploitations to work, they need to be actively used by a developer. A few of these vulnerable extensions that Snyk uncovered are:

• Open in Default Browser-  Over 520,000 downloads. Allows developers to open files in a browser, so they can easily and quickly inspect them (common with HTML files).

• Instant Markdown - Over 120,000 downloads. Enables developers to parse the markdown syntax of a file and then renders it as an HTML representation to open in a web browser. Similar to how a markdown file such as a README.md would be represented as a GitHub repository homepage.

Looking at those popular extensions, how many times have any of us installed an extension in our editor, completely unconscious to the fact that we’re letting in code that a stranger wrote? Code that may now have access, or even control of a development environment? How many times have developers potentially been put at risk by just using an extension?

The impact of vulnerable VS Code extensions on developers

At first, it may seem that an extension is merely an extended IDE capability, but their blast radius is significantly more severe than that. A compromised extension on a developer’s laptop means that, at the very least, the attacker had punched a hole through the firewall, and gained access to internal corporate networks. Then, let’s think about the sensitive information developers have access to. Even if an attacker is only able to read files, such as a classic path traversal vulnerability, this means they can harvest secrets, such as gaining access to read the developer’s own environment configuration files or SSH keys, which in turn leads to gaining read and write access to source code repositories.

As you can see, a development environment is quite powerful and often regarded as a trusted entity within a network, and so, compromising developers is a lucrative attack target.

Infact, a similar security vulnerability was impacting the Node.js runtime back in November 2018. The vulnerability, identified as CVE-2018-12120, was putting developers in a potentially dangerous situation due to the debugger port of the runtime listening on all available network interfaces. Imagine the situation where you’re debugging a Node.js or JavaScript application by running node --debug while working from a public and insecure network, such as a coffee shop. This may allow attackers to attach to the debugging interface and run arbitrary JavaScript code on your development environment.

If you think the above example is an edge case scenario, you should know that Rapid7 has weaponized an exploit that specifically targets this vulnerability of Node.js debugger command injection by creating a module for the Metasploit exploitation framework.

Attacking VS Code extensions

Let’s take a deeper dive into one of the vulnerable extensions and see how an attacker can exploit it to their advantage.

In the following demonstration, we are going to exploit a code vulnerability in the Instant Markdown extension. Once you’ve installed it from the Marketplace, you can see what the common use case of previewing markdown files looks like:

The moment that you view a markdown file, like a repository’s README.md, the extension starts a web server listening on localhost and port 8090. You don’t even have to load the extension view pane on VS Code. It just starts automatically in the background.

If you were to open a README.md file in the VS Code editor, and then browse to http://localhost:8090, you’ll see the contents of README.md as an HTML file.

The problem starts with the Instant Markdown extension having a path traversal vulnerability, which means anyone with access to that localhost server is able to request and receive any file on the environment running VS Code, which is essentially the developer’s machine.

For example, if I was using that extension and I have a Snyk logo file in my downloads folder, such as ~/Downloads/snyk-dog.svg and then ran the below curl command on the command line prompt, it would send back the results of this file:

1curl "http://localhost:8090/foo/?/../../../../../Downloads/snyk-dog.svg"

You might be wondering now,  how would someone be able to access a file that is served by a local web server? Well, what if they tricked you into visiting a website? The act of simply opening an attacker-controlled website in your browser is all that they need.

Consider the following flow chart diagram that explains how CORS related issues are bypassed:

The attack vector described above makes use of the path traversal vulnerability, along with server side request forgery, and some nifty JavaScript tricks like forcing a download to the user’s environment, iframe and the browser’s Window.postMessage API to communicate the required data.

Here is a video showing all of that flow in action, in which Kirill Efimov, a Snyk security researcher spawns a web server they control, makes it available over ngrok to simulate an internet-accessible HTTP website, and ends up stealing SSH keys from the developer who uses VS Code and a vulnerable extension:

Snyk releases VS Code supply chain security research findings

This is just one example of how attackers will seek ways to exploit VS Code extensions and this supply chain vector to target developers. In fact, there are other extensions which we found to be vulnerable to similar attack vectors, such as LaTeX Workshop boasting more than 1,200,000 downloads.

By this time of sharing these results with the public, Snyk went through a responsible disclosure process and informed the relevant maintainers of the concerns as pointed out here to coordinate a fix.

I invite you to read more on the technical details of the VS Code supply chain story by Snyk’s security researchers Raul Onitza-Klugman and Kirill Efimov who conducted the research, created the proof of concepts, and collaborated with maintainers of extensions to remedy the situation and keep our ecosystem secure.

Mitigating VS Code extensions security concerns

As a developer who builds these extensions or writes in JavaScript, TypeScript or Java, you can and should be using a tool that helps you find security flaws while you code in your IDE. I’m not talking about a standard linter, but rather Snyk Code — a newly announced static application security testing (SAST) tool that you can use straight from your IDE. You can also run it via the Snyk CLI: $ snyk code test.

Here’s a screenshot of Snyk Code finding this path traversal vulnerability in the Instant Markdown extension for VS Code:

Another way to find all of the security related static analysis code issues across multiple project repositories is by importing your GitHub repositories to Snyk, which will find these potential vulnerabilities. Here it is, the same path traversal vulnerability information as annotated in the Snyk web app:

From the developer’s point of view, as a user of the VS Code IDE software, you should be more concerned and conscious of the extensions you install. Unfortunately, there are currently no tools for vetting extension security  built into the marketplace. However, when it comes to your project’s own open source libraries, whether on npm or otherwise, you can always use Snyk (it’s free!) to find and fix security vulnerabilities in such packages.

Summary

Supply chain security concerns are only going to grow bigger, deeper, and more targeted towards the developer ecosystem. It is our hope that by reading research findings you are made even more aware of the potential security risks and implications.

If you want to see a live demonstration of the Visual Studio Code extensions hack I encourage you to check out this session on June 8th 3PM UTC with Liran Tal, Director of Developer Advocacy at Snyk, and Kirill Efimov, Security Researcher at Snyk:

https://www.youtube.com/watch?v=pkvywMhd30c

Here are more highly recommended similar case studies on the topic:

• Deep dive into Visual Studio Code extension security vulnerabilities

• Zoom remote code execution security vulnerability CVE-2019-13567

• Dependency Confusion and other topics about securing your modern software supply chain

• If you’re a JavaScript or Node.js developer you’d want to take a look at the following 10 npm security best practices guideline.

• Developers as malware distribution vehicles presentation by Guy Podjarny at InfoQ