آنچه در این مقاله میخوانیم
۳۹ روش جدید برای به خطر انداختن احراز هویت Passkey
Passkeyها با هدف ایجاد روشی امنتر برای ورود به حسابهای کاربری و جایگزینی رمزهای عبور معرفی شدند. این فناوری از رمزنگاری کلید عمومی استفاده میکند و برخلاف رمز عبور، کلید خصوصی کاربر را در اختیار سرور قرار نمیدهد.
همین ویژگی باعث میشود بسیاری از حملات سنتی مانند سرقت رمز عبور، Credential Stuffing و بخش بزرگی از حملات فیشینگ بسیار دشوارتر شوند.
با این حال، تحقیقات امنیتی جدید نشان میدهد مهاجمان برای نفوذ الزاماً نیازی به شکستن رمزنگاری Passkey ندارند.
طبق گزارشی که BleepingComputer منتشر کرده، اکنون دستکم ۳۹ روش، مسیر حمله و سناریوی تحقیقاتی مستندشده وجود دارد که Passkey و زیرساختهای اطراف آن را هدف قرار میدهند.
نکته بسیار مهم این است که وجود این روشها به معنای شکسته شدن FIDO2 نیست. در بسیاری از این حملات، الگوریتم رمزنگاری کاملاً سالم باقی میماند، اما مهاجم با سوءاستفاده از بخشهای دیگر فرایند احراز هویت میتواند حساب کاربری را به خطر بیندازد.
هدف مهاجمان دیگر فقط خود Passkey نیست
فرایند احراز هویت مدرن با Passkey از مجموعه بزرگی از اجزای مورد اعتماد عبور میکند.
مرورگر، سیستمعامل، برنامه، Password Manager، سرویس همگامسازی ابری، تلفن همراه، Bluetooth، سیستم بازیابی حساب، فرایند ثبت Passkey، Help Desk و حتی خود کاربری که درخواست ورود را تأیید میکند، همگی بخشی از این زنجیره هستند.
محققان امنیتی اکنون تقریباً تمام این لایهها را بررسی کردهاند.
روشهایی مانند دستکاری Assertion، گرفتن اطلاعات احراز هویت، تزریق Challenge، Browser Hooking، دستکاری User Verification و User Presence از جمله سناریوهایی هستند که در تحقیقات مختلف مطرح شدهاند.
مهاجم لزوماً به کلید خصوصی نیاز ندارد
یکی از نکات مهم تحقیقات امنیتی این است که بدافزار الزاماً مجبور نیست کلید خصوصی Passkey را از دستگاه استخراج کند.
برای مثال، یک برنامه مخرب روی Windows ممکن است تلاش کند از زیرساخت قانونی WebAuthn برای ایجاد یک Assertion معتبر استفاده کند.
کاربر ممکن است پنجرهای را مشاهده کند که کاملاً شبیه درخواست عادی احراز هویت Windows است و آن را تأیید کند. در این شرایط، مهاجم میتواند از نتیجه فرایند احراز هویت سوءاستفاده کند.
در چنین سناریویی:
کلید خصوصی همچنان در محل امن خود باقی مانده است، رمزنگاری شکسته نشده و FIDO2 نیز از نظر رمزنگاری دچار نقص نشده است؛ اما فرایند احراز هویت مورد سوءاستفاده قرار گرفته است.
حتی پنجره تأیید Passkey میتواند بخشی از سطح حمله باشد
بخشی دیگر از تحقیقات روی رابط کاربری احراز هویت متمرکز شده است.
مهاجمان میتوانند تلاش کنند درخواستهای Passkey را طوری نمایش دهند که کاربر تصور کند با یک درخواست قانونی روبهرو است.
سناریوهای مطرحشده شامل مواردی مانند:
Passkey Prompt Flooding، جعل رابط اطلاعات Credential، جعل Metadata برنامه، Window Handle Spoofing، فیشینگ Passkey از طریق Remote Desktop و Overlay کردن رابط FIDO هستند.
این وضعیت شباهت زیادی به مشکل MFA Fatigue دارد.
زمانی که کاربران مرتباً درخواستهای احراز هویت دریافت میکنند، ممکن است به مرور بدون بررسی دقیق آنها را تأیید کنند.
مقاومت در برابر فیشینگ به معنی مقاومت کامل در برابر فریب کاربر نیست
Passkey در سطح پروتکل رمزنگاری در برابر فیشینگ مقاومت بالایی دارد، اما این ویژگی به این معنی نیست که تمام اجزای سیستمعامل، مرورگر، برنامه و رابط کاربری نیز در برابر مهندسی اجتماعی مصون هستند.
مهاجم ممکن است بهجای حمله مستقیم به رمزنگاری، تلاش کند همان تجربه بصری مورد اعتماد کاربر را جعل یا دستکاری کند.
Passkeyهای قابل همگامسازی سطح حمله را گستردهتر میکنند
Passkeyها میتوانند بین دستگاههای مختلف همگام شوند و این قابلیت از نظر تجربه کاربری بسیار مفید است.
اما هرچه Credential بتواند میان دستگاهها، Password Managerها یا حسابهای Cloud جابهجا شود، اجزای بیشتری وارد مدل امنیتی میشوند.
سناریوهای مورد بررسی محققان شامل مواردی مانند تصاحب Vault همگامشده، نفوذ به Apple Account یا Google Account، سوءاستفاده از Cloud Recovery، سرقت تلفن همراه، Mobile Malware، دستگاههای Root شده، افزونههای مخرب مرورگر و برخی حملات مرتبط با CTAP و Bluetooth است.
مسئله لزوماً ضعف رمزنگاری نیست
این دسته از تهدیدها بیشتر یک مسئله معماری امنیتی محسوب میشوند تا ضعف رمزنگاری.
اگر یک Passkey بتواند:
بین دستگاهها منتقل شود،
از طریق Cloud همگام شود،
از Vault صادر شود،
یا از طریق یک Identity دیگر بازیابی شود،
مرز امنیتی دیگر فقط خود Authenticator نیست.
مهاجم کافی است یکی از اجزای مورد اعتماد این اکوسیستم را به اندازه کافی تحت کنترل بگیرد.
به همین دلیل یک Passkey همگامشده میتواند از رمزنگاری بسیار قدرتمندی استفاده کند اما همچنان تحت تأثیر امنیت تلفن همراه، سیستمعامل، Browser، Password Manager، حساب Cloud و سیستم Recovery قرار داشته باشد.
ثبت Passkey و بازیابی حساب مسیر دیگری برای حمله است
یکی از مهمترین نکات گزارش این است که مهاجم همیشه نیازی به سرقت Passkey موجود ندارد.
گاهی میتواند تلاش کند یک Passkey جدید برای خودش ثبت کند.
سناریوهای مطرحشده در تحقیقات شامل Shadow Passkeys، Enrollment Vishing، ثبت تلفن تحت کنترل مهاجم، ثبت Passkey توسط مهاجم، سوءاستفاده از Help Desk، سوءاستفاده از Credential موقت، SIM-Based Recovery و Reverse Vishing هستند.
Shadow Passkey چیست؟
فرض کنید مهاجم به اندازهای به حساب یک کارمند دسترسی پیدا کند که بتواند فرایند قانونی ثبت Passkey جدید را آغاز کند.
مهاجم بهجای سرقت Credential فعلی کاربر، Passkey جدیدی را روی دستگاهی که خودش کنترل میکند ثبت میکند.
در چنین شرایطی سرویس اصلی، یک Credential کاملاً معتبر برای مهاجم ایجاد کرده است.
در واقع چیزی از Authenticator اصلی شکسته یا استخراج نشده است.
همین مسئله نشان میدهد که امنیت Passkey فقط به مرحله Login محدود نمیشود.
Enrollment، Replacement، Recovery و Device Registration نیز باید با همان سطح امنیت محافظت شوند.
سختافزارهای اختصاصی احراز هویت میتوانند سطح حمله را کاهش دهند
یکی از راهکارهایی که مقاله بر آن تأکید میکند، استفاده از Authenticatorهای سختافزاری اختصاصی برای محیطهای سازمانی حساس است.
در چنین معماریای، Credential خصوصی میتواند داخل سختافزار امن باقی بماند و قابلیتهایی مانند Cloud Sync یا Export برای آن وجود نداشته باشد.
همچنین میتوان احراز هویت را به عواملی مانند حضور فیزیکی کاربر و تأیید Biometric روی خود دستگاه وابسته کرد.
چرا دستگاه اختصاصی میتواند امنتر باشد؟
یک Authenticator اختصاصی برخلاف تلفن یا کامپیوتر معمولی الزاماً دارای:
سیستمعامل عمومی،
App Store،
Browser،
افزونههای شخص ثالث،
و مجموعه بزرگی از برنامهها و سرویسهای Background نیست.
بنابراین مهاجم گزینههای کمتری برای نصب برنامه مخرب، دستکاری Browser، نمایش رابط جعلی یا آلوده کردن سیستم در اختیار دارد.
این معماری سطح حمله را به میزان قابل توجهی محدود میکند.
البته سختافزار اختصاصی به تنهایی کافی نیست و نحوه پیکربندی سرویس مقصد نیز نقش اساسی دارد.
پیکربندی صحیح سرویس بسیار مهم است
برای محیطهای سازمانی حساس، سازمانها باید مشخص کنند چه Authenticatorهایی اجازه ثبت و استفاده دارند.
سرویس باید مواردی مانند هویت Authenticator، User Verification، اعتبار Challenge و Session را بهدرستی بررسی کند.
همچنین نباید یک روش احراز هویت ضعیفتر به عنوان مسیر پشتیبان در اختیار مهاجم قرار گیرد.
Recovery نباید نقطه ضعف Passkey باشد
اگر یک سازمان از Passkey بسیار امن استفاده کند اما مهاجم بتواند فقط با یک تماس تلفنی با Help Desk، یک SMS یا فرایند Recovery ضعیف آن را دور بزند، مزیت اصلی Passkey کاهش پیدا میکند.
ثبت Authenticator جدید در محیطهای حساس بهتر است نیازمند اثبات دسترسی به یک Authenticator از قبل تأییدشده باشد، نه صرفاً دسترسی به یک کانال Recovery ضعیفتر.
این ۳۹ روش حمله در واقع چه چیزی را نشان میدهند؟
وجود ۳۹ روش تحقیقاتی و سناریوی حمله به معنی شکست FIDO2 نیست.
اتفاقاً بسیاری از این تحقیقات نشان میدهند حمله مستقیم به رمزنگاری درست پیادهسازیشده FIDO2 کار بسیار دشواری است.
به همین دلیل محققان و مهاجمان بیشتر روی محیط اطراف Credential تمرکز میکنند:
سیستمعامل،
مرورگر،
Cloud Sync،
Password Manager،
فرایند Enrollment،
Account Recovery،
Help Desk،
برنامهها
و در نهایت خود کاربر.
Passkey همچنان یکی از مهمترین جایگزینهای رمز عبور است
Passkey بخش بزرگی از مشکلات امنیتی مرتبط با Password را حل میکند و FIDO Alliance نیز آن را یک روش احراز هویت مقاوم در برابر فیشینگ معرفی میکند.
اما برای سازمانهایی که حسابهای بسیار حساس، Administratorها یا کاربران دارای دسترسی Privileged دارند، تنها فعال کردن Passkey پایان کار نیست.
سازمان باید تمام چرخه هویت را از ثبت Credential تا Login، Recovery و Replacement بهعنوان بخشی از مدل امنیتی در نظر بگیرد.
تحقیقات جدید درباره ۳۹ مسیر حمله مرتبط با Passkey یک پیام مهم برای مدیران امنیت دارد:
مهاجم برای تصاحب حساب الزاماً نیازی به شکستن FIDO2 یا سرقت کلید خصوصی ندارد.
گاهی یک Browser آلوده، سیستمعامل تحت کنترل مهاجم، Password Manager آسیبپذیر، حساب Cloud تصاحبشده، فرایند Recovery ضعیف یا حتی یک کاربر فریبخورده برای دور زدن مدل امنیتی کافی است.
بنابراین امنیت واقعی Passkey زمانی حاصل میشود که علاوه بر خود Credential، تمام زیرساخت اطراف آن نیز بهدرستی طراحی، پیکربندی و محافظت شود.
