تخيل سيناريو مرعبًا: جهاز يعمل بنظام ويندوز يُصاب ببرمجية خبيثة، ثم تواصل هذه البرمجية الدخول إلى حسابات محمية بمفاتيح مرور (Passkeys) دون أن تظهر على الشاشة أي مطالبة للمستخدم، ودون بصمة أو رقم تعريف شخصي أو حتى إشعار واضح بأن «التحقق البشري» تم. هذا ليس خيالًا؛ بل هو ما ناقشته أبحاث حديثة حول كيفية استغلال مسارات ما بعد الاختراق داخل متصفح كروم، وبالتحديد ضمن بنية مزامنة مفاتيح المرور عبر خدمة مدير كلمات المرور من جوجل.
الأهم هنا ليس كسر التشفير نفسه، بل استهداف منطق التحقق حوله: كيف تُدار مفاتيح الجهاز، وكيف تتم إعادة التسجيل (re-enrollment)، وما إذا كانت مواقع الويب تتحقق فعليًا من أن المستخدم تم التحقق منه بدلًا من افتراض ذلك من إعدادات تُرسل ضمن عملية المصادقة.
ما الذي تقوله الأبحاث؟ فهم الفكرة خلف «تجاوز التحقق»
وفقًا لعرض أمني تفصيلي من Unit 42 (ذراع الأبحاث لدى بالو ألتو نتووركس)، يمكن لبرنامج خبيث يعمل كـ مستخدم عادي على جهاز ويندوز أن يلتقط أو يعيد استخدام أجزاء من طبقات مصادقة مفاتيح المرور التي تعتمد على Trusted Platform Module (المعروف اختصارًا بـ TPM) وبنية مزامنة مفاتيح المرور داخل كروم.
النتيجة المحتملة: الحصول على «تأكيد مصادقة صالح» (authentication assertion) أو حتى استخراج سر أمني (Security Domain Secret) المستخدم لفك مفاتيح المرور الخاصة المتزامنة. والأخطر أن بعض المسارات يمكن أن تمنح «إعادة استخدام لاحقة» من بيئة المهاجم بعد اختراق أولي للجهاز.
هذه الأبحاث هي تقنيات ما بعد الاختراق؛ أي أنها تصف ما يمكن أن يفعله مهاجم بعد أن يصبح لديه تنفيذ برمجي على الجهاز بالفعل، وليس كيف يتم اختراق الجهاز في المقام الأول. هذا التفريق جوهري لفهم المخاطر وتحديد ضوابط الاستجابة.
لماذا تهم مفاتيح المرور؟ وما علاقتها بتقليل الاعتماد على كلمات المرور
مفاتيح المرور (Passkeys) تهدف إلى تقليل مشاكل كلمات المرور: إعادة الاستخدام، التصيد، التسريبات، والهجمات المعتمدة على إدخال بيانات اعتماد. بدلاً من كلمة مرور ثابتة، تُستخدم مفاتيح تشفير مرتبطة بالجهاز أو بحساب المستخدم، مع التحقق عبر بروتوكولات مثل WebAuthn وFIDO2.
لكن حتى مع قوة التشفير، يظل نظام المصادقة مرتبطًا بسلسلة من «الافتراضات» حول التحقق البشري: هل تم التحقق فعلاً؟ هل تم استخدام جهاز آمن؟ هل تم رفض استبدال المفاتيح غير الموثوق؟ هذه الافتراضات تظهر في تفاصيل مثل علم التحقق من المستخدم (User Verified أو UV) داخل تأكيدات المصادقة.
ثلاثة مسارات هجومية: من إعادة استخدام هوية الجهاز إلى استبدال مفاتيح التحقق
الأبحاث تصف ثلاث تقنيات رئيسية، وكل واحدة تستهدف طبقة مختلفة من منطق مصادقة مفاتيح المرور المتزامنة داخل كروم. وللتوضيح: لا يوجد ما يشير إلى كسر مباشر للتشفير، بل استغلال ثغرات منطقية/تنفيذية في كيفية بناء التأكيدات أو إدارة المفاتيح داخل العميل.
المسار الأول: استغلال علم التحقق من المستخدم داخل تأكيدات السحابة
المسار الأول (Pass-ta-key) يركز على استخراج مفتاح هوية الجهاز المغلف (wrapped device identity key) وطلب توقيع عبر واجهات تشفير في نظام ويندوز عبر CNG، ثم تمرير طلب إلى خدمة المصادقة السحابية الخاصة بمدير كلمات المرور.
هنا جوهر المشكلة: الخدمة تُرجع تأكيد مصادقة صالح، والفرق بين تأكيد حقيقي صادر بعد تحقق المستخدم وبين تأكيد صادر دون تحقق فعلي قد يكون «بتًا واحدًا» هو علم User Verified (UV)، والذي يبقى غير مضبوط.
الأبحاث تشير إلى أن بعض الجهات (مثل GitHub) طبقت التحقق من هذا العلم، بينما واجهت جهة أخرى (مثل eBay) فجوة في التحقق حتى تم تصحيحها بعد الإفصاح. هذا يسلط الضوء على درس عالمي: الاعتماد على «إعدادات الطلب» دون التحقق من «حقل الاستجابة» هو وصفة لفشل الأمان.
المسار الثاني: إعادة تسجيل الجهاز واستبدال مفتاح التحقق
المسار الثاني (Silver Pass-ta-key) يستهدف ما يحدث عندما يتم إجبار المتصفح على إعادة تسجيل الجهاز. خلال نافذة زمنية لا يتم فيها إنشاء مفتاح التحقق من المستخدم فورًا، يمكن للمهاجم—بحسب وصف الأبحاث—تسجيل مفتاح خاص به بدلًا من مفتاح موثوق.
النتيجة المحتملة هنا أكثر خطورة: قد تُصدر التأكيدات الموقعة بواسطة المفتاح الجديد علم UV، ما يتيح تسجيل دخول لاحق دون الحاجة لجهاز الضحية. الأبحاث تربط هذا بما يؤكده كود كروم/كروميوم من وجود حالة تأجيل إنشاء مفتاح التحقق (deferred_uv_key_creation)، مع التنبيه أن الكود العام لا يكفي وحده لإثبات أن جميع عناصر الاستبدال تمارس ضد أحدث إصدارات كروم بشكل مضمون.
كإجراء تخفيف، توصي الأبحاث بأن تتحقق الخدمة من إثبات العتاد الآمن (hardware attestation) عند قبول مفاتيح تم تسجيلها حديثًا.
المسار الثالث: استخراج سر المجال الأمني من ذاكرة العملية
المسار الثالث (Golden Pass-ta-key) الأكثر حساسية يستهدف Security Domain Secret (SDS) نفسه. الفكرة ليست مجرد قراءة بيانات من القرص، بل تحريك المتصفح لإعادة التسجيل، ثم قراءة السر من ذاكرة عملية كروم عندما يظهر—ولو لفترة قصيرة—بنص واضح (plaintext).
الأبحاث تشير إلى أن كروم ينشئ أو يستقبل أسرار المجال الأمني بحجم 32 بايت داخل هياكل بيانات داخلية، ما يعني أن السر يصل إلى ذاكرة العميل. لكن يبقى سؤال عملي محوري: هل يمكن للمهاجم تحويل ذلك إلى اختراق حساب دائم عبر استعادة مفاتيح المرور الخاصة المتزامنة؟ الأبحاث توضح مسارًا لذلك، لكنها لا تقدّم—وفق النص—حسمًا نهائيًا بخصوص الاستمرارية عبر «عصور» الأسرار أو كيفية إبطالها من منظور المستخدم.
كما ورد أن جوجل عدلت سابقًا ما يتعلق بتسجيلات FIDO، وأن eBay باتت تتحقق من علم UV. لكن التعديل في السجلات لا يعالج بالضرورة حقيقة أن السر يصل إلى الذاكرة داخل العميل.
ما الذي يعنيه ذلك للقطاعات الحساسة؟ (وليس فقط للمستخدمين)
قد يبدو الأمر وكأنه تهديد للمستخدم الفردي، لكن تداعياته تمتد إلى قطاعات تعتمد على مصادقة قوية لتقليل الاحتيال:
- القطاع المالي: تطبيقات البنوك ومحافظ الدفع غالبًا تستخدم WebAuthn/Passkeys لتقليل الاحتيال. أي ثغرة في منطق التحقق (خصوصًا علم UV) قد تفتح بابًا لتجاوز «التحقق البشري» على نحو صامت.
- التجارة الإلكترونية: منصات مثل eBay وغيرها تتعامل مع ملايين جلسات المصادقة؛ فجوة في التحقق من التأكيدات قد تنتج عمليات دخول غير مشروعة دون إشعار واضح.
- الحكومة والمؤسسات: حتى لو كانت الأنظمة الداخلية تستخدم حلولًا أكثر صرامة، فإن المستخدمين قد يستعملون نفس بيئة المتصفح لمصادقات سحابية، ما يجعل «العميل» نقطة خطر مشتركة.
وبشكل عام، ينسجم هذا مع اتجاه عالمي: الهجمات الحديثة لا تكتفي باستهداف كلمات المرور، بل تستهدف سلسلة المصادقة نفسها—من العتاد إلى منطق التحقق في الطرف المعتمد.
إطار مفاهيمي: لماذا «لا يهم كسر التشفير» في بعض الهجمات؟
من أكثر المفاهيم التي يساء فهمها: الاعتقاد بأن قوة التشفير وحدها كافية. في الواقع، كثير من الهجمات لا تحتاج إلى كسر الخوارزمية؛ يكفيها أن تستغل:
- فجوات منطقية في كيفية بناء أو تفسير تأكيدات المصادقة.
- افتراضات خاطئة لدى الطرف المعتمد بأن الإشارة (مثل UV) تم ضبطها بشكل موثوق.
- هندسة إعادة التسجيل التي قد تسمح بتبديل مفاتيح خلال نافذة زمنية.
- تعرض أسرار داخل ذاكرة العميل عند ظروف محددة.
هذه هي الفروق بين «هجوم تشفير» و«هجوم نظام مصادقة». الأول يهاجم الخوارزمية، والثاني يستغل ما حولها—وهو غالبًا الأكثر واقعية في الهجمات البرمجية.
ما الذي يجب فعله؟ توصيات عملية للمواقع ومطوري حلول الهوية
الأبحاث تقدّم توجيهات واضحة، ويمكن صياغتها كقائمة إجراءات قابلة للتطبيق:
- للطرف المعتمد (المواقع/الخدمات): ضبط userVerification على required (ومع ذلك، الأهم) التحقق من علم UV داخل الاستجابة وليس الاكتفاء بأن الطلب «طلب ذلك».
- لمقدمي بيانات الاعتماد (Credential Providers): تطبيق attestation للأجهزة عند تسجيل مفاتيح جديدة، مع تشديد فحوصات إعادة التسجيل والاسترداد.
- لتقليل سطح الهجوم على العميل: تقنيات تقييد وصول عمليات النظام إلى حالة المرور المحلية، وتقليل فرص قراءة الأسرار من الذاكرة.
- للحوكمة والامتثال: مواءمة الضوابط مع أطر مثل NIST Cybersecurity Framework واتباع مبادئ OWASP في تصميم المصادقة وتحقق المدخلات/المخرجات.
على مستوى المستخدمين والمؤسسات، تبقى قاعدة ذهبية: أي مصادقة قوية لا تنقذ جهازًا مخترقًا إذا ظل المهاجم قادرًا على تنفيذ كود داخل المتصفح أو الوصول إلى سياق العملية.
هل هناك رقم تسلسلي للثغرات أو تحديثات مؤكدة؟
وفقًا للنص، لم يتم العثور—عند البحث بتاريخ 3 أغسطس 2026—على معرفات CVE تطابق التقنيات الثلاث المذكورة. كما لا يذكر الإفصاح نسخ كروم المتأثرة بالتحديد أو حالة الإغلاق الكاملة لكل مسار. هذا شائع في أبحاث «هندسة المصادقة»؛ إذ قد لا تُترجم المشكلة دائمًا إلى CVE واحد واضح، خصوصًا عندما تكون الفجوة مرتبطة بمنطق الطرف المعتمد أو بتفاصيل تنفيذية داخلية.
كما أن الكود المنشور من مشروع Chromium—بحسب ما ورد—يدعم أجزاء من البنية، لكن لا يضمن وحده أن أحدث إصدار مستقر من كروم يظل قابلًا للاستغلال بنفس الطريقة.
كيف يتصرف المستخدم عندما يشتبه بالاختراق؟ سؤال يظل بلا إجابة كاملة
من الناحية العملية، يواجه المستخدم تحديًا: ما الذي يبطل ما حصل عليه المهاجم بالفعل؟ وفق النص، تسمح وثائق دعم مدير كلمات المرور بتغيير رقم التعريف الخاص (PIN) أو حذف بيانات مدير كلمات المرور، لكن لا يوجد—بحسب ما ورد—تحكم واضح لإعادة تدوير SDS أو إبطاله بشكل مخصص.
هذا يطرح سؤالًا جوهريًا يهم خبراء الأمن والمستخدمين على حد سواء:
إذا تم استغلال سر مجال أمني داخل ذاكرة العميل، فهل تغيير PIN أو حذف بيانات مدير كلمات المرور يُجبر الخدمة على إنشاء حقبة جديدة (secret epoch) يبطل الوصول السابق؟
الإجابة ليست مجرد تفصيل—بل هي الفرق بين «تخفيف مؤقت» و«استعادة أمان فعلية».
ختام: هل نحن ننتقل من هجمات كلمات المرور إلى هجمات التحقق نفسه؟
هذه الأبحاث تذكّر بأن الانتقال إلى مفاتيح المرور لا يعني نهاية الهجمات؛ بل يعني انتقالها إلى طبقات أكثر دقة: متى يُعتبر المستخدم مُتحققًا؟ من يملك القرار؟ وما الذي يحدث عند إعادة التسجيل؟
والسؤال الذي ينبغي أن يرافق كل مؤسسة تطبق مفاتيح المرور هو: هل بنية المصادقة لديكم تتحقق من «إشارة التحقق» فعليًا من الطرف الصحيح، وتفرض قيودًا صارمة على إعادة التسجيل والاسترداد، وتفترض أن العميل قد يكون—في أسوأ الحالات—مخترقًا؟
ما الضابط الذي تعتقد أنه الأكثر إلحاحًا لدى المؤسسات اليوم: التحقق الصارم من علم التحقق داخل الاستجابة، أم فرض إثبات العتاد عند تسجيل المفاتيح، أم تعزيز حماية حالة المرور داخل المتصفح؟
روابط بحثية إضافية
تابع تغطياتنا وتحليلاتنا على:
#أمن_المعلومات #مفاتيح_المرور #مصادقة
Leave a Reply