Okta Terrify – Exposing Vulnerabilities In Passwordless Authentication

This tools was released as part of my BSides Cymru 2024 talk, Okta Terrify: Persistence in a Passwordless World.

The presentation deck and demonstration video have been included with this repository.

Okta Terrify is a tool to demonstrate how passwordless solutions such as Okta Verify’s FastPass or other FIDO2/WebAuthn type solutions can be abused once an authenticator endpoint has been compromised.

Whilst Okta Terrify demonstrates Okta specific attacks, the same methodology would typically apply to other passwordless solutions, as generally they all leverage asymmetric cryptography.

Passwordless Authentication

Passwordless authentication works via public/private key pairs.

Typically, there are two types of keys generated during authenticator enrollment, Proof Of Possession and User Verification. Combined, both keys satisfy the multifactor element of authentication that organisations strive for as part of ongoing efforts to protect their users.

Proof Of Possession

The proof of possession key is designed to do just that, prove that presence of a specific authenticator and/or user during authentication.

In Okta’s case, the the proof of possession key is used to determine the presence of both the authenticator and the user, since in multiuser scenarios, unique proof of possession keys are generated per user.

The proof of possession key is typically a silent key, which does not require any form of biometric data to unlock it’s usage beyond that of the operating system itsself, such as an authenticated Windows user session.

When available, this key will be backed by a TPM and is therefore not possible to export from the device. When a TPM is not available, this key is generated as a software only key.

User Verification

The user verification key also provides proof of possession, but additionally verifies that the user is indeed aware that authentication is taking place.

This is achieved through biometric data, often a fingerprint or facial recognition but is also backed up by a PIN.

On Windows based devices, this is typically implemented by using Windows Hello. Signing operations will not work without the correct biometric data provided.

Some passwordless solutions will use just the user verification key to satisfy both factors. The drawback of this approach is that every signing operation will require the users biometric data.

In Okta’s case for the example, the proof of possession key can be used as a distinct factor during authentication along with a septate factor such as the users password.

Again, this key is either backed by a TPM when available or generated in software if not.

Okta

Ok, enough of this background on passwordless, lets get to the good stuff.

Whilst the same concepts exist across all supported Okta Verify devices, from here on we will be discussing how the Windows version of Okta Verify functions.

Okta stores authenticator information inside an encrypted SQLite database.

There are two different database version, the legacy version stored inside a filed called OVStore.db which uses the users SID as the basis of the encryption key passed through a custom XOR algorithm and a fixed key.

The newer version is called DataStore.db and uses a random value that is stored in credential manager.

This credential is passed through a similar XOR algorithm as the legacy format. The database is stored at %LocalAppData%\Okta\OktaVerify\.

The database contains the generated key ids for both the proof of possession and user verification key which are generated during device enrollment.

The database also contains other useful metadata, like device, user and authenticator IDs along with the Okta tenant URL for the registered accounts.

Okta Terrify is split into two distinct components. Okta Terrify and OktaInk.

Okta Terrify

Okta Terrify is designed to run on the attackers machine. The tool requires the users SID and a database file with legacy database format and for the newer format, the database key.

For the newer format, the database key can be generated using OktaInk. Okta Terrify has 4 operating modes controlled through various switches.

Info

The --info mode simply dumps information contained within the database.

Example

Legacy Database

OktaTerrify.exe --info -s S-1-5-21-*******-1001 --db C:\Users\Tester\AppData\Local\Okta\OktaVerify\OVStore.db
2023-11-21 11:49:56.2243|INFO|OktaTerrify|Okta Terrify is starting....
C:\Users\Tester\AppData\Local\Okta\OktaVerify\OVStore.db

Database Encryption Key: 3a9d6ad1643f2608479c976f1a2ebcb98c115c379d8dfaa2bb6ab2c65c286250
User Id: 00u8*******
Client Instance Id: cli*******
Device Id: guo9**********
Authenticator Url: https://tenant.okta.com/api/v1/authenticators/aut*****
Method Enrollment Id: crp*****
Device Enrollment Id: pfd*****
Sandbox Account Name: None
Keys:
  Id: SFT_********, Sandboxed: No, Type ProofOfPossession
  Id: BOL_********, Sandboxed: No, Type UserVerification
  Id: SFT_********, Sandboxed: No, Type DeviceAttestation

For more information click here.