Some people have been led to believe that using MFA can stop you from getting hacked. It makes it a bit harder but certainly not impossible. Evil hackers these days use infograbbers or something like evilginx2, a tool that prides itself on bypassing 2-factor authentication. It acts as an invisible proxy, especially designed for login pages to act as a monster-in-the-middle.

FIDO2/WebAuthN/Passkeys boast about preventing phishing, so I tried it out to see what happens.

Let’s phish⌗

In our scenario the hacker is going to use evilginx. It’s set up so when people visit the website fastmail.not-a-phish.com, they see the login for fastmail.com/login.

I will be playing the role of the helpless victim. After a text¹ tells me my fastmail account will be deleted in 10 minutes unless I agree to the new terms of service, I hastily click the link to be greeted by what looks like the fastmail login page.²

So I login with my username and password, the hacker can pick it out of the traffic flowing through their fake website and see it.

But next I click to use my hardware security key to complete the login. Immediately it says something went wrong.

There’s no error in the browser’s console, Window’s Webauthn system hasn’t been called yet. It’s not immediately obvious what the problem is. We need to use the browser’s debugger to catch the error as it’s handled by Fastmail’s page javascript.

So 'rp.id' cannot be used with the current origin. Our current origin is the page we are on, fastmail.not-a-phish.com, while the rp.id is the Relying Party ID. It is set along with everything else needed for a WebAuthN authentication ceremony. We can see it being sent in the JSON response to the successful username & password POST request:

fastmail.com is a different website than fastmail.not-a-phish.com³, so Firefox prevents the authentication from even beginning. Here I feel both Firefox and Fastmail could do more to tell the user something phishy is going on, and raise some alarm bells.

Seeing this problem, what if the hacker changes the rp.id to match their fake website, fastmail.not-a-phish.com? evilginx can be configured to change bits of the website as it’s passed along, for just such domain fix ups. What happens then?

Firefox has no problems, and passes on the request to Window’s WebAuthN system. Once again, the hacker’s evil website is shown to the user, but not very prominently. Something about Windows prompts just make people go ‘yeah yeah whatever just do your thing and go away plz’. So I insert my key like it tells me to…

But it doesn’t work, instead suggesting that I’ve used the wrong key. This is because my security key doesn’t have any records for fastmail.not-a-pish.com. This is a less suspicious error, perhaps someone has separate work and personal keys, or attempted to use Window’s built in software keystore, or their phone’s over bluetooth. It could be raising unnecessary alarm to suggest something dodgy was occurring when people automatically have a few places to pick keys from and may have simply chosen wrong.

Well now what?⌗

At this point I’d say WebAuthN has been successful in preventing this phishing attack. I imagine a MITM attack from the correct fastmail.com domain would work, but to do that you’re either breaking TLS or have already compromised the user’s machine. In either case the hacker is better off just grabbing the cookie/auth token from the browser with an infograbber.

In the case of Fastmail, there’s another option:

I didn’t notice until I tried this experiment, but Fastmail offers classic SMS or email OTP as an alternative to the hardware security key. If I was desperately and quickly attempting to login, and the security key simply said “Sorry something went wrong 🤷”, there’s a decent chance I’d go for the SMS option. Evilgnix can grab the code, and/or the auth token after I’ve successfully logged in. No need to invent new attacks on WebAuthN, I’ve been pwned.

Bonus round⌗

While observing WebAuthN in action, I discovered Windows will log all WebAuthN events. You can see them in Application and Services Logs/Microsoft/Windows/WebAthN/Operational.

Included is a record of all communications with the hardware key. It’s stored as CBOR, a binary encoding of JSON. Event Viewer displays it as hexadecimal. Not all CBOR tools can decode it, since it’s a variation called CBOR Sequence, or cbor-seq. A easy tool to convert is at cbor.me, just tick cborseq. Though easy, it does the conversion server-side, so not very secure. I ended up using the python library cbor2, though I had to modify the sample command line tool to input hex, not just base64.

Here I’m showing the auth challenge sent to the hardware key. The rpid is included so the key can know what website is making the request.

Since all of this should be based on nonces and public keys, I don’t think it’s a massive problem to have these logs. Again a hacker with access probably also has your browser cookies and easier ways to access your accounts.