Phishing with an in-browser remote desktop | Hacker News Reader

Phishing with an in-browser remote desktop

mrd0x.com

53 pointsjsnell13 comments

Why this is interesting: a major defense against mass account takeovers (ATOs) at large scale companies has been fingerprinting browsers. You as a normal user see this most when you use something like reCaptcha, but it's actually happening on nearly every login flow for major websites. By blocking automation like evilginx, you stop a lot of phishing and credential stuffing attacks against your users.

Using VNC here is super clever. This means that the "automation" part of the phishing attack is actually a browser just like the user is using, so you can't fingerprint it. In fact, the victim is really typing in their password into a real Google login page, but the attacker is logging everything through VNC. It's going to be very hard for Google (or anyone else) to detect this.

The solution to this (like all phishing attacks), is still WebAuthn. However, many of us in security were hoping we could get by with bandaids like fingerprinting until WebAuthn was more widespread.

I really don't get the hype about WebAuthn. It's only real protection against phishing is that credentials are associated with a particular domain which has been a feature of every password-manager, including the OS/browser built-in ones since forever. The thing requesting the password -- (i.e. the browser) is still the ultimately the source of trust. The treat model these things protect against is so narrow, and now narrower since phones have built-in secure storage, that it can't be worth the effort compared to a marketing push for people to use Bitwarden, Lastpass, 1Password, KeypassX, Browsers, or iCloud password saving. And if you really care about accidental logging of plaintext passwords PAKE already has your back.

If we have the political capital to somehow get everyone on-board with changing their flow I really don't see why it should be webauthn. It's ultimately just a key stored somewhere controlled by the client presenting it, but with more red tape, pseudo-drm, and ewaste.

^ If you're in a high-security setting then go for it, but for the masses nah.

I asked this on the Twitter thread and got no response. Is this even useful on its own? Or at all? It requires a redirect to some other domain where the VNC is hosted.

Would modern up-to-date browsers just see it as cross site and block it?

Wouldn't it still require sneaking in the VNC code to the site you want that user coming through via a pre-existing exploit chain or social engineering scheme?

By itself this seems negated by standard browser security. If youre using it at the end of some exploit chain it seems like there would be several other more effective and useful things to do from that chain like an invisible proxy mitm.

There are two browsers involved, both dealing with just one site and neither in any way aware of the other.

The outer browser is running on the user's machine, loading a page from the attacker's origin. That page makes no cross-site requests, but just establishes a websocket connection to the attacker's server (the data connection for the remote desktop protocol) and renders the remote desktop to the outer browser on a canvas.

The inner browser is running on the attacker's server, just configured to show no URL bar or other chrome. It has loaded the genuine login page of the target site completely normally.

It's your site, so you can set the URL to anything you can buy. In the demo he is using an IP, but nothing to stop you buying gooogle.com or something with Unicode tomfoolery that will be enough to pass muster for most victims and look authentic at first pass.

This method of phishing can't work with 2FA physical key like yubikey, right?

No, unless combined with WebUSB trickery, and such an attack has been possible in the past. However, browsers currently implement blocklists of HIDs and other USB types from working with WebUSB.

Clever, but it's tough to imagine that anyone savvy enough to use 2FA will be fooled by this.

Really? If nothing looks phishy, few people are rigorous about inspecting URLs. Tech co's habits of using cryptic CDN domains and the like makes this hard behavior to change... login.google.goog-233.com ? hmm, guess they're doing some new clever thing I don't understand...oh well, I have things to do...

goog-233.com still fails the domain name test i taught my mom in 1999.

eh, accounts with 2FA get phished and popped all the time. Users will always be the weakest link.

Some people use 2FA because the service they're accessing requires it. Some people use 2FA for work accounts because their employer requires it. Using 2FA doesn't necessarily indicate savvy on the part of the user.

Most people are using 2FA either because it was mandated (e.g. most of the systems at work have mandatory 2FA) or because they were strongly urged to use 2FA even though they don't really care.

The problem here, as with all phishing, is that humans are easily fooled. But machines aren't fooled about this at all. Just have the machines make this critical decision and the problem evaporates, use WebAuthn to do 2FA. This makes life easier for humans because it is no longer their responsibility to try to figure out if they're being phished, WebAuthn solves that, back to my game of Wordle.

Reply on news.ycombinator.com