Move over, npm: Now VS Code extensions can’t be trusted

It’s super easy to spoof Visual Studio Code extensions. And it’s incredibly hard to detect.

If you unwittingly install a malicious extension, bad actors can get access to your code to inject back doors, steal your credentials, drop malware or use your login to move laterally. It’s a nasty problem that’s not getting enough attention.

It may also be present in Visual Studio and Azure DevOps. In this week’s Secure Software Blogwatch, we run and hide.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Apollo 12’s tricky error.
 

VSC Marketplace FAIL

What’s the craic? Bill Toulas reports — “VSCode Marketplace can be abused to host malicious extensions ”:

“Over 27 million downloads”
Researchers have found it surprisingly easy to upload malicious Visual Studio Code extensions to the VSCode Marketplace, and discovered signs of threat actors already exploiting this weakness. Visual Studio Code (VSC) is a source-code editor published by Microsoft. … Microsoft also operates an extensions market for the IDE, called the VSCode Marketplace, which offers add-ons that extend the application's functionality.
…
Some of these extensions have tens of millions of downloads, so if there was an easy way to spoof them on the platform, malicious actors could quickly attack a respectable number of victims. [They] can be used to install additional programs, steal or tamper with source code in the VSCode IDE, and even use the developer's SSH key to access connected GitHub repositories.
…
Reserchers … attempted to "typosquat" a popular code formatting extension named "Prettier," which has over 27 million downloads. However … they found that they could reuse the real extension's logo and description and give it the same name as the real extension. [And] the publisher can still edit the stats freely, so these can be modified to create the sense of an active project with a long history of development … the researchers could replicate the legitimate extension's GitHub project name, last commit times, pull requests, and open issues.

That sounds evil. And Tim Anderson has more — “Researchers demonstrate a thousand installs of fake VS Code extension in 48 hours”:

“Potential for harm is real”
VS Code is the most popular development tool globally thanks in part to the huge range of extensions available. … The heart of the problem is that as with the big package repositories like NPM or PyPi, having a human check every submission is too costly so checks have to be automated, and in principle a bad extension might be downloaded thousands of times before someone complained and it was taken down.
…
Package repositories are frequently in the public eye because of the risks of bad dependencies but developer add-ons not so much. … But the potential for harm is real and this report shows weaknesses in the protections currently in place.

Where’s Ian Betteridge when you need him? Paul Krill asks the obvious question, “Can developers trust extensions downloaded for Microsoft’s popular Visual Studio Code editor?”

“Could install ransomware, wipers, and other malicious code”
Attackers could easily impersonate popular extensions and trick unknowing developers into downloading them. Some extensions may already have taken advantage of this.
…
It can be challenging to distinguish between malicious and benign extensions, and the lack of sandbox capabilities means that extensions could install ransomware, wipers, and other malicious code. [Dependencies] also can be downloaded from NPM, which faces security threats as well.

Horse’s mouth? Ilay Goldman — “Can You Trust Your VSCode Extensions?”:

“Extensions run with the privileges of the user”
We’ve uncovered a new attack method which could act as an entry point for an attack on many organizations. We’ve also discovered that some extensions may have already been taking advantage to exploit this attack vector. … As a VSCode user, have you ever asked yourself if a VSCode extension is trustworthy?
…
The VSCode Marketplace uses a blue … check mark near the author’s name. … We’ve come to expect that a publisher with a blue check mark means that the platform has verified that the publisher is in fact who he claims to be. … In reality, a publisher could buy any domain and register it to get that verified check mark.
…
It's also important to note that VSCode extensions are written in Node, and the packages are downloaded from NPM. … There is also a constant threat of malicious code packages being uploaded to … NPM. Therefore, there is the actual risk that an unaware legitimate developer could unknowingly use a malicious package from NPM as a dependency for his extension, leading to the compromise of the entire extension and unwittingly risking the community.

It’s a challenge even for security-aware developers to distinguish between malicious and benign extensions. … However, all extensions run with the privileges of the user … without any sandbox. [They] can access and even alter all the code that you have locally and even use your SSH key to change the code in all your organization’s repositories in GitHub! … The Marketplace also offers extensions for Visual Studio and Azure DevOps. At first inspection, they are vulnerable as well.

Are we surprised? bobmagicii isn’t:

Not surprised here. … The entire system seems barely a quarter baked.
…
When you release an extension, first, if you do vsce login [email] it yells at you that it cannot be a "human readable" id. So then you do vsce login [human-readable-username] and it's like "ok cool."

To top it off, if you ever screw up a release, there is no way to delete it — you have to ask support for help on GitHub. They flat out told everyone in the comments begging for a delete that when that happens, they send someone into the data center with an sql query in their hand.

It’s a bit of an open secret among devs such as satya71:

Stating the obvious is sometimes useful to get someone to take notice. Let’s hope.

Was Microsoft naïve? What can we learn from others’ mistakes? CEC-P is a fan of the red-team thought experiment:

Whenever you roll out any type of … literally anything from the ground up, in the initial planning stages ask yourself, "What is the worst of the worst actors in the IT space going to do?" You have to put yourselves in their shoes and "attack" it before they do, not after you roll it out.

I don't care if it's an online game or a giant tech services portal or anything in between. If you aren't asking how someone's going to exploit it to do something bad and it gets to release without asking that, your project and product leads should all be fired and replaced with someone who has been on the internet before.

Until then, what should devs do? u/boofaceleemz:

The same as any program that allows third party plugins and extensions: Be discerning and don’t download any from authors you don’t trust. Understand that even if you do trust the author, **** can happen — so don’t introduce moving parts you don’t actually need to do your work.

If you’re managing employees who use VSCode, you should maintain a whitelist of allowed extensions. Same goes for browsers and anything else.

Meanwhile, please remove yourself from jjaa’s grassed area:

The target audience for VSC is mostly same crowd that hands off dependency management entirely to NPM, which has a track record of also occasionally pulling in things some bad actor … cooked up.

And Finally:

Somehow, this has to be IBM’s fault

Previously in And finally

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Barthelemy de Mazenod (via Unsplash; leveled and cropped)