6 ms·

> 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 comman

by 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 ago
Indeed. 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 ago
  The "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 ago
    They 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 ago
    This. 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.
- xg15 3y ago
  Isn't the whole "airtight hatchway" concept mostly invalidated today by "defense in depth" an "zero-trust networking" paradigms? Effectively, the airtight hatchway often isn't, so you do have to think about cases where the attacker is behind it. E.g., it used to be an effective security measure to have a daemon listen on loopback only. But then browsers relaxed the same-origin policy and today every sleazy banner ad can get the browser to open a TCP connection on loopback and at least send a TLS handshake - and, if the daemon accepts that, an OPTIONS request with an attacker-controlled URL. So a daemon has to perform at least some basic validation on incoming connections to be secure.
  - plorkyeran 3y ago
    Zero-trust networking still involves threat models and things which you are and aren't trying to defend against. The "airtight hatchway" concept is just that once you've declared that a certain type of attack isn't something you're trying to prevent, there's no point in reporting issues which rely on that attack because it's already known to be vulnerable. Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. If your threat model involves people trying to exfiltrate data from a developer machine with an internet connection in an innocent-looking way, this VSC feature is a problem. Most companies either don't make an attempt at preventing that, or would use an airgapped setup so it's not something worth caring about.
    - Dylan16807 3y ago
      > Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. And even if you're not in the innermost area, an attack might exist entirely in the space between two hatchways and not breach any.
  - josephcsible 3y ago
    Isn't this validly described as "it lets you execute commands as a particular user on a particular host, but requires you to first execute a command as that user on that host"? Even in "defense in depth" or "zero-trust networking" paradigms, what does this ever let attackers do that they couldn't do already?
xg15 3y ago
I think there is a difference in degree. There is some likelihood that VS Code may already be installed (depending on who the attacker wants to target), so the victim "just" has to be tricked to run a single shell command - and the attacker immediately gets live shell access, without having to worry about firewalls, connectivity, finding the victim's address, etc. So I think the danger of this is less that it's technically an RCE exploit (as indeed you already need an existing way to run code to trigger it) - but rather that it lets an attacker turn a relatively simple capability (planting a single shell command with no back channel that the victim might run at some point in the future) into a sophisticated one (having access to a full remote shell with all bells and whistles, including firewall traversal, automatic reconnect and file transfer). Edit: ok, looks like the attacker already needs a back channel to get hold of the access code for the tunnel.
- _cenw 3y ago
  ssh.exe seems to be on enough Windows machines these days. How's that different?
  - eddythompson80 3y ago
    powershell.exe is on all of them. Just load up System.Net.TcpListener/Client and bob’s your uncle.
    - deleted 3y ago
      [deleted]
    - msm_ 3y ago
      Running arbitrary Powershell scripts from disk during OS autostart is one of the (if not the) loudest things attacker could do. The point of this blog post is stealth. Nobody claims it's a vulnerability in VS code (or vulnerability in anything at all), just a convenient method of persistence.
  - xg15 3y ago
    ssh.exe would at least show up on the firewall as "ssh connecting to a dubious host". The VSCode thing would show up as "VSCode connecting to some random Microsoft domain".
Spooky23 3y ago
Looking at it from a risk management perspective there’s more nuance. There’s lots of ways to tunnel, but a methodology that looks and may be legit is a great one. This a great way to have a long term, persistent exfiltration mechanism. Compromise some desktops, move laterally through the network and you have a river of data flowing out.
deleted 3y ago
[deleted]
mac-chaffee 3y ago
Unfortunately, differentiating good behavior from malicious behavior is a central pillar of security, and the existence of this feature undermines that pillar. * The fact that it's in a popular signed binary means it bypasses app allow-lists. * The fact that it flows through Microsoft's servers bypasses firewall allow-lists. * The fact that no stage2 is required bypasses antivirus scanning. I say "unfortunately" because I personally think attempting to differentiate good behavior from malicious behavior is losing battle. Design-based or resilience-based security controls are the way to go IMO: https://kellyshortridge.com/blog/posts/control-vs-resilience-cybersecurity-strategy/ https://kellyshortridge.com/blog/posts/control-vs-resilience...

by ptx 3y ago

josephcsible 3y ago

Indeed. 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 ago
The "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 ago
  They 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 ago
  This. 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.
xg15 3y ago
Isn't the whole "airtight hatchway" concept mostly invalidated today by "defense in depth" an "zero-trust networking" paradigms? Effectively, the airtight hatchway often isn't, so you do have to think about cases where the attacker is behind it. E.g., it used to be an effective security measure to have a daemon listen on loopback only. But then browsers relaxed the same-origin policy and today every sleazy banner ad can get the browser to open a TCP connection on loopback and at least send a TLS handshake - and, if the daemon accepts that, an OPTIONS request with an attacker-controlled URL. So a daemon has to perform at least some basic validation on incoming connections to be secure.
- plorkyeran 3y ago
  Zero-trust networking still involves threat models and things which you are and aren't trying to defend against. The "airtight hatchway" concept is just that once you've declared that a certain type of attack isn't something you're trying to prevent, there's no point in reporting issues which rely on that attack because it's already known to be vulnerable. Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. If your threat model involves people trying to exfiltrate data from a developer machine with an internet connection in an innocent-looking way, this VSC feature is a problem. Most companies either don't make an attempt at preventing that, or would use an airgapped setup so it's not something worth caring about.
  - Dylan16807 3y ago
    > Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. And even if you're not in the innermost area, an attack might exist entirely in the space between two hatchways and not breach any.
- josephcsible 3y ago
  Isn't this validly described as "it lets you execute commands as a particular user on a particular host, but requires you to first execute a command as that user on that host"? Even in "defense in depth" or "zero-trust networking" paradigms, what does this ever let attackers do that they couldn't do already?

xg15 3y ago

I think there is a difference in degree. There is some likelihood that VS Code may already be installed (depending on who the attacker wants to target), so the victim "just" has to be tricked to run a single shell command - and the attacker immediately gets live shell access, without having to worry about firewalls, connectivity, finding the victim's address, etc. So I think the danger of this is less that it's technically an RCE exploit (as indeed you already need an existing way to run code to trigger it) - but rather that it lets an attacker turn a relatively simple capability (planting a single shell command with no back channel that the victim might run at some point in the future) into a sophisticated one (having access to a full remote shell with all bells and whistles, including firewall traversal, automatic reconnect and file transfer). Edit: ok, looks like the attacker already needs a back channel to get hold of the access code for the tunnel.

_cenw 3y ago
ssh.exe seems to be on enough Windows machines these days. How's that different?
- eddythompson80 3y ago
  powershell.exe is on all of them. Just load up System.Net.TcpListener/Client and bob’s your uncle.
  - deleted 3y ago
    [deleted]
  - msm_ 3y ago
    Running arbitrary Powershell scripts from disk during OS autostart is one of the (if not the) loudest things attacker could do. The point of this blog post is stealth. Nobody claims it's a vulnerability in VS code (or vulnerability in anything at all), just a convenient method of persistence.
- xg15 3y ago
  ssh.exe would at least show up on the firewall as "ssh connecting to a dubious host". The VSCode thing would show up as "VSCode connecting to some random Microsoft domain".

Spooky23 3y ago

Looking at it from a risk management perspective there’s more nuance. There’s lots of ways to tunnel, but a methodology that looks and may be legit is a great one. This a great way to have a long term, persistent exfiltration mechanism. Compromise some desktops, move laterally through the network and you have a river of data flowing out.

deleted 3y ago

[deleted]

mac-chaffee 3y ago

Unfortunately, differentiating good behavior from malicious behavior is a central pillar of security, and the existence of this feature undermines that pillar. * The fact that it's in a popular signed binary means it bypasses app allow-lists. * The fact that it flows through Microsoft's servers bypasses firewall allow-lists. * The fact that no stage2 is required bypasses antivirus scanning. I say "unfortunately" because I personally think attempting to differentiate good behavior from malicious behavior is losing battle. Design-based or resilience-based security controls are the way to go IMO: https://kellyshortridge.com/blog/posts/control-vs-resilience-cybersecurity-strategy/ https://kellyshortridge.com/blog/posts/control-vs-resilience...