هجمات «Pass-ta-key» تستغل ثغرات Chrome لاختطاف مفاتيح المرور على Windows

المهم هنا أن الهجمات لا تكسر تشفير WebAuthn أو FIDO2 نفسه، بل تستغل عيوباً في طريقة عمل موثّق Google السحابي، وفي إجراءات تسجيل الجهاز وإعادة ربطه بالحساب . كما أن جميع السيناريوهات تتطلب إصابة الجهاز بالبرمجيات الخبيثة أولاً؛ فالجهاز النظيف لا يتعرض لهذه الهجمات بهذه الطريقة.

التقنيات الثلاث.. وما الذي تستغله كل واحدة؟

1. هجوم Pass-ta-key الأساسي

تستخرج البرمجية الخبيثة مفتاح هوية الجهاز الذي يحميه نظام TPM من ملف Chrome المحلي passkey_enclave_state، ثم تعيد استخدامه عبر استدعاءات نظام Windows المشروعة الخاصة بواجهات التشفير CNG لتوقيع طلبات يسيطر عليها المهاجم.

وبذلك يمكن إنتاج استجابة مصادقة صالحة وفق WebAuthn من دون ظهور مطالبة ببصمة أو رقم تعريف شخصي على شاشة الضحية. إلا أن الهجوم ينجح فقط ضد المواقع التي لا تتحقق من علامة User Verified (UV) في بيانات الموثّق .

ما الذي يستغله؟

• ثقة الموثّق السحابي في مفتاح هوية جهاز محفوظ محلياً.
• عدم فرض بعض المواقع التحقق الفعلي من علامة التحقق من المستخدم.

2. هجوم Silver Pass-ta-key

يتجاوز هذا السيناريو حتى المواقع التي تفرض التحقق من المستخدم. ويبدأ بحذف ملف passkey_enclave_state المحلي أو إبطال محتواه، ما يدفع Chrome إلى إعادة تسجيل الجهاز لدى الخدمة.

وخلال عملية إعادة التسجيل، ينشئ Chrome مفتاح التحقق من المستخدم مؤقتاً ضمن مسار مؤجل. ويستغل المهاجم هذه النافذة لتسجيل مفتاح UV خاص به. وبما أن موثّق Google السحابي لا يتحقق من شهادة مصدر المفتاح الجديد، فإن الاستجابات الموقعة به تحمل علامة UV مضبوطة على 1، فتبدو للمواقع وكأن المستخدم تحقق فعلاً من هويته .

والنتيجة هي وصول مستمر يمكن للمهاجم استخدامه من جهازه هو، من دون الحاجة إلى بقاء جهاز الضحية متصلاً بالإنترنت.

ما الذي يستغله؟

• غياب التحقق من شهادة مصدر المفتاح أثناء إعادة تسجيل الجهاز.
• إمكانية حذف ملف حالة الـenclave من دون وسائل حماية كافية.

3. هجوم Golden Pass-ta-key الأخطر

يستخدم هذا السيناريو مسار إعادة التسجيل نفسه، ثم يفرغ ذاكرة عملية Chrome لاستخراج سر نطاق الأمان (Security Domain Secret أو SDS).

وهذا السر عبارة عن مفتاح متماثل بطول 32 بايتاً يُستخدم لتشفير جميع مفاتيح المرور المتزامنة في حساب Google الخاص بالضحية. وإذا حصل المهاجم عليه، فبإمكانه فك تشفير مفاتيح المرور الخاصة الحالية، وكذلك أي مفاتيح جديدة تتم مزامنتها لاحقاً، ما يفتح الطريق أمام الاستيلاء الكامل على الحسابات المحمية بها .

وكان Google قد سجّل سر SDS سابقاً بنص واضح في مخرجات chrome://device-log/FIDO داخل Chrome، وقد أزيل هذا السجل بعد إبلاغ Unit 42، لكن مشكلة وجود السر في ذاكرة العملية لا تزال قائمة وفق التقارير .

ما الذي يستغله؟

• وجود سر SDS بصيغة واضحة في ذاكرة Chrome أثناء عملية تسجيل الجهاز.

ما المواقع المتأثرة؟

يعمل هجوم Pass-ta-key الأساسي ضد أي موقع يعتمد على مفاتيح المرور ولا يتحقق من علامة UV. وحددت Unit 42 موقع eBay مثالاً على خدمة لم تكن تفرض هذا الفحص، قبل أن يصلح الموقع المشكلة لاحقاً .

وأشار الباحثون إلى أن عدداً «مفاجئاً» من المواقع يطلب userVerification: "required" عند تسجيل مفتاح المرور، لكنه لا يتحقق من قيمة UV التي تعود مع عملية المصادقة . وهذا يعني أن طلب التحقق وحده لا يكفي؛ إذ يجب على الخادم فحص النتيجة فعلياً قبل منح صلاحية الدخول أو تنفيذ العمليات الحساسة.

ماذا يعني تسريب مفتاح SDS الرئيسي؟

يعمل SDS عملياً كمفتاح رئيسي لجميع مفاتيح المرور المتزامنة في حساب Google. وتسريبه قد يؤدي إلى:

• فك تشفير كل مفتاح مرور خاص متزامن حالياً، وقراءة أي مفتاح جديد تتم مزامنته لاحقاً .
• تسجيل الدخول إلى أي حساب محمي بمفتاح مرور، بما في ذلك Gmail، من دون تفاعل إضافي من الضحية .
• توسيع نطاق الاختراق إلى خدمات أخرى؛ إذ يستطيع المهاجم الذي يسيطر على Gmail طلب إعادة تعيين كلمات مرور حسابات مرتبطة به .
• عدم القدرة على تدوير SDS أو إنشاء نسخة جديدة منه عبر آلية مدمجة للمستخدمين، وفق ما أوردته التقارير .

كيف يمكن تقليل المخاطر؟

استناداً إلى توصيات Unit 42 والتغطية الأمنية للنتائج، يمكن للمستخدمين والمؤسسات اتخاذ الخطوات التالية:

• تسجيل مفتاح أمان مادي واحد على الأقل، مثل YubiKey، إلى جانب مفتاح المرور المتزامن. فبيانات الاعتماد المرتبطة بالجهاز لا تتم مزامنتها مع السحابة، ولا تدخل حالة enclave في Chrome، ولا يمكن قراءتها من ذاكرة المتصفح بالطريقة نفسها .
• تفعيل برنامج الحماية المتقدمة من Google للمستخدمين مرتفعي المخاطر، مثل الصحفيين والمديرين التنفيذيين والناشطين ومديري الأنظمة. ويفرض البرنامج استخدام مفاتيح أمان أو مفاتيح مرور مرتبطة بالجهاز، كما يشدد إجراءات استعادة الحساب .
• مراجعة قائمة الأجهزة المرتبطة بحساب Google مرة كل شهر وإزالة أي جلسات أو أجهزة غير معروفة .
• اعتبار أي إصابة ببرمجية لسرقة المعلومات حادثة تستدعي إعادة ضبط شاملة لبيانات الاعتماد. وبعد استعادة السيطرة، يُنصح بإعادة بناء الجهاز وتسجيل جميع مفاتيح المرور من جهاز نظيف .
• على المواقع والخدمات التحقق من علامة UV على الخادم، واستخدام userVerification: "required" بدلاً من "preferred" عند تنفيذ العمليات الحساسة .

الوضع الحالي

حتى تاريخ نشر النتائج في 3 أغسطس 2026، لم يُسند رقم CVE إلى هذه المشكلة، كما لم تؤكد Google علناً ما إذا كانت ستصلح مساري Silver Pass-ta-key أو Golden Pass-ta-key بشكل مباشر .

الخلاصة الأهم للمستخدمين هي أن قوة مفتاح المرور لا تعتمد على التشفير وحده، بل أيضاً على سلامة الجهاز والمتصفح وآلية تسجيل الجهاز. فإذا وصلت البرمجية الخبيثة إلى جهاز Windows، فقد تتمكن من استغلال هذه الطبقات المحيطة بالمفتاح من دون الحاجة إلى كسر الخوارزميات التي تحميه.