okta-terrify: Okta Verify and Okta FastPass Abuse Tool
okta-terrify
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.
This tools was released as part of my BSides Cymru 2024 talk, Okta Terrify: Persistence in a Passwordless World.
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.
Backdoor
In --backdoor mode, Okta Terrify will launch the tenant Okta URL using the OAuth client id that the official Okta Verify application uses during enrollment. This will typically trigger the authentication flow and signing mode is active during this phase. Once an authenticated session is created, a new user verification key is generated on the attacking device and is enrolled as a fake biometric key. Once the key is enrolled, FastPass will operate in a passwordless state without any dependencies on the original compromised authenticator device.
Sign
In --sign mode, during Okta authentication, challenges are either signed locally through exfiltrated keys or they can be proxied to OktaInk running on a compromised authenticator when hardware backed keys are present.
Import
The --import mode will save software defined proof of possession and user verification keys that have been extracted using Okta Ink.
Okta Ink
Okta Ink is designed to run on the compromised authenticator device. The application supports 4 types of operations.
Generate DB Key
For the newer database format, the --operation DumpDBKey can be used to dump the database key for the DataStore.db file. The key can then be used as a parameter for OkaInk.
JWT Sign
During the Okta authentication flow a challenge response JWT is generated to prove that either the proof of presence or user verification key is available. The --operation SignDeviceBind mode can be used to sign the generated JWT with the proof of possession key, which is silent. If you want to perform passwordless authentication, you can also sign with the user verification key by adding the -v argument. WARNING – When requesting the user verification key, the victim user will be required to perform biometric validation and therefore could raise suspicion.
Attestation Sign
Okta Verify also enrolls a device attestation key, which is a silent key. This key appears to be used when changes are being made to the registered authenticator device via web API calls against the Okta tenant. But it seems by default device attestation is not enforced, therefore signing is not required. Regardless, this mode can be leveraged via the --operation SignDeviceAttestation arguments.
Private Key Export
For devices that do not support a TPM, the --operation ExportPrivate command line can be use to export all keys registered on the device. Proof of possession keys are tied to the users DPAPI key and therefore the users password must be known.
Public Key Export
During the backdoor enrolment process, we need to ensure that the existing public keys are retained within the tenant authenticator data. --operation ExportPublic facilitates this by exporting the public key associated with a specific key id.
