Hacker News Reader

Comment by ptx | Hacker News Reader

> 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

[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

View on HN

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.

ssh.exe seems to be on enough Windows machines these days. How's that different?

powershell.exe is on all of them. Just load up System.Net.TcpListener/Client and bob’s your uncle.

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.

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".

Yeah, sorry but if you are in an environment were you are actively monitoring your firewall and you didn't get that your machine was breached you have way other problems than vscode or an SSH process.

How do you get that your machine(or one of the many you are observing) was breached, if the attacker is not doing obvious damage? I think monitoring connections is standard procedure to find this out?

If someone can access your machines physically, can login, play with an USB Stick or download malware. No form of monitoring your logs will keep your data safe.

The question is not to keep your data safe, but to know that there is a breach to begin with.

If a user is logged in with high activity at a time the user should not be working and the only thing that would tick you off is your firewall log you got other problems than a remote access feature of vscode that "could" be abused ONLY if the attacker had previously breached your system.

And if the attacker is smart and uses active times to hide his activity, then monitoring active connections is a smart way, no?

It's nice to have especially if you need to find a rogue employee but if you catch a bad actor only when he is already exfiltrating, you failed at your job.

Sure, but when some damage is already done, you can and must still prevent greater damage. And you have to assume, that one day something fails. So - "monitoring active connections is a smart way, no?"

You've misunderstood the situation completely. The first job of a persistent attacker is to gain acceess. The second job of a persistent attacker is to pivot that access from illegitimate to legitimate, so that by the time their TTPs become IOCs, log rotation has wiped that illegitimate access from the books and all their access looks legitimate.

What we have here is a way for an attacker using shady means (email-delivered 0day, parking lot thumbdrive, browser drive-by compromise) to take over a computer and then drop a signed package that will allow for remote control over time that looks completely legitimate. To a network IDS, that access will look like an authorized cloud tunnel, completely normal. To a file scanner, it will look like an vendor-signed binary, the gold standard. To the complete defense-in-depth stack, the entire c2 chain is cloaked in legitimacy. If you get a single detection at all for the initial compromise (not possible with 0day), the entire rest of the kill chain looks like legitimate access and vanishes.

It's a nightmare for defense in depth and hunt teams.

Thanks for the explanation, that makes a lot more sense actually.

And then for the attacker to do anything damaging to the computer they need to trick you into revealing your sudo/admin password, right?

On a default Unix-like desktop shell you can’t really do much permanent harm without elevating your permissions.

Write access to .bashrc is plenty to very sneakily get sudo access tho.

  alias sudo='./.my-evil-sudo-binary'

And wait till the next time the user authenticates, they wont see anything amiss and you just silently delete the alias after you’ve got the sudo password.

Also even without root dumping .ssh and the browser’s cookie jar is probably plenty to achieve lateral movement and you don’t need root for that.

Indeed. This whole post is a nothingburger since the "attack" requires the attacker to already be on the wrong side of the airtight hatchway.

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.

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.

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.

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.

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.

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

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?

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

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.

Reply on news.ycombinator.com