6 ms·
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
by 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 agossh.exe seems to be on enough Windows machines these days. How's that different?
- eddythompson80 3y agopowershell.exe is on all of them. Just load up System.Net.TcpListener/Client and bob’s your uncle.
- deleted 3y ago[deleted]
- msm_ 3y agoRunning 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 agossh.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".
- Zetobal 3y agoYeah, 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.
- hutzlibu 3y agoHow 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?
- Zetobal 3y agoIf 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.
- rat9988 3y agoThe question is not to keep your data safe, but to know that there is a breach to begin with.
- Zetobal 3y agoIf 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.
- mthomasmw 3y agoYou'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.
- xg15 3y agoThanks for the explanation, that makes a lot more sense actually.
- dangus 3y agoAnd 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.
- vengefulduck 3y agoWrite 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.