فهرست مطالب
در حال حاضر، دستکم ۳۹ روش مستندشده عمومی برای دور زدن احراز هویت با پسکی، مسیر حمله، تکنیک پژوهشی و سناریوی بهرهبرداری از آن وجود دارد.
به گزارش سرویس امنیت سایبری تکناک، پسکی در ابتدا با یک وعده امنیت بالا معرفی شد؛ جایگزینی گذرواژهها با رمزنگاری کلید عمومی، اتصال اعتبارنامه به سرویس قانونی، نگهداری کلید خصوصی خارج از سرور و در نتیجه دشوارتر شدن چشمگیر طیف وسیعی از حملات فیشینگ و سرقت اعتبارنامه که برای دههها امنیت سازمانی را تهدید کردهاند. تمام این گزارهها همچنان درست هستند، اما مدل گفتوگو درباره امنیت پسکی با سرعت زیادی در حال تغییر است.
بسیاری از روشها برای دور زدن احراز هویت با پسکی به ابزارهای اثبات مفهوم عملیاتی یا پژوهشهای منتشرشدهای مجهز هستند که نحوه اجرای دقیق آنها را نشان میدهد و برخی نیز در الگوهای حملات دنیای واقعی مشاهده شدهاند.
این مسئله به معنای عملیاتی شدن هر ۳۹ روش توسط مجرمان نیست، اما نشان میدهد چارچوب حملات به صورت عمومی در حال تدوین است و مهاجمان دیگر نیازی ندارند این تکنیکها را از ابتدا توسعه دهند. مهمتر از آن، این تحقیقات یک تمایز بنیادی را برای سازمانها آشکار میکنند: حتی اگر رمزنگاری داخلی FIDO2 کاملا سالم باقی بماند، امنیت حساب کاربری که پسکی از آن محافظت میکند همچنان ممکن است به خطر بیفتد.
بیشتر بخوانید: کدام شرکتها از احراز هویت مبتنی بر پسکی پشتیبانی نمی کنند؟
هدف دیگر فقط خود پسکی نیست
مسیر احراز هویت مدرن با پسکی از تعداد قابل توجهی مرز اعتماد عبور میکند. این زنجیره میتواند برنامه وب، مرورگر، سیستمعامل، مدیر گذرواژه، سرویس همگامسازی ابری، دستگاه همراه، لایه انتقال بلوتوث، سامانه بازیابی حساب، فرایند ثبتنام، واحد پشتیبانی و در نهایت کاربری را دربر بگیرد که احراز هویت را تایید میکند. SpecterOps در پژوهش Pass the Passkey اهمیت این مشکل را بهخوبی نشان داده است. یکی از مهمترین مشاهدات این پژوهش آن است که بدافزار نیازی به استخراج کلید خصوصی ندارد. یک برنامه مخرب ویندوزی میتواند از زیرساخت قانونی WebAuthn درخواست تولید یک Assertion امضاشده کند. کاربر با رابطی مواجه میشود که همان فرایند احراز هویت قانونی ویندوز است، مراحل تایید هویت را انجام میدهد و در نهایت مهاجم Assertion تولیدشده را دریافت میکند. کلید خصوصی هرگز از محل امن خود خارج نشده است. هیچکس رمزنگاری را درهم نشکسته است، اما فرایند احراز هویت با موفقیت مورد دستکاری قرار گرفته است. درک همین تمایز برای شناخت مدل تهدید و امنیت پسکی حیاتی است.
حتی اعلان پسکی نیز مورد هدف قرار میگیرد
چندین مورد از ۳۹ تکنیک مستندشده، رابط کاربری پیرامون فرایند احراز هویت با پسکی را هدف میگیرند. پژوهشگران تاکنون تکنیکهایی از جمله بمباران اعلان پسکی، فریب رابط اعتبارنامه، جعل فراداده برنامه، جعل Window Handle، فیشینگ پسکی از طریق Remote Desktop و حملات Overlay روی رابط FIDO را به نمایش گذاشتهاند. این وضعیت یادآور مشکلی است که صنعت امنیت پیشتر در ارتباط با احراز هویت چندمرحلهای مبتنی بر Push با آن مواجه شده بود. کاربران به اعلانهای احراز هویت عادت میکنند و هنگامی که احراز هویت به یک تعامل بصری و روزمره تبدیل شود، مهاجمان میتوانند این تعاملات را ایجاد، تکرار، پنهانسازی یا با زمانبندی هدفمند اجرا کنند.

SpecterOps ابزاری را به نمایش گذاشته که قادر است اعلانهای قانونینما را برای احراز هویت پسکی در ویندوز بهطور مکرر فراخوانی کند. همچنین پژوهشگران تکنیکهایی را نشان دادهاند که فعالیت مخرب احراز هویت را به شکلی نمایش میدهند که گویی منشأ آن برنامهای است که کارمند از قبل به آن اعتماد دارد. نکته کلیدی این است که مقاومت در برابر فیشینگ در سطح پروتکل رمزنگاری، بهتنهایی تضمین نمیکند که کل زنجیره پیرامون آن پروتکل، از جمله سیستمعامل، مرورگر، برنامه و رابط کاربری، در برابر فریب مقاوم باشد.
پسکی قابل اشتراک، سطح حمله را گسترش میدهد
قابلیت اشتراکگذاری، همگامسازی، Export، بازیابی یا انتقال پسکی میان دستگاهها باعث میشود سطح حمله به شکل چشمگیری گسترش پیدا کند. فهرست حملات مستندشده اکنون مواردی مانند بهخطر افتادن Vaultهای همگامشده، تصاحب حسابهای اپل یا گوگل، تصاحب سازوکار بازیابی ابری، سرقت یا بهخطر افتادن گوشی، بدافزار موبایلی، دستگاههای روتشده، دستکاری احراز هویت ترکیبی، سرقت Exportهای KeePassXC و Bitwarden، سرقت هنگام تبادل اعتبارنامه، افزونههای مخرب مرورگر و حملات مرتبط با ارتباطات CTAP و بلوتوث را دربر میگیرد. این مسئله در اصل یک مشکل رمزنگاری نیست، بلکه یک مشکل معماری است.
هنگامی که یک اعتبارنامه بتواند بین دستگاهها جابهجا شود، از طریق یک حساب ابری همگامسازی شود، از Vault خارج شود، با استفاده از هویتی دیگر بازیابی شود یا از طریق سازوکاری دیگر Restore شود، مرز امنیتی آن بسیار فراتر از Authenticator اولیه گسترش مییابد. در این شرایط، مهاجم دیگر نیازی به شکست FIDO2 ندارد؛ کافی است یکی از اجزای بهاندازه کافی مورد اعتماد در اکوسیستم پیرامونی را به خطر بیندازد. بنابراین یک پسکی همگامشده میتواند از رمزنگاری بسیار قدرتمندی بهره ببرد، اما همچنان ضعفهای گوشی، سیستمعامل، Password Manager، حساب ابری، مرورگر، فرایند ریکاوری و زیرساخت Synchronization مسئول مدیریت آن را به ارث ببرد.
ثبتنام و بازیابی امنیت پسکی را بهخطر میندازد
برخی از مهمترین حملات حتی برای سرقت پسکی موجود طراحی نشدهاند؛ مهاجم یک پسکی جدید ایجاد میکند. تکنیکهای منتشرشده شامل Shadow Passkey، Vishing در فرایند Enrollment، ثبت دستگاه مهاجم، ثبت پسکی تحت کنترل مهاجم، تصاحب Help Desk، سوءاستفاده از Credential موقت، ریکاوری مبتنی بر سیمکارت، Reverse Vishing و حملات مبتنی بر Pretext در فرایند Migration هستند.
فرض کنید مهاجم کنترل کافی بر حساب یک کارمند به دست آورد تا بتواند فرایند قانونی ثبت یک پسکی جدید را آغاز کند. در این سناریو، مهاجم بهجای استخراج Credential موجود کارمند، یک Credential کاملا جدید را روی دستگاهی که تحت کنترل خود او قرار دارد ثبت میکند. هیچ چیزی شکسته نشده و چیزی نیز از Authenticator موجود سرقت نشده است. خود سرویس قانونی، یک Credential کاملا معتبر برای مهاجم ایجاد میکند. این مسئله به یک اصل فزاینده مهم در حوزه هویت منجر میشود: احراز هویت مقاوم در برابر فیشینگ، زمانی کافی نیست که Enrollment، Replacement، ریکاوری و Device Registration با همان استاندارد امنیتی محافظت نشوند.
برای مطالعه بیشتر: پسکی جایگزین رمز عبور و تایید هویت پیامکی در ویندوز ۱۱ می شود
سختافزار بیومتریک اختصاصی برای احراز هویت با پسکی
راهکارهای مبتنی بر سختافزار بیومتریک اختصاصی، رویکرد کاملا متفاوتی با پسکی ذخیرهشده روی دستگاههای همهمنظوره دارند. یک Authenticator بیومتریک اختصاصی میتواند Credential خصوصی را درون سختافزار امن خود بدون همگامسازی ابری، بدون مکانیزم Export و بدون وابستگی به Password Manager برای جابهجایی Credential میان دستگاهها نگه دارد. احراز هویت میتواند علاوه بر حضور فیزیکی Authenticator در نزدیکی Endpoint درخواستکننده، به یک اثر انگشت زنده روی خود Authenticator نیز نیاز داشته باشد. مهمتر اینکه یک Authenticator اختصاصی نیازی به سیستمعامل سنتی همهمنظوره، فروشگاه برنامه، مرورگر یا نمایشگر ندارد. همین تمایز بخش بسیار بزرگی از سطح حمله را حذف میکند.

هیچ برنامه شخص ثالثی وجود ندارد که مهاجم بتواند آن را با نسخهای مخرب جایگزین کند. اکوسیستم افزونههای مرورگر برای نفوذ وجود ندارد و هیچ نمایشگری وجود ندارد که بدافزار بتواند روی آن یک رابط احراز هویت فریبنده نمایش دهد. همچنین خبری از یک سیستمعامل مصرفی مملو از برنامههای نامرتبط، مجوزها، سرویسهای پسزمینه و وابستگیهای مختلف به Update نیست. Authenticator تنها مجموعه بسیار محدودی از عملکردهای مشخص امنیتی را اجرا میکند و هیچ وظیفه دیگری ندارد.
این معماری اقتصاد حمله به دستگاه را بهطور بنیادین تغییر میدهد. مهاجم بهجای تلاش برای نفوذ به یک محیط محاسباتی همهمنظوره و گسترده، با یک دستگاه سختافزاری بهشدت کنترلشده مواجه است که برای حفاظت از Credentialهای رمزنگاریشده و احراز هویت بیومتریک طراحی شده است. همچنین این معماری فرایند احراز هویت با پسکی را در برابر Manipulation کارمند مقاومتر میکند. یک کارمند ممکن است با مهندسی اجتماعی متقاعد شود به وبسایتی مراجعه کند، به یک تماس تلفنی پاسخ دهد یا دستورهای فردی را دنبال کند که خود را پشتیبان فنی معرفی میکن،؛ اما مهندسی اجتماعی نمیتواند یک برنامه سرکش را روی سختافزاری نصب کند که برنامههای معمول را اجرا نمیکند. همچنین نمیتواند نمایشگری را که وجود ندارد دستکاری کند یا Credential را از طریق سرویس ابری Synchronize دستکاری کند که Authenticator از آن استفاده نمیکند. از این منظر، سختافزار بیومتریک اختصاصی که بهدرستی طراحی شده باشد، امنیت پسکی را بالا میبرد.
پیکربندی صحیح برای امنیت احراز هویت با پسکی
سختافزار اختصاصی بهتنهایی کافی نیست. سرویس Relying Party نیز باید بهگونهای پیکربندی شود که مدل امنیتی مورد نظر حفظ شود. در محیطهای سازمانی حساس، Authentication و Enrollment باید به کلاسهای تاییدشده Authenticator محدود شوند. Relying Party باید هویت Authenticator را اعتبارسنجی کند، User Verification را اجباری سازد، Challengeها و Sessionها را بهدرستی اعتبارسنجی کند، از سازوکارهای مناسب برای محافظت از Signature Counter استفاده کند و مانع تبدیل روشهای ضعیفتر به مسیرهای Fallback برای احراز هویت شود. Enrollment و ریکاوری به توجه ویژهای نیاز دارند. افزودن Authenticator جدید باید به اثبات مالکیت از طریق یک Authenticator از پیش مجاز نیاز داشته باشد، نه اینکه کنترل حساب از طریق یک کانال ریکاوری ضعیفتر اثبات شود.
در صورت پیکربندی صحیح، این معماری مانع از آن میشود که مهاجم با استفاده از یک لپتاپ، گوشی، Software Vault یا Security Key دیگر، امنیت پسکی را بهخطر بیندازد. تصاحب حساب ابری نیز Credential را در اختیار مهاجم قرار نمیدهد. بهخطر افتادن Password Manager نیز آن را افشا نمیکند و بدافزار موبایلی قادر به آلوده کردن Authenticator نخواهد بود. یک برنامه مخرب نمیتواند روی آن نصب شود و مهاجم راه دور نیز نمیتواند ترکیب مورد نیاز از سختافزار اختصاصی، تأیید بیومتریک، حضور فیزیکی و تعامل قانونی با سرویس را برای احراز هویت جعل کند.
حتما بخوانید: گوگل امکان جابهجایی پسکی بین اپلیکیشنها را به اندروید میآورد
۳۹ روش چه چیزی به ما میگویند؟
وجود ۳۹ روش حمله منتشرشده برای احراز هویت با پسکی به این معنا نیست که رمزنگاری FIDO2 شکست خورده است؛ در بسیاری از جهات، این مسئله حتی خلاف آن را نشان میدهد. پژوهشگران بارها نرمافزار، سامانههای Synchronization، فرایندهای Enrollment، سیستمعاملها، مرورگرها، مکانیزمهای ریکاوری و انسانهای پیرامون Credential را هدف قرار میدهند، زیرا شکست مستقیم سختافزار رمزنگاریشدهای که بهدرستی پیادهسازی شده باشد، بهمراتب دشوارتر است. این موضوع باید به مدیران امنیتی نشان دهد که مرز بعدی امنیت پسکی باید در کجا قرار گیرد.
برای هویتهای سازمانی با ارزش بالا، Credentialها نباید به صورت آزادانه میان دستگاههای مصرفی و اکوسیستمهای ابری قابل اشتراک باشند. این Credentialها باید به سختافزار بیومتریک اختصاصی، فرد احراز هویتشده، سرویس قانونی و فرایند Enrollment و ریکاوری تحت کنترل سازمان Bind شوند. پسکی بخش بزرگی از مشکل امنیت گذرواژه را حل میکند، اما ۳۹ حمله منتشرشده نشان میدهند مهاجمان اکنون چه نقاطی را هدف قرار میدهند. سختافزار بیومتریک اختصاصی که از مرحله Enrollment تا Authentication و ریکاوری بهدرستی پیادهسازی شود، تقریبا تمام سطح حمله پیرامونی را حذف میکند پیش از آنکه مهاجم فرصتی برای بهرهبرداری از آن پیدا کند.
















