اختراق وسيط CA: عندما تنكسر سلاسل الثقة

إليك رأيًا يبدو معكوسًا: أسوأ حوادث هيئات الشهادات ليست تلك التي يقتحمها المهاجم. حادثة اختراق الوسيط في eMudhra الأخيرة دليل على ذلك. فقد أمكن استخراج ثماني مفاتيح لمراجع شهادات وسيطة من الشهادات نفسها دون أي اختراق، لأن مراسم توليد المفاتيح لدى الهيئة أنتجت مفاتيح خاصة بالغة الضعف، حتى إن أحدها كان حرفيًا الرقم 4. لم يسرق أحد تلك المفاتيح، بل وُلدت مخترقة. وهذا نمط فشل أخطر من أي خرق، لأنك لا تستطيع إصلاحه بتدوير بيانات الاعتماد وسدّ ثغرة. فالثقة نفسها كانت معيبة منذ اليوم الأول.

إذا كنت تشغّل أي شيء يُجري اتصالات TLS خارج المتصفح، وأنت كذلك، فهذا الأمر يستحق انتباهك. المتصفحات حُميت خلال أيام. أما بقية المنظومة، مثل أوامر curl في مهام cron لديك، وخدمات Python التي تثبّت certifi، وملفات Go التنفيذية المضمَّن فيها مخازن الجذور، فما زالت تلحق بالركب. دعني أستعرض ما حدث فعلًا، ولماذا يكون اختراق الوسيط أسوأ بطبيعته من اختراق الشهادة النهائية، وماذا يكشف الترقيع غير المتساوي عن حالة الإبطال (Revocation) في الإنترنت الحديث.

ما الذي حدث فعلًا في eMudhra

وفقًا للتقييم الأولي الذي نشرته الهيئة نفسها في متتبع الحوادث لدى Mozilla، فالقصة بسيطة إلى حد مؤلم. كان سكربت مراسم توليد المفاتيح، وهي العملية المضبوطة والمدققة التي تنشئ بها هيئة الشهادات أحساس مفاتيحها، قد عُدِّل بانحراف معتمد لاختبار إجراء تغليف المفاتيح وفك تغليفها للتصدير. تسبب خلل في الكود المعدَّل في توليد مجموعة ثانية من مفاتيح ECC على وحدة HSM، وكانت تلك المفاتيح ضعيفة. ليس ضعفًا من نوع «انخفاض العشوائية»، بل ضعفًا يجعل استخراجها من الشهادة العامة أمرًا تافهًا.

تأمّل ما يعنيه ذلك. يُفترض أن يكون المفتاح الخاص في ECC عددًا عشوائيًا من 256 بت، ويستند أمان المخطط كله إلى مسألة اللوغاريتم المتقطع: فمعرفة المفتاح العام يجب أن تجعل إيجاد العدد الخاص أمرًا مستحيلًا حسابيًا. لكن إذا كان العدد «العشوائي» بايتًا واحدًا، فالمفتاح العام ليس سوى نقطة المولّد مضروبة في ذلك البايت، ويستطيع أي أحد تجربة جميع الاحتمالات الـ256 في أجزاء من الثانية على حاسوب محمول. وقد ذُكر أن أحد المفاتيح الثمانية كان العدد الصحيح 4. هذا ليس اختراقًا بالمعنى التقليدي، بل شهادة لم تكن آمنة قط، صدرت تحت جذر تثق به Mozilla وMicrosoft وApple وChrome.

الباحث الذي أبلغ عن الثغرة، واسمه Wayne بحسب التقارير، أثبت امتلاكه للمفاتيح بتوقيع رسالة بكل مفتاح من المفاتيح الخاصة الثمانية، ثم أرسل التواقيع إلى برامج الجذور. ويستطيع أي شخص التحقق من الإثبات بأمرين أو ثلاثة في OpenSSL: استخراج المفتاح العام من كل شهادة وسيطة، ثم التحقق من أن التوقيع على الرسالة صحيح بالنسبة إليه. وهذا هو الجانب الأنيق والمرعب في إثبات امتلاك المفتاح بالتشفير، فلا لبس فيه ولا ضباب من عبارات «نحن نأخذ الأمن بجدية». إما أن تتحقق الحسابات أو لا تتحقق. وقد تحققت.

لماذا يكون اختراق الوسيط أسوأ من اختراق الشهادة النهائية

عندما يتسرب المفتاح الخاص لشهادة نهائية، كأن يصل مفتاح api.example.com إلى مستودع عام على GitHub، فإن نطاق الضرر يقتصر على اسم مضيف واحد، وربما عدد قليل منها إذا كانت الشهادة بحرف البدل. تُبطل الشهادة، وتُصدر واحدة جديدة، وتمضي. مزعج، لكنه ليس وجوديًا.

مفتاح الوسيط مختلف تمامًا. تعمل Web PKI كسلسلة من التواقيع: جذر (CA) محفوظ دون اتصال بالشبكة ومحروس كمادة نووية، يوقّع الوسطاء، والوسطاء يوقّعون الشهادات النهائية التي يقدّمها الخوادم فعلًا. ومن يملك المفتاح الخاص للوسيط هو تلك الهيئة لكل الأغراض التشفيرية. يستطيع إصدار شهادة صالحة لـ google.com أو لبنكك أو لنطاق SSO الداخلي لديك، وكل عميل يثق بالسلسلة سيقبلها دون أي اعتراض. لا يوجد حد للاستخدام، ولا جهة مركزية تُستشار، ولا طريقة لتمييز توقيع مزوَّر لكنه صالح عن توقيع شرعي.

ضاعفت حادثة eMudhra هذا الخطر ثماني مرات، إذ شملت وسطاء متقاطعي التوقيع عبر جذور Sectigo، تتصل بمخازن ثقة تُشحن في مليارات الأجهزة. وطوال نحو سنة ونصف، أي من وقت إصدار الشهادات المعيبة حتى الإفصاح عنها، كان بإمكان أي عميل يثق بتلك الوسطاء ولا يفرض فحص Certificate Transparency أن يتعرض لانتحال هويته من أي شخص يكلف نفسه استخراج المفاتيح. هذه هي النافذة. لا نعرف إن كان أحد قد استغلها، ومن دون رصد حظي في سجلات CT أو هجوم مرصود، قد لا نعرف أبدًا.

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

Certificate Transparency كان البطل غير المقصود

الجزء الذي يستحق اهتمامًا أكبر في القصة هو أن Chrome وSafari وFirefox وEdge كانت محمية، على الأرجح، قبل أن يعلم أحد بوجود المشكلة. ليس بفضل الإبطال، بل بفضل Certificate Transparency.

المتصفحات التي تفرض CT تشترط أن تكون كل شهادة معتمدة عامًا مسجّلة في سجلات CT عامة لا يمكن تعديلها إلا بالإضافة. والوسطاء المخترقون في eMudhra لا توجد لهم إدخالات في سجلات CT للفترة المعنية، ما يعني أن أي شهادة نهائية يصدرها المهاجم بتلك المفاتيح سترفضها العملاء الذين يفرضون CT، لأنها ستصل دون طوابع زمنية موقّعة صالحة للشهادة (SCT). كان على الاحتيال أن يُنشر حتى يُصدَّق، ونشره كان سيكشفه فورًا.

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

لكن، وهنا أتراجع عن حدود تفاؤلي، فإن فرض CT هو في الأساس رفاهية متصفحات. فغالبية عملاء TLS على الإنترنت لا تتحقق من SCT. وأمر curl لديك لا يفعل ذلك، ولا استدعاء requests في Python. ولا أسطول أجهزة إنترنت الأشياء الذي يتصل بسحابة المورّد. بالنسبة لكل هؤلاء، لم تكن الحماية الوحيدة سوى وصول بيانات الإبطال إلى مخزن الثقة في الوقت المناسب، وهنا تصبح القصة قبيحة.

فجوة الإبطال: المتصفحات مقابل كل شيء آخر

تعاملت شركات المتصفحات مع الأمر بكفاءة، وتستحق الثناء على بنية تحتية بُنيت قبل عقد. فقد أطلقت Mozilla آلية OneCRL، وهي آلية دفع لإلغاء الثقة بالوسطاء والجذور، منذ أكثر من عشر سنوات، وعالجت هذه الحادثة لمستخدمي Firefox خلال ساعات دون الحاجة إلى تحديث للمتصفح. وفعلت CRLSets في Chrome والآليات المكافئة لدى Apple الشيء نفسه على منصاتها خلال أيام قليلة. أبطلت الهيئة الوسطاء، ومن منظور مستخدم المتصفح انتهت الحادثة تقريبًا قبل أن تبدأ.

أما عالم ما خارج المتصفحات فالصورة مختلفة. قائمة الإصلاحات تبدو كجرد لسلسلة توريد البرمجيات: حزم ca-certificates محدّثة لـ Ubuntu وDebian وFedora وAlpine وArch وGentoo، وإصدار جديد من NSS، وحزمة CA جديدة لـ curl، وcertifi لبايثون، وrustls-webpki وwebpki-roots لـ Rust، وإصدارات Go الفرعية، وإصدارات Electron الترقيعية على ثلاثة خطوط إصدار، وca-bundle الخاصة بـ Composer، وcastore في Elixir. كل واحد منها أداة مستقلة، على وتيرة إصدار مستقلة، ويستهلكها آلية تحديث مستقلة. وبعضها كان لا يزال معلّقًا بعد أيام من الإفصاح.

ثم هناك الفئة التي تُبقيني مستيقظًا ليلًا: البرمجيات التي تضمّن مخزن الشهادات الخاص بها داخل الملف التنفيذي. فخدمة Go مترابطة ساكنًا بُنيت العام الماضي تحمل جذورها داخل الناتج المترجم. ولا حل سوى إعادة البناء وإعادة النشر، فلا توجد حزمة نظام يمكن ترقيعها. اضرب ذلك في كل صورة حاوية في سجلك التي تحتوي طبقة /etc/ssl/certs مضمّنة، وكل تطبيق Electron على كل حاسوب مكتبي، وكل صورة برامج ثابتة على كل جهاز متصل، وسترى حجم المشكلة. مخزن الثقة الخاص بالنظام هو الجزء السهل. لقد كتبنا من قبل عن كيف تحوّل الأجهزة المدمجة وأنظمة التقنيات التشغيلية الحوادث الأمنية إلى ملاحم تمتد لسنوات، والشهادة المخترقة هي بالضبط نوع الحدث الذي لا تُصلَح فيه تلك الأجهزة أبدًا.

مخازن الثقة الطويلة التي لا يملكها أحد

في هذه الحادثة حالة خاصة تستحق فقرة مستقلة لأنها توضح الفكرة تمامًا: macOS. فقد حجبت منصة Apple الوسطاء المخترقين على مستوى النظام بسرعة. لكن curl المدمج في /usr/bin/curl يتحقق عبر /etc/ssl/cert.pem، وهو ملف لم يُحدَّث، ولا يتحقق من الإبطال أصلًا. أي أن جهاز Mac مرقّعًا بالكامل قد يرفض فيه Safari شهادة مزوّرة، بينما يقبلها curl على الجهاز نفسه بكل سعادة. قراران للثقة، وجهاز واحد، وجوابان متعاكسان.

هذا التشظي هو الدرس الحقيقي. نميل إلى الحديث عن «Web PKI» كما لو كانت نظامًا واحدًا. بل هي عشرات الأنظمة ذات خصائص متباينة للغاية:

• المتصفحات: إبطال بالدفع (OneCRL، CRLSets)، وفرض CT، وتحديثات تلقائية. ويُقاس الإصلاح بالساعات إلى الأيام.
• مخازن ثقة أنظمة التشغيل: تحديثات تديرها الحزم (ca-certificates، ca_root_nss). ويعتمد الإصلاح على وتيرة إصدار التوزيعة، وعلى ما إذا كان الجهاز سيُرقَّع أصلًا.
• أنظمة اللغات البرمجية: certifi، وwebpki-roots، والجذور المضمّنة في Go، ومخزن Mozilla المرفق مع Node. ويعني الإصلاح إصدار نسخة جديدة وانتظار ترقية الاعتماديات عبر آلاف المشاريع.
• الملفات المترجمة والصور: ملفات تنفيذية وحاويات وبرامج ثابتة. ويعني الإصلاح إعادة البناء وإعادة النشر، وهو ما يعني عمليًا ذيلًا ضعيفًا طويلًا يمتد لسنوات.
• إنترنت الأشياء والأنظمة المدمجة: غالبًا لا يوجد مسار تحديث أصلًا. تعرّض دائم عمليًا.

أنفقت المتصفحات عقدًا كاملًا في الاستثمار في هذا السيناريو تحديدًا، وقلّما فعل غيرها ذلك. قال تعليق من جانب Mozilla بصراحة: خارج منظومة المتصفحات لم يكن هناك استثمار يُذكر في الإبطال، وبالنسبة لهذه العملاء فإن هذا النوع من الحوادث مشكلة ضخمة. وهذا يتفق مع كل ما رأيته في تشغيل البنية التحتية. وإذا كنت قد تعاملت مع النقاط العمياء في تسجيل أحداث المصادقة السحابية، فستتعرف على النمط نفسه: المسار الحرج مُراقَب جيدًا، أما الذيل الطويل فغرفة مظلمة.

كيف تتحقق مما إذا كانت عملاؤك ما زالوا معرّضين

بعيدًا عن النظرية، يجب أن تختبر بيئتك فعلًا، والجميل في TLS أنه يمكنك اختباره تجريبيًا. فقد أقام أعضاء من المجتمع مضيفين يقدمون شهادات موقّعة من الوسطاء المخترقين، فإذا اتصل عميلك دون خطأ في الشهادة، فهو ما زال يثق بهم. والنمط العام لاختبار curl أو أي أداة سطر أوامر يبدو هكذا:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

شغّل هذا من كل سياق يهمك: حواسيب المطورين، وعدّاءات CI، وصور الحاويات الأساسية، ومجموعات الخوادم. ستختلف النتيجة بينها، وهذه الاختلافات هي المقصود. وللحصول على جرد سريع لما يحتاج إلى ترقية:

• خدمات Go: أعد البناء بإصدار Go 1.27.3 أو 1.26.10 أو أحدث، فالجذور مُترجمة داخل الملف.
• Python: certifi بإصدار 2026.10.19 أو أحدث (وتحقق من إصدارات pip وuv أيضًا، فهما يحملان نسخهما الخاصة).
• Rust: rustls-webpki بإصدار 0.103.16، وwebpki-roots / webpki-root-certs بإصدار 1.0.10.
• Node.js وElectron: إصدارات معلّقة أو ترقيعية لكل خط إصدار، وتحقق من كل أداة مشحونة.
• مخازن النظام: حزم ca-certificates المحدّثة متاحة لـ Ubuntu وDebian وFedora وAlpine وArch وGentoo، أما ca_root_nss في FreeBSD فكانت معلّقة وقت كتابة هذا المقال.

إذا لم تستطع انتظار حزمة، فمعظم توزيعات Linux تتيح لك إلغاء الثقة بالجذور المتأثرة يدويًا. في Debian/Ubuntu يكفي وضع علامة ! أمام الشهادات في /etc/ca-certificates.conf ثم تشغيل update-ca-certificates؛ وفي عائلة Fedora/RHEL تستخرج الجذور إلى /etc/pki/ca-trust/source/blocklist/ وتشغّل update-ca-trust. ولدى NixOS خيار تصريحي نظيف:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

لاحظ ما الذي تُلغي الثقة به فعليًا في هذه الحلول المؤقتة: الجذور التي تتصل بها تلك الوسطاء. هذه هي حقيقة الإصلاح في PKI بأسلوب المطرقة. فلا توجد في معظم أدوات مخازن الثقة أداة «ألغِ الثقة بهذا الوسيط وحده»، لذا تضع الجذر في القائمة السوداء وتقبل الضرر الجانبي للشهادات غير المرتبطة. وهذا خيار صائب في حالة الطوارئ، لكنه يبقى مقايضة.

حيث تنهار فكرتي المعاكسة

بدأت كلامي بالقول إن فشل توليد المفاتيح الذي نتسبب فيه بأنفسنا أسوأ من الاختراقات. دعني أكون صادقًا حيث ينهار هذا الكلام. فالاختراق التقليدي، مثل DigiNotar، يوحي على الأقل بأن الهيئة كانت تعمل بكفاءة حتى تفوّق عليها المهاجم، والهيئات الكفؤة هي ما يراهن عليه النظام كله. أما مراسم مفتاح تُخرج المفتاح الخاص «4» فتوحي بأن الضوابط المدققة وإجراءات HSM وقوائم التحقق الامتثالية لم تكتشف عيبًا كارثيًا في أكثر العمليات حساسية لدى الهيئة. هذه ليست مشكلة خصم، بل مشكلة ضمان، والضمان هو المنتج الأساسي الذي تبيعه هيئة الشهادات.

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

ما الذي ينبغي فعله فعلًا

لا يمكنك إصلاح Web PKI. لكن يمكنك تقليص تعرّضك لفشلها التالي:

• اختبر، ولا تفترض. افحص عملاءك مقابل المضيفين الذين يقدمون السلاسل المخترقة. يستغرق هذا بعد ظهر واحدًا وسيفاجئك.
• أعد بناء الملفات المترجمة. ملفات Go التنفيذية وصور الحاويات تحمل مخازن ثقتها معها. عبارة «رقّعنا الصورة الأساسية» لا تعني شيئًا حتى تعيد النشر.
• اجرد مخازن الثقة لديك. لا يمكنك إصلاح ما لم تحصره. عُدّ نسخ certifi والحزم المضمّنة وتطبيقات Electron كما لو كانت مهمة، لأنها كذلك فعلًا.
• فضّل مخازن الثقة الخاصة بالنظام حيثما أمكن. كل حزمة مضمّنة هي ترقيع ستنسى شحنه. والاعتماد على مخزن نظام التشغيل لا يلغي المشكلة، لكنه يمنحك نقطة واحدة تركّز عليها.
• راقب منظومة CT والإبطال. توجد مشاريع تسعى إلى جلب إبطال بمستوى المتصفحات إلى العملاء خارجه، وتستحق الدعم، وهذه الحادثة أقوى حجة ستحصل عليها لتمويلها.
• تعامل مع حوادث هيئات الشهادات كحوادث أمنية. يجب أن تستدعي شخصًا، وتُطلق عملية جرد، وتنتج سجلًا مكتوبًا، تمامًا كما تفعل مع بيانات اعتماد مسرّبة. فهي كذلك فعلًا.

الخلاصة غير المريحة: آلية الطوارئ في Web PKI تعمل ببراعة في العملاء الذين كانوا أقل احتياجًا لها، لأن CT كان يغطيهم أصلًا. أما العملاء الذين يحتاجون الفرامل فعلًا، من دون واجهة مستخدم أو المدمجين أو المضمّنين أو المنسيين، فمعظمهم لا يملك أي فرامل. والحادثة التالية لاختراق وسيط في هيئة شهادات مسألة وقت لا احتمال. المتغير الوحيد تحت سيطرتك هو ما إذا كانت بيئتك ستنتبه لذلك.