8 ms·
Blocking Visual Studio Code embedded reverse shell before it's too late
- throwaway02y 3y ago> internal network is now accessible from anywhere ! If you exposed it willingly.
- baz00 3y agoI work with 500 idiots. Willingly and cluelessly are interchangeable.
- eddythompson80 3y agoTake their computer away.
- baz00 3y agoManagement frowned at this suggestion.
- Jochim 3y agoSeems to be the goal of most "cybersecurity" types.
- baz00 3y agoI thought their goal was collecting vendor certifications.
- eddythompson80 3y agoOuch dude
- baz00 3y agoIt's a burn but it's accurate. Had three consultancies in (high end well known ones) and and two in house certified to their eyeballs professional cyber security experts in charge. All they did was tick a fuck load of boxes, run some scans, spend a lot of money and make it really hard for people. Yet I managed to find a fully remote RCE and exploit it in 30 minutes after they did all this. The industry is a fucking scam.
- eurg 3y agoNot nicely put, but not wrong. I had half an heart attack when that feature was rolled out, and the danger was split only between myself and a colleague. I can't even trust myself to not screw up. I needed another permanencied invocation of the principle of hope.
- intelVISA 3y agoWell said, this is why working solo can be beneficial: only one idiot to look out for. :)
- userbinator 3y agoThe industry is only going to keep making more idiots if they treat developers like this.
- baz00 3y agoIt kept producing more idiots when we didn't treat them like this and this is easier so fuck it.
- taway1237 3y agoThe point of the blog post is that this method is useful for attackers (as a so-called lolbin - trusted binary used in a malicious way).
- ptx 3y ago> this tunnel can be triggered from the cmdline with the portable version of code.exe. An attacker just has to upload the binary If the attacker can run commands and upload binaries, it really doesn't matter what VS Code does. There are lots of commands and binaries that can open network connections. 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's airtight hatchway [1]. [0] https://badoption.eu/blog/2023/01/31/code_c2.html https://badoption.eu/blog/2023/01/31/code_c2.html [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- josephcsible 3y agoIndeed. This whole post is a nothingburger since the "attack" requires the attacker to already be on the wrong side of the airtight hatchway.
- dundarious 3y agoThe "airtight hatchway" argument is that it's not a security bug in the program. I don't think TFA makes the case that it is a security bug, so it's moot. Personally I'm not particularly moved by the lolbin and footgun case it does make. I am just mildly put off by how text editors and IDEs are inextricably bundled with so many double-edged remote capabilities.
- shadowgovt 3y agoThey are nowadays competing with cloud services for users. Increasingly, being able to manipulate data on a machine other than the one I'm currently physically sitting at is table stakes features.
- _cenw 3y agoThis. I'd be more worried some worker opens up a piece of internal infrastructure deliberately to make their work life easier instead of an attacker taking advantage of the binary being trusted.
- RcouF1uZ4gsC 3y ago> 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't be detected by any anti-virus since it is legitimate and singed windows binary. This feels like Raymond Chen’s other side of the airtight hatch. 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.
- taway1237 3y agoVs code functions as a remote access trojan (RAT) in this scenario. But while your AV will hopefully detect and flag most common RATs, it won't flag vs code. This method is often used in real world attacks (especially targetted ones). I'm not saying that's a huge concern, but something one has to consider when protecting their organisation.
- skinner927 3y agoBut how did you put the binary on the box and run it without an already working RCE/RAT?
- _cenw 3y agoI think it's a point about persistence. It's easy to obfuscate an existing piece of malware to not be found for a day or two, harder to keep it undetected forever. If you instead task schedule code.exe to expose some internal network port, you can keep it for as long as the machine lives. But that's already assuming you get compromised anyway, and that your compromised workstations have things worth reaching on their internal network/VPN. All things that are true on real corporate networks, but "fixing" this vulnerability is still pretty low impact in the grand scheme of things one could do to to improve the situation. But in my experience, most CISOs aren't that great at setting priorities and threat modeling anyway: One just recently told me they doesn't want XSS vulnerabilities reported, because the scanner would find them anyway - but sends out daily all-caps emails about specific emails being phishing.
- deleted 3y ago[deleted]
- killjoywashere 3y agoIs this more or less of a vulnerability than VS Code's Live Share? https://code.visualstudio.com/learn/collaboration/live-share https://code.visualstudio.com/learn/collaboration/live-share
- _cenw 3y agoNo, it's an intentional ngrok-like tunneling feature.
- pc_edwin 3y agoThe is the obvious next step for the industry/technology. I think a better answer is to maximally reduce the potential fallout from a compromised employee. This is easier said then done and if you go the direction of complicated procedures employees will usually just try to bypass procedures entirely. 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. Its also the easiest its ever been to have a sandboxed production environment and a near parallel staging environment.
- ahhfgshando6698 3y agoStepping back for a second...do we have evidence that these sorts of issues are actually the cause of a significant number of breaches rather than paranoia on the part of people that are paid to be paranoid? That's not a rhetorical question, I 'm actually curious to find out. The reason I ask is that of all the big security breaches that end up in the news, I cannot recall a single case where these sorts of issues (for instance, not locking down deployment to production) was the root cause.
- donatj 3y agoSo 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/mouse/monitor that can already do this undetectably.
- catlifeonmars 3y agoI think there’s an interesting argument to be made about reducing the attack surface area for userspace though. A really naive thing to do would be to run any shell (any program really) in its own isolated environment. The barriers to this aren’t really technical IMO, mostly they are UX barriers. It needs good OS support, and there’s not really a developer oriented OS with smooth mechanisms for escalating and de-escalating privileges at a granular level (sudo ain’t it lol). An ideal development environment would: (1) allow for executing unsigned/self-signed code without jumping through hoops or relying on a 3rd party or App Store, (2) allow for escalation and automatic descalation of fine-grained privileges with native UX for grants (LittleSnitch on macOS has a good design for this specifically for networking IMO —- one could imagine extending this to the file system). There are plenty of systems that have some aspects of these, but I have not seen both, at least not in a form accessible enough to be ubiquitous in 2023.
- nikanj 3y agoCode execution leads to code execution. CVE score 9.98 confirmed by Mitre
- jeremyjh 3y agoOr someone with physical access for five minutes can set themselves with a lifetime subscription to whatever you may have thats worth stealing on that machine in the future, without installing anything that can be detected as malware.
- skybrian 3y agoHere's the "airtight hatch" article folks are referring to: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31... 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? I'm also reminded of how browsers do defense in depth. The "airtight hatch" 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? But that assumes a developer environment can be made into a low-privilege container, sort of like a browser's render process. I don't think many people work that way? 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. That'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?
- ahhfgshando6698 3y ago[dead]
- t0mas88 3y agoThe "airtight hatch" story is not fully applicable here. Executing VScode instead of a random exploit payload could be considered an increase in privilege, because you're going from an unsigned and unknown binary to one that is signed by Microsoft. And VScode is probably allowed through any outgoing firewall rules because the main user of the machine is using it, while a random exploit payload would not be.
- opentokix 3y ago[flagged]
- okokwhatever 3y ago[flagged]
- Longhanks 3y ago[flagged]
- albert_e 3y agois this already blocked by default in most corporate environments? it seems this opens up a easy way to exfilarate corporate data (without detection?) correct me if I am wrong please attacker (or a cooperating employee) can browse and download any files from target machine inside corporate network by opening the generated vscode.dev/tunnel URL from a browser on any device anywhere in the world ?
- 1letterunixname 3y agoYep. A place I worked forked VSCode as it's recommended IDE. VSCode can prevent installation of all but allowlisted extensions by policy. They used an extensive review process for third-party extensions because some components are necessary to run remotely in the development environment instead of on the local machine with the VSCode UI. Random thought: Since there are N editors and M languages, that's N x M plugins. Surely there's a better way to reduce the effort involved.
- eddythompson80 3y ago> Random thought: Since there are N editors and M languages, that's N x M plugins. Surely there's a better way to reduce the effort involved. Yeah, it’s called LSP. The core of most plugins is just an lsp that’s shared between vim, neovim, emacs, vscode, sublime, etc. all the editor needs is to support generic lsp, or have a generic lsp plugin like vim/emacs. For example if you look at neovim, you just load the actual lsp and wire it up to the editor in lua. That’s more or less the majority of the “extension code” for something like sublime or vscode (plus some other niceties)
- 1letterunixname 3y agoYou're making a dishonest leap here. Language server protocol doesn't create a universal plugin.
- eddythompson80 3y agoWhat do you mean by a universal plugin?
- parentheses 3y agoThis can be particularly pernicious since in order to collaborate, someone may do this and not consider the security ramifications
- CalChris 3y agoThe 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/we don't. 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 enable. 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. Yo Microsoft, add a preference for this thing which defaults off.
- Longhanks 3y agoIt is not enabled by default? You need to log in with a GitHub or Microsoft account, install the remote dev extension, and then explicitly enable the feature on a per-machine basis (and yes, this can be done via the CLI, as the article mentions). If you don’t know the feature set of the software you use, maybe don’t use the software instead of blaming the vendor.
- CalChris 3y agoBut I don't want to know this feature in order to use this editor. Apparently Auto Closing Overtype deserves an enable/disable/auto flag but Embedded Reverse Shell doesn't. Yo Microsoft, add a preference for this thing which defaults off.
- oefrha 3y ago1. You don’t need to install any extension, `code tunnel` is builtin, the extension is UI stuff using the tunnel. No need for any extension to open a reverse shell. 2. It’s about an attacker exploiting the feature, the attacker is enabling it and doing the login. Whether you need to enable it yourself is largely irrelevant, in fact you’re probably more likely to notice an ongoing attack if you use the feature yourself. Anyway, default is pointless, a gadget is a gadget as long as the bits are there and easily executable.
- ethbr1 3y ago> If you don’t know the feature set of the software you use, maybe don’t use the software instead of blaming the vendor. Saying this in reference to modern Microsoft, with their default-opt-in-to-drive-market-share strategy, is a pretty high bar. Effectively it means "Don't use Windows."
- userbinator 3y agoI 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. Perhaps you shouldn't treat your users like stupid cattle, or you're not going to get anything better but only worse.
- bad_alloc 3y agoIt's about preventing mistakes and everybody makes those. If your company or institution is a target for spies, you want to avoid anything that makes it easy for an attacker.
- vorpalhex 3y agoYou know, sometimes people cut themselves very badly with sharp knives. I'd like you to give me all your kitchen knives. If you need to cook a steak or something, you can just give me a call and I will supervise you while you use the knife. I wouldn't want you to make a mistake and make it too easy to injure yourself.
- TeMPOraL 3y agoIn medicine, this is called an autoimmune disease. In social sciences, this is called paranoia. The latter is about about as helpful to an organization as the former is to a human body.
- DarkmSparks 3y agowhy is this not an extension? I cannot think of a single argument for this being default functionality.
- nikanj 3y agoIf 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
- iguana_lawyer 3y agoThis very poorly written