Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

PassKeys are a form of the WebAuthn CTAP specification to perform passwordless authentication. The idea is for a Client, such as the browser, to communicate with an authenticator, such as a mobile phone or USB device. In practice, "WebAuthn is just SSH (privkey-pubkey) for the web".

There is a difficult problem though: if the passkey is on my phone and I want to login via the web browser, how do I do that? PassKeys contain a cross-device authentication flow with various methods. One of these is using Bluetooth low energy (BLE). Since these devices ensure close proximity, the idea is that authentication is now completely phish-proof.

When doing cross-device login, WebAuthn authentication creates a QR code to scan. This is how the flow works:

1. User scans the QR code. The mobile phone's PassKey manager processes this data.
2. BLE connection is made.
3. Browser generates a random challenge for the Authenticator to sign with the stored private key.
4. Authenicator signs the challenge and sends it back.
5. Browser sends everything to the backend website.

FIDO intents, the URI found in the QR code, contain a blob with a bunch of serialized data. Since it contains a public key of the relying party, a timestamp, registered domains, and much more. Since this information is just a QR code, this means that FIDO intents can be triggered cross-origin. Why does this matter for security?

Here's the attack scenario:

1. Victim clicks on a link controlled by an attacker's page.
2. Attackers' device visits the login page of the victim user and the website they want to exploit. They extract the FIDO link from the QR code using a headless browser and redirect the user to the page.
3. Victims PassKey manager pops up for the attacked site. This is done by the website, and since there's no validation of FIDO URLs being popped.
4. The attacker connects to the device user's phone/device via BLE with the session from the first step.
5. The user approves the login attempt.
6. Attacker is now logged in via the user's account.

This attack requires physical access while the victim clicks on a user-controlled link. Since WebAuthn is baked into the browser, it's not possible to get the PassKey information from the website itself. Instead, I believe that the FIDO link is required to be clicked on in order to start the pairing process. Then, by connecting to the attacker's controlled device that has the session on it, we trick them into logging into the wrong website.

To fix this issue, browsers made the FIDO:// URI no longer navigable by a page. Overall, great research into a new form of authentication!