Blocking Visual Studio Code embedded reverse shell before it's too late

&gt; <i>this tunnel can be triggered from the cmdline with the portable version of code.exe. An attacker just has to upload the binary</i><p>If the attacker can run commands and upload binaries, it really doesn&#x27;t matter what VS Code does. There are lots of commands and binaries that can open network connections.<p>Edit: The attacker apparently needs to control the URL and exfiltrate the activation code [0], so if they can already execute commands and open network connections, then this enables them to execute commands and open network connections. So, as mentioned by other commenters, this does sound a lot like Raymond Chen&#x27;s airtight hatchway [1].<p>[0] <a href="https:&#x2F;&#x2F;badoption.eu&#x2F;blog&#x2F;2023&#x2F;01&#x2F;31&#x2F;code_c2.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;badoption.eu&#x2F;blog&#x2F;2023&#x2F;01&#x2F;31&#x2F;code_c2.html</a><p>[1] <a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=31283" rel="nofollow noreferrer">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=31...</a>

Here&#x27;s the &quot;airtight hatch&quot; article folks are referring to:<p><a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=31283" rel="nofollow noreferrer">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=31...</a><p>Phishing does involve an insider being confused and letting someone in, though. The question is what a vscode user could be tricked into doing. That part of the explanation could be fleshed out more?<p>I&#x27;m also reminded of how browsers do defense in depth. The &quot;airtight hatch&quot; argument implies that second-level security is worthless because the first level is secure. Having a useful binary already there on the system might be useful for chaining with another exploit?<p>But that assumes a developer environment can be made into a low-privilege container, sort of like a browser&#x27;s render process. I don&#x27;t think many people work that way?<p>Perhaps someday we will work in containers and code editors will be locked down like browsers. The most straightforward path to that would probably be for the code editor to run in the browser.<p>That&#x27;s something VS Code can do, so a policy that says you must use a browser-based version of VS Code might actually work for some organizations?

The vast vast majority of users will neither want nor use this embedded reverse shell functionality. I fall in that majority. Hats off to the users who do to get their work done with it but I&#x2F;we don&#x27;t.<p>So for us, this function should have an enable flag which is off by default. The slim minority who do want it and would use it can suffer the inordinate burden of having to go into the preferences panel and clicking <i>enable</i>.<p>You can argue whether it is a hole (it is) or whether it is a piece of a hole (it is). But it should be off by default and on by permission.<p>Yo Microsoft, add a preference for this thing which defaults off.

So if someone already has physical access to a machine they can get remote access to the machine? Even ignoring the fact that they already had access, they sell devices that emulate a keyboard&#x2F;mouse&#x2F;monitor that can already do this undetectably.

&gt; The worse part is that this tunnel can be triggered from the cmdline with the portable version of code.exe. An attacker just has to upload the binary, which won&#x27;t be detected by any anti-virus since it is legitimate and singed windows binary.<p>This feels like Raymond Chen’s other side of the airtight hatch.<p>Yes, if you can get a binary you control onto the user’s system and get them to run it, you can use that to have remote code execution. But then, the whole exploit described is remote code execution.

<i>&gt; internal network is now accessible from anywhere !</i><p>If you exposed it willingly.

This can be particularly pernicious since in order to collaborate, someone may do this and not consider the security ramifications

If I enter your house through the front door and unlatch the patio door from the inside, I can then enter the house through the patio door

<i>I am so glad that my users now have the ability to expose their computer with highly sensitive data right on the web, through an authentication I nor control, nor supervise.</i><p>Perhaps you shouldn&#x27;t treat your users like stupid cattle, or you&#x27;re not going to get anything better but only worse.

The is the obvious next step for the industry&#x2F;technology. I think a better answer is to maximally reduce the potential fallout from a compromised employee.<p>This is easier said then done and if you go the direction of complicated procedures employees will usually just try to bypass procedures entirely.<p>However I think there is a middle ground or a sweet spot here. The tech has come a long way in the past decade or so. Its pretty easy to have a set up where almost no employee can deploy to production from their local machine.<p>Its also the easiest its ever been to have a sandboxed production environment and a near parallel staging environment.

is this already blocked by default in most corporate environments?<p>it seems this opens up a easy way to exfilarate corporate data (without detection?)<p>correct me if I am wrong please<p>attacker (or a cooperating employee) can browse and download any files from target machine inside corporate network by opening the generated vscode.dev&#x2F;tunnel URL from a browser on any device anywhere in the world ?

why is this not an extension?<p>I cannot think of a single argument for this being default functionality.

Is this more or less of a vulnerability than VS Code&#x27;s Live Share? <a href="https:&#x2F;&#x2F;code.visualstudio.com&#x2F;learn&#x2F;collaboration&#x2F;live-share" rel="nofollow noreferrer">https:&#x2F;&#x2F;code.visualstudio.com&#x2F;learn&#x2F;collaboration&#x2F;live-share</a>

This very poorly written