The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on.
Fantastic research by NinjaLab. One of the most interesting parts to me from Yubico's advisory is that the Webauthn protocols attestation [1] is also defeated by this local cloning. Could the protocol have been better designed to resist this local cloning attack?
> An attacker could exploit this issue to create a fraudulent YubiKey using the recovered attestation key. This would produce a valid FIDO attestation statement during the make credential resulting in a bypass of an organization’s authenticator model preference controls for affected YubiKey versions.
> Could the protocol have been better designed to resist this local cloning attack?
I don't see how, the attacker is cloning the secrets used to sign the request, if they have those secrets there's no way of distinguishing the clone from the original device. The whole security model of secure elements is preventing the keys from being extracted, if you can do that there's no more security than saving the key to a file on your computer.
Of course to get the key they need to physically open the device, so unless someone actually takes your key it's more secure than saving them on you computer.
The login service could send not just the request, but also N random bits for the next session.
These would be stored by the device and combined with the next sessions' request data before signing. The login site does it's own combining before checking the signature.
This way any clone usage would be obvious. If the attacker uses the clone before you, your key wouldn't work for that site anymore. The site could even warn you if it keeps track of previous values.
Likewise it limits the timeframe the attacker can use the clone.
I guess even just 16 bits of data should make it quite resistant to guessing by the attacker.
This requires some non-volatile storage to keep the "future bits", but at 16 bits you can do quite a few logins before having to do a single page erase.
Then again, not my field so perhaps there's something I'm missing.
Perhaps some kind of rolling key system could've been used? If the key was rewritten on each successful login, either the attacker would have to use their cloned key immediately (alerting the user), or have their cloned key become useless the moment the user logs in again. This would only work with discoverable credentials, and would increase wear on the device's flash storage.
Not really, unfortunately, given that attestation practically always depends on some piece of secure hardware being able to guard an issuer-certified secret with which it can authenticate itself to a relying party and thereby bootstrap trust into any derived/stored secrets.
If that attestation secret is extractable in any way, nothing prevents an attacker from creating a fake authenticator able to create fraudulent attestations, despite not behaving like an authentic one (i.e. in that it allows extracting stored credentials).
You could theoretically try to mitigate the impact of a single leaked attestation secret by using something like e.g. indirect attestation and authenticator-unique attestation keys (rather than attestation keys shared by hundreds of thousands of authenticators, which is what Yubikey does), but it would be a probabilistic mitigation at best.
> The where operator will validate that the syntax is valid, but it will pass unknown function calls through to the underlying database. In RunReveal's case, we use Clickhouse under the hood, so if we wanted to do a case-insensitive match we could still use Clickhouse's lower function.
From the release blog [1] they mention that unknown functions are passed through to the underlying SQL engine -- this let's them target anything from mysql, Postgres, ClickHouse or proprietary engines like Snowflake.
Shameless self-plug for an alternative tax that affects operational security and reliability teams: https://audit-logs.tax
Understanding how your breach impacts me, or detecting how the abuse of your tools are used to impact our organizations shouldn't cost additional money or be gated to only enterprise contracts.
Regardless of where it's rolled out first, this is a good example of reducing the attack surface from remote exploits (which China is known to have and use at contests like Tianfu Cup). Seems in line with changes they made with "Lockdown Mode" that users can opt into.
The latest and greatest cryptography powering everyone’s favorite SAML-based single-sign on.
reply