When a clickjack attack managed to hijack a passkey authentication ceremony, were password managers really to blame? ZDNET's investigation reveals a more complicated answer.
Vertigo3d/iStock/Getty Images Plus via Getty Images • A researcher developed an exploit that hijacks passkey authentication.
• The exploit depends on a non-trivial combination of pre-existing conditions.
• Neither the passkeys nor the protocol was proven to be vulnerable.
At this year's DEF CON conference in Las Vegas, white hat security researcher Marek Tóth demonstrated how threat actors could use a clickjack attack to surreptitiously trigger and hijack a passkey-based authentication ceremony.
In the big picture, this is a story about how password managers could be tricked into divulging login information -- either traditional credentials such as user IDs and passwords or credential-like artifacts associated with passkeys -- to threat actors.
Are password managers to blame? Tóth -- the researcher who discovered the exploit -- suggests that they are, but the answer is more complicated.
Fully locking down any automated process is invariably the result of security in layers. Across the grand majority of use cases where digital security matters, there's almost never a single silver bullet that wards off hackers. Depending on the layers of technology that combine to complete a workflow (for example, logging into a website), responsibility for the security of that process is shared by the parties that control each of those layers.
Yes, the password managers are one layer in stopping the exploit. But website operators and end-users -- the parties in control of the other layers -- must trade too much security for convenience in order for the exploit to work. Pointing fingers is useless. All parties at every layer must take action.
The big ideas behind passkeysEvery summer, the cybersecurity industry gathers in Las Vegas for the back-to-back Black Hat and DEF CON conferences, where security researchers take turns presenting their "big reveals." During the year leading up to the event, these researchers work to discover new, unreported vulnerabilities. The bigger the vulnerability and the more users affected, the greater the attention (and possibly the financial reward) that awaits a researcher.
This year, several researchers announced a handful of issues that challenged the supposed superiority of passkeys as a login credential.
Here on ZDNET, I've been writing a lot about passkeys and why, from the security and technical perspective, they're immensely better than user IDs and passwords (even when additional factors of authentication are involved).
The three big ideas behind passkeys are:
1. They cannot be guessed in the way passwords often can (and are).
2. The same passkey cannot be reused across different websites and apps (the way passwords can).
3. You cannot be tricked into divulging your passkeys to malicious actors (the way passwords can).
Marek Tóth discovered a way -- under a combination of very specific
technical preconditions -- to hijack passkey-based authentications
while those authentications are in progress. Marek TóthUnfortunately, despite their superiority, the passkey user experience varies so wildly from one website and app (collectively, "relying parties") to the next that passkeys risk being globally rejected by users. Despite these barriers to adoption, and in the name of doing the most to protect yourself (often from yourself), my recommendation continues to be: Take advantage of passkeys whenever possible.
In the interest of delivering sound advice to ZDNET's readers, I always double-check the veracity of any headlines that challenge the viability and superior security of passkeys. Various reports emerged from this year's Black Hat and DEF CON, citing potential trouble in passkey paradise. The one that got the most attention came from Tóth, who -- under a combination of very specific technical preconditions -- has discovered a way to hijack passkey-based authentications while those authentications are in progress.
My research involved lengthy communications with Tóth, officials from the FIDO Alliance (the organization responsible for the development and promotion of the passkey standard), a developer of a turnkey plug-in that enables websites for passkey-based authentication, and vendors of various password managers. Why the password managers? From the end-user's perspective, it's impossible to engage in passkey-based authentication -- technically known as an "authentication ceremony" -- without the assistance of a password manager. They play a key role in Tóth's findings.
As for the FIDO2 Credential passkey specification itself, Tóth told me, "The protocol itself is probably secure. I haven't tested it extensively, as it wasn't the focus of my research." In other words, he is not suggesting that passkeys themselves are insecure. In fact, Tóth's research covers user IDs and passwords, too, and his findings essentially prove that those traditional credentials are far more exploitable than properly configured passkeys ever will be.
However, through a combination of sloppy website management and user indifference when it comes to securely configuring their password managers, there exists a previously undisclosed opportunity for malicious actors to hijack a passkey-based authentication ceremony while it's in progress. This is true even though passkeys themselves cannot be stolen.
Instead of pointing his finger at the FIDO2 specification or careless website operators, Tóth primarily blames the password managers, who, in his opinion, could have done more to protect the user from his exploit.
"No, it's not only the website operator's fault," Tóth wrote to me via email. "But also the password manager vendors, since the vulnerability is in their software." In a tweet where Tóth summarizes some of his findings, he calls out 12 password managers (including all the popular ones) by name as being vulnerable to one extent or another.
Whether or not the various password managers are indeed vulnerable depends on your definition of "vulnerability." None of the password management vendors that I contacted agreed with the assertion that their password manager had a vulnerability.
However, given the aggressive browser permissions that users must grant to their password managers at the time of installation (the same permissions that make it possible for a password manager to prevent rogue usage of unsanctioned SaaS apps), password managers are in a unique position to detect and prevent this and other threats before damage is done.
Not surprisingly, some of the password managers are releasing new versions to address Tóth's exploit.
The heart of the attackAlthough the exploit happens in the blink of an eye, it involves a complicated set of interactions and preconditions that, taken together, present a series of non-trivial obstacles to the attacker's chances of success. At its heart, Toth's exploit never steals a user's passkey (one of the core tenets of passkeys is that they can't be stolen). But it essentially steals the next best thing.
At the moment that a user is tricked into inadvertently authenticating to a website with a passkey, the exploit intercepts a payload of information that was manufactured by the user's password manager with the help of his or her passkey to that site. As described in part 5 of my series on How Passkeys Actually Work, this payload is called the PublicKeyCredential, and it's like a one-time single-use golden ticket that contains everything necessary for the user to log into their account on the legitimate website. Once the attacker gains possession of this golden ticket, it can be used to log the attacker's system into the victim's account as though the attacker's system is the victim's system.
And that's exactly what this exploit does.
After loading malware into the victim's browser, the exploit -- a malicious cross-site script (XSS) -- intercepts that golden ticket and, instead of presenting it for entry into the legitimate site (as the user's browser typically does at the request of the password manager), it sends it to the attacker's website. Then, with that golden ticket in hand, the attacker submits that same ticket from their own system to the legitimate website, effectively logging the attacker's system into the user's account on the legitimate website.
But, as mentioned earlier, Tóth's discovery relies on the pre-existence of several conditions involving the website in question, the user's choice of password manager, how they have that password manager configured, and the website operator's choice of technology for adding the ability to authenticate with a passkey. Whether you're an end-user, the operator of a website, or the vendor of a password manager, it's important to understand these conditions because, once you do, you'll also understand the defense. You can also judge for yourself who among the involved parties is most responsible for the vulnerability.
While Tóth points his finger at the password managers, I believe that the website operator would be mostly to blame if an actual threat actor used this exploit in the wild. Setting aside for a moment the challenge of getting the victim to encounter the malware (a malicious cross-site JavaScript that runs in the victim's browser), there are two settings that foil the attack that every professional website operator should know about.
There comes a moment during the passkey authentication ceremony -- once the user has indicated the desire to log in with a passkey -- when the website responds to the user with a challenge as a part of a larger payload called the PublicKeyCredentialRequestOptions. Like every response from a web server, that response also includes several parameters known as HTTP headers, one of which can be used to establish a specific communication session with the client system using a uniquely coded cookie, and then to configure that cookie as an HttpOnly cookie.
A simplified version of that header parameter -- known as the set-cookie parameter -- might look something like this (as a part of a larger transmission from the web server to the user's browser):
Set-Cookie: session_id=123456789abcdefg; HttpOnly
When a web server is configured to include a header like this during a user's attempt to authenticate with a passkey, it permanently glues the challenge (and the rest of the conversation between the user's browser and web server) to the specified session ID. Once a challenge is bound to a specific session ID, the server will only honor a golden ticket that's packaged with that same ID. For Tóth's exploit to work, the attacker's system must not only take possession of the intercepted golden ticket, but it must also know the exact session ID to use when presenting that ticket to the legitimate web server.
This is where the HttpOnly parameter comes into play. When the set-cookie header includes this parameter (as shown above), it's like a magical invisibility cloak. The session ID becomes invisible to any JavaScript -- legitimate or malicious -- that might be running in the user's browser. As a result, if that JavaScript happens to be malicious, it can't do what Tóth's exploit does; it can't discover the session ID, nor can it include it with the intercepted golden ticket that it forwards to the attacker's system. So, even if the malicious JavaScript forwards the intercepted golden ticket to the attacker's system, it would be useless to the attacker without the missing session ID.
For eons, this "session-binding" of an authentication conversation (passkey-related or not) between a website and the end-user's browser has been considered the primary line of defense against such an attack. A website operator's failure to lock its authentication processes down with this simple, well-known best practice would be viewed by most cybersecurity professionals as highly negligent.
Plenty of blame to go aroundBut in my interviews with Tóth, he also blames two other groups: the solution providers that sell the plug-ins used by relying parties to add passkey support to their websites, and the FIDO Alliance, the organization responsible for the development, promotion, and adoption of passkeys.
In his research, Tóth noted that, of the seven plug-in solutions he tested, four "did not implement 'session-bound challenge,' [thus] making this attack exploitable." In other words, if a website operator installed one of those four libraries (from Hanko, SK Telecom, NokNok, or Authsignal) and left them in their default state, it would be the equivalent of disregarding the best practice.
Tóth was also incredulous that the FIDO Alliance included those four solutions in its online showcase of FIDO-certified solutions. In Tóth's opinion, flaunting the widely known best practice and defaulting to non-session-bound challenges should disqualify a plug-in from FIDO's certification. The FIDO Alliance disagrees.
FIDO Alliance CTO Nishant Kaushik told me:
"Regarding the four companies you pointed out as not using session binding, it's worth noting that the researcher tested demo sites that these companies leverage to showcase the user experience that their products provide. Demo sites would not typically be hardened in the same manner as an actual implementation."
Kaushik went on to talk about the criticality of session binding, saying that the FIDO Alliance-operated passkeycentral.org includes a post demonstrating that "the FIDO Alliance [has been] clear that session-binding is 'essential' to prevent session hijacking." However, the article refers to cryptographic session-binding techniques such as Device Bound Session Credentials (DBSC) and Demonstrating Proof of Possession (DPoP), and fails to suggest the far simpler and widely publicized best practice of session-binding with the set cookie header.
Additionally, whereas the FIDO Alliance defended its certifications, essentially claiming that no one would realistically deploy the plug-ins in the manner that Tóth did, the CEO of one of those plug-ins struck a far more genuine, conciliatory and culpable tone in a way that called the accuracy of Kaushik's response into question.
"We're aware of the issue and our team is actively working on a fix," said Hanko.io CEO Felix Magedanz. "The passkey implementation is one of the earliest components of Hanko. While we have since added functionality such as sessions and user management, a gap remained in how WebAuthn flows were bound to user sessions. We're treating this with the highest priority and will release an updated version of Hanko very soon."
While fixes come from Hanko.io (and maybe the others), it's abundantly clear that the onus is on relying parties to implement session binding responsibly to better protect their end-users.
source
