Comment by xg15 | Hacker News Reader

Comment by xg15 | Hacker News Reader

Parent Full thread

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.

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.

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

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.

Reply on news.ycombinator.com