3/6 | A Letter to Microsoft: Uncovering Design Flaws of Visual Studio Code Extensions
In the previous blog post, “2/6 | Exposing Malicious Extensions: Shocking Statistics from the VS Code Marketplace” we shared shocking statistics about the Visual Studio Code Marketplace while exposing the world of malicious and risky VSCode extensions.
During our research on the marketplace we found an incredible number of security design flaws implemented by Microsoft that provide amazing ways for threat actors to gain credibility and access. Let’s talk about what those design flaw are, and Microsoft, if you are reading this, consider this a letter to you as for the sake of all the CISOs in publicly traded companies, address these issues outlined in this post ASAP.
So, Microsoft, lets have a chat.
VSCode Extensions Under The Hood
Let’s begin with exploring how extensions work under the hood. The initial biggest security design flaw with VSCode extensions, by far, is the lack of any permission model.
Microsoft has not implemented any sort of permission management or visibility for installed extensions, meaning that any extension can perform any API action. For example, a theme extension that should only change the colors of my IDE, may execute code and read or write files without any visibility or explicit authorization from the user. Amazingly, there has been an open Github feature request from 2018 requesting a permission model and it has yet to be addressed by Microsoft.
Another concerning issue is that extensions by default automatically update quietly to the latest version behind the scenes, this means that anyone can initially publish a legitimate extension, gain traction, and then introduce malicious code, even temporarily for a specific version in order to gain initial access. This has happened many times before in the Chrome Web Store, where threat actors bought legitimate Chrome extensions from individual publishers to later introduce malicious threats. We’ve actually leveraged this method to improve our data collection during our research when we developed an extension to learn the insides of VSCode extensions, read that story in our initial blog post — “How We Hacked Multi-Billion Dollar Companies in 30 Minutes Using a Fake VSCode Extension”
Another design flaw is the lack of restrictions on VSCode extensions, a VSCode extension is practically another app or executable running on the host machine. Unlike similar cases like Chrome Extensions or Gmail Add-ins, VSCode extensions have zero limitations on what they can do on the host. They can spawn child processes, they can execute system calls, they can import any NodeJS package they’d like, making them highly risky. As an extension developer you are not forced to communicate with OS level API in a specific manner, you can execute commands or spawn processes in a variety of different ways, making the ability of VSCode to regulate this behavior impossible. Unfortunately, traditional endpoint security tools (EDRs) do not detect this activity (As we’ve demonstrated examples of RCE for select organizations during the responsible disclosure process), VSCode is built to read lots of files and execute many commands and create child processes, thus EDRs cannot understand if the activity from VSCode is legit developer activity or a malicious extension. There are no bounds, or limited scopes for VSCode extensions, they do what they like, when they like.
Scary stuff.
VSCode Marketplace Controls, Or more precisely, Lack Thereof
Okay, so extensions can do anything on the host, but maybe the Visual Studio Code Marketplace has controls in place to prevent malicious extensions from being installed in the first place. TLDR: They don’t, and it's worse than you think.
Lets begin when creating a publisher account, during our research we found of ~45K publishers registered on the marketplace, only 1,800 of them are verified publishers. Being a verified publisher means getting a shiny blue badge next to your extension’s name. But, and it is a big but, to become a verified publisher (amongst the top 4% of publishers) all you need to do is add a DNS verified domain to your publisher account, meaning anyone that buys a $5 domain can become a verified publisher and instantly gain credibility points. Just look at our experiment extension —
Next, let's talk about the listing page. VSCode takes all the information that is displayed on the marketplace listing page from the package.json file packaged along with the extension code. Most notably, it takes from the Github repository displayed on the listing page. Yes, as you guessed, there is no verification mechanism that you actually own the Github repo, nor is there any sort of verification that the uploaded code is actually code that is on the Github repo. Meaning you can seem like your extension is open source but the actual packaged code may be 100% different. If that is not enough, there are no duplication checks, meaning you can actually copy an open-source extension and list it’s Github as your official Github repository (!).
One of the ways we managed to get traction towards our research extension was that we were trending on the front page of Visual Studio Code Marketplace within a single day of publishing the extension. We are uncertain of how Microsoft chooses the trending extensions, but most of the surfaced extensions by Microsoft have very little downloads, usually less than a 1,000. We also verified that creating a Docker file that installs the extension and then running it in a loop increases the install count of the extension, meaning you can install-bomb your way to the front page very easily (This front page gets 4.5 million hits a month).
Microsoft, please fix these issues. It provides incredibly easy vectors for threat actors to gain credibility and get exposure to developers.
Dear Microsoft,
You created an amazing product, one used and adored by millions of developers, but those developers put their trust in you to design a safe product. I can only hope that the security design flaws mentioned in this blog post will be fixed in the coming months, if you have access to anyone at Microsoft working on Visual Studio Code, do share this with them.
I’ve only touched on the major design issues that we found during our research, there are many more smaller issues and perhaps a big over-arching problem. The fact that VSCode is unmanaged. Now, most IDEs are unmanaged, so this is not something to say against Microsoft, but it highlights a simple solution. If organizations had the ability to gain visibility, assess, and govern their IDEs, the risk and impact of this attack vertical could have been minimized.
But, until this happens, we decided to take it to our own hands and help organizations mitigate this threat by creating a free community tool to analyze suspicious Visual Studio Code extensions, navigate the extension jungle to detect harmful code, risky access, and or other security vulnerabilities.
In the next blog post, “4/6 | Introducing ExtensionTotal: How to Assess Risk in VS Code Extensions” (Now published!) we will introduce our solution to this niche but risky problem. As always, stay tuned.
Edit: We’ve released our free community tool to help solve this problem, checkout ExtensionTotal
Fun Security Design Flaw Excluded From The Main Post
There is a utility package developed by Microsoft called vsce used to package your extension code once you are done developing. A fun fact Microsoft does not mention is that when you use the utility, it does not only pack the “build” or “dist” folder, but the entire folder you are currently on. During our research, we found thousands of extensions accidentally packaged with their source code and secrets, some of which included AWS Keys, Github Secret Credentials, Google Credentials, Personal Access Tokens, SMTP, and OpenAI Keys.
