[HN Gopher] Phishing with an in-browser remote desktop
       ___________________________________________________________________
        
       Phishing with an in-browser remote desktop
        
       Author : jsnell
       Score  : 48 points
       Date   : 2022-02-22 23:26 UTC (23 hours ago)
        
 (HTM) web link (mrd0x.com)
 (TXT) w3m dump (mrd0x.com)
        
       | bqe wrote:
       | 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.
        
       | jaywalk wrote:
       | Clever, but it's tough to imagine that anyone savvy enough to use
       | 2FA will be fooled by this.
        
         | daxelrod wrote:
         | 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.
        
         | ghostly_s wrote:
         | 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...
        
         | edm0nd wrote:
         | eh, accounts with 2FA get phished and popped all the time.
         | Users will always be the weakest link.
        
         | tialaramex wrote:
         | 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.
        
       | systemz wrote:
       | This method of phishing can't work with 2FA physical key like
       | yubikey, right?
        
         | moloch wrote:
         | 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.
        
       | tekchip wrote:
       | 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.
        
         | kingcharles wrote:
         | 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.
        
         | jsnell wrote:
         | 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.
        
           | pinephoneguy wrote:
        
       ___________________________________________________________________
       (page generated 2022-02-23 23:02 UTC)