گزارش Unit 42 نشان میدهد بدافزاری که روی ویندوز اجرا میشود، میتواند بدون درخواست تأیید بیومتریک یا PIN وارد حسابهای محافظتشده با passkey در Google Password Manager شود.
کشف و دامنهٔ تأثیر
محققان سه مسیر حمله علیه سازوکاری که کروم برای مدیریت passkeyها و احراز هویت ابری استفاده میکند را معرفی کردهاند: Pass‑ta‑key، Silver Pass‑ta‑key و Golden Pass‑ta‑key. این حملات به رمزنگاری پایه حمله نمیکنند، بلکه ضعفهای اجرایی در نحوهٔ ذخیرهسازی کلیدهای دستگاه، روند ثبت دوبارهٔ دستگاه و چکهای اعتبارسنجی را هدف قرار میدهند.
براساس گزارش، این حملات میتوانند یکی از سه عمل زیر را انجام دهند:
- بهصورت مخفی یک assertion معتبر احراز هویت دریافت کنند،
- یک کلید تأیید کاربر تحت کنترل مهاجم ثبت کنند،
- یا راز 32 بایتی Security Domain Secret (SDS) را استخراج کنند تا کلیدهای خصوصی passkeyهای همگامشده را بازیابی نمایند.
این پژوهش محدود به Google Password Manager در کروم روی ویندوز با TPM است و همهٔ مسیرها مستلزم اجرای بدافزار روی دستگاه قربانیاند؛ بنابراین این تکنیکها پس از نفوذ عمل میکنند و روشهایی برای عبور از محافظهای اولیه نیستند.
چگونگی فراهم شدن امکان حمله بهوسیلهٔ تنظیمات محلی کروم
کروم رکوردهای همگامسازیشده را در مسیری مانند %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB نگهداری میکند. فرایندهای بدون امتیاز میتوانند متادیتا را بخوانند و شناسهها، نامهای کاربری و مواد کلید رمزنگاریشده را شناسایی کنند؛ اطلاعاتی که به حملهکننده امکان هدفگیری و آمادهسازی حمله را میدهد.
یادداشتهای فنی از سورس کرومیوم
بررسی کد کرومیوم نشان میدهد کروم کلید TPM را بدون برچسبِ مشخص ایجاد و بهصورت blob صادر میکند که بعدها تحت فلَگهایی بدون نمایش درخواست کاربر بارگذاری میشود. در کد TODOهایی برای برچسبگذاری کلیدها و اصلاح رفتار مشاهده شده است. پیگیری مخازن کرومیوم برای درک تغییرات پیشنهادی مفید خواهد بود.
مسیر اول: Pass‑ta‑key
بدافزار blob هویت بستهبندیشدهٔ کروم را استخراج میکند و از TPM میخواهد تا درخواست احراز هویتی تحت کنترل مهاجم را از طریق فراخوانهای Windows CNG امضا کند. سرویس ابری احراز هویت خروجیای تولید میکند که assertion معتبر است، اگرچه بیت «User Verified (UV)» در آن تنظیم نشده است.
استاندارد WebAuthn مشخص میکند که اگر رِیلایینگ پارتی (سرویسِ پذیرنده) مقدار userVerification را روی required قرار داده باشد، نبودن بیت UV باید عملیات را رد کند. Unit 42 گزارش کرده که برخی سایتها، مانند GitHub، این چک را اجرا میکردند؛ اما در آزمایش، eBay تا زمان اصلاح پس از افشا چنین چکی را نمیگرفت؛ بنابراین رفتار سایت در این مورد تعیینکننده است، نه فقط سرویس ابری.
مسیر دوم: Silver Pass‑ta‑key
در این سناریو بدافزار روند ثبت دوبارهٔ دستگاه را تحریک میکند. کروم ممکن است بلافاصله کلید تأیید کاربر را ایجاد نکند و در این بازهٔ زمانی مهاجم قادر است کلید خود را ثبت کند. گزارش Unit 42 نشان میدهد سرویس همگامسازی بررسی نمیکند که آیا کلید تازه ثبتشده از سختافزار امن آمده یا خیر؛ در نتیجه assertionهای امضاشده با آن کلید ممکن است دارای بیت UV باشند و بعداً بدون دستگاه قربانی مورد استفاده قرار گیرند.
کد کرومیوم نشان میدهد دستگاههای تازه ثبتشده ممکن است وضعیت deferred_uv_key_creation را داشته باشند، اما مکانیزمهای سمت سرور برای تأیید منشاء سختافزاری کلید جای بهبود دارند.
مسیر سوم: Golden Pass‑ta‑key
این مسیر قویترین حالت است: بدافزار میتواند ثبت دوباره را تحریک کند و در زمانی که SDS بهطور موقت بهصورت متنصریح در حافظهٔ فرایند کروم قرار دارد، آن را استخراج کند. با دسترسی به SDS، مهاجم میتواند کلیدهای خصوصی passkeyهای همگامشده را بازیابی و از آنها برای ورودهای مجدد در محیط خود استفاده کند.
وضعیت افشاگرانه و CVE
گزارش موردی از بهرهبرداری وسیع در طبیعت نشان نمیدهد و شمارهٔ CVE، نسخههای دقیق آسیبپذیر یا وضعیت کامل رفع منتشر نشده است. تا زمان گزارش، موردی که دقیقاً مطابق این سه روش نامگذاریشده در پایگاه دادهٔ NVD ثبت شده باشد یافت نگردیده است (NVD).
اقدامات پیشنهادی برای مدیران و کاربران
قدمهای عملی و فوری برای کاهش خطر:
- سایتها بررسی userVerification را طبق قواعد WebAuthn بهدرستی انجام دهند و وقتی لازم است مراسم را رد کنند.
- توسعهدهندگان کروم و سرویسهای همگامسازی نحوهٔ مدیریت blobهای TPM و جریان ثبت دوبارهٔ دستگاه را بازبینی و نسبت به برچسبگذاری شفاف و نمایش درخواستهای تأیید کاربر اقدام کنند.
- تحقق وجود سختافزار امن (مانند TPM واقعی) را در سمت سرور مدنظر قرار دهید تا ثبت کلیدهای جایگزین کاهش یابد.
- پیادهسازی کنترلهای پیشگیری از نفوذ و سامانههای تشخیص رفتار مشکوک روی نقاط انتهایی برای مقابله با عملیات پس از نفوذ ضروری است.
جمعبندی و مسیر پیش رو
یافتهها نشان میدهد امنیت passkeyها علاوه بر اصول رمزنگاری، به کیفیت پیادهسازی محلی و میزان اعتبارسنجی سمت سرور وابسته است. پس از نفوذ، مهاجم ممکن است دسترسی تکرارشونده و بلندمدتی به حسابها بهدست آورد مگر آنکه لایههای حفاظتی تقویت شوند. برای دریافت جزئیات فنی و بهروزرسانیها، گزارش Unit 42 و مخازن پروژهٔ کرومیوم منابع اصلی هستند (Unit 42، Chromium).
