في 17 أكتوبر 2026، أرسل باحث أمني يُعرف فقط باسم "Wayne" رسالة إلى فرق برامج شهادات الجذر (Root Programs) للمتصفحات في Apple وGoogle وMicrosoft وMozilla. كانت الرسالة موقعة باستخدام المفاتيح الخاصة لـ ثماني سلطات شهادات وسيطة (Intermediate CAs) تديرها شركة eMudhra، وهي مزود الثقة الرقمية الهندي المسؤول عن العلامة التجارية emSign. وجاء في الرسالة: 

"لدينا مشكلة هنا – Wayne" 

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

وبعد خمسة أيام، أعلنت eMudhra عن خروجها بالكامل من قطاع شهادات SSL/TLS العالمي. 

بالنسبة لمدراء أمن المعلومات (CISOs) ومهندسي الأمن المعماري - وخاصة أولئك الذين يديرون بيئات التكنولوجيا التشغيلية (OT)، وأنظمة التحكم الإشرافي وتحصيل البيانات (SCADA)، وإنترنت الأشياء الصناعي (IIoT) - فإن هذا الحادث يستحق اهتماماً أكبر بكثير مما تشير إليه عناوين الأخبار. إليكم الصورة الكاملة للحادثة، بما في ذلك التطورات التي حدثت خلال الـ 48 ساعة الماضية. 

ما حدث بالفعل: النسخة الموجزة 

بين شهري أبريل ومايو 2025، أجرت eMudhra مراسم توليد مفاتيح (Key Ceremony) لإنشاء 24 مفتاحاً لسلطات شهادات تابعة تحت تسلسل emSign Root TLS CA – G3 الخاص بها. وأثناء خطوة التغليف/فك التغليف (wrap/unwrap) على وحدة أمان الأجهزة (HSM)، أدى خلل في البرنامج النصي (Script) الخاص بتوليد المفاتيح إلى إنشاء مجموعة ثانية من المفاتيح الضعيفة المعتمدة على المنحنى الإهليلجي P-384. وبسبب تشابه تسميات المفاتيح ووقوع خطأ بشري، تم استخدام ثمانية من تلك المفاتيح الضعيفة لإصدار شهادات سلطات الشهادات الوسيطة الفعلية. 

يتم عادةً استخلاص مفاتيح P-384 المولدة بشكل صحيح من نطاق يقارب 10¹¹⁵ من القيم المحتملة. أما هذه المفاتيح، فقد تراوحت إنتروبيتها (عشوائيتها) الفعالة بين 3 إلى 8 بتات فقط. ولم تكن استعادة هذه المفاتيح إنجازاً في تحليل وتشفير البيانات، بل كانت مجرد عملية حسابية بسيطة. 

المفاتيح الوسيطة الثمانية المخترقة هي: 

التفصيل الجوهري الذي تغفله معظم التغطيات الإخبارية: توجد كل شهادة وسيطة أيضاً كشهادة ثانية موقعة توقيعاً متبادلاً (Cross-signed) بواسطة جذر "AAA Certificate Services" القديم التابع لشركة Sectigo. ولذلك، فإن مجرد إزالة جذور eMudhra من مخزن الثقة (Trust Store) الخاص بك لا يكفي؛ فأي نظام لا يزال يثق في جذر Sectigo سيكون قادراً على التحقق من صحة النسخ الموقعة توقيعاً متبادلاً. 

الجدول الزمني: 17 شهراً من التعرض، و100 دقيقة لاحتواء الأزمة 

أُنشئت المفاتيح الضعيفة في 30 أبريل 2025، وظلت قابلة للاسترداد علناً لمدة تقارب 17 شهراً قبل أن يلاحظها أحد. ومع ذلك، فإن ما حدث بعد اكتشافها يُعد واحداً من أسرع الاستجابات المنسقة في تاريخ البنية التحتية للمفاتيح العامة (PKI): 

• 30 أبريل 2025 – مراسم مفاتيح معيبة تولد الشهادات الوسيطة الثمانية. 

• 14 مايو 2025 – شركة Sectigo تجري توقيعاً متبادلاً للشهادات الوسيطة تحت مظلة AAA Certificate Services. 

• 23 مايو 2025 – ظهور أقدم دليل على وجود توقيعات CRL غير صالحة من نفس هذه الشهادات الوسيطة، وهي إشارة تحذيرية تم تشخيصها بشكل خاطئ في ذلك الوقت. 

• 17 أكتوبر 2026، 18:05 بتوقيت UTC – برنامج Chrome Root يتلقى تقرير Wayne. 

• 17 أكتوبر 2026، 19:45 بتوقيت UTC – متصفح Chrome يصدر تحديث CRLSet لحظر المفاتيح المخترقة عبر تجزئة SPKI، وتبعه متصفح Firefox بحلول الساعة 22:59 بتوقيت UTC. إجمالي الوقت المستغرق: أقل من ساعتين. 

• 18 أكتوبر 2026 – شركة eMudhra تلغي جميع الشهادات الوسيطة الثمانية. 

• 19 أكتوبر 2026 – شركة Apple تحظر الشهادات؛ وSectigo تلغي نسخها الموقعة توقيعاً متبادلاً؛ كما تم إطلاق تدابير الحماية لنظام Android عبر خدمات Google Play. 

• 20 أكتوبر 2026 – شركة Microsoft تحظر الشهادات؛ وMozilla تزيل الثقة بالكامل في emSign ECC Root CA – G3؛ وإصدار نسخ مصححة لكل من Go وFirefox وPython. 

• 22 أكتوبر 2026 – شركة eMudhra تعلن خروجها من سوق شهادات SSL/TLS العالمية. وأكد رئيس مجلس الإدارة V. Srinivasan أن الإلغاء تم خلال 14 ساعة من الاكتشاف، وأنه لم يتم إصدار أي شهادات للكيانات النهائية (End-entity certificates) من الشهادات الوسيطة المتأثرة، وأنه لم يحدث أي اختراق للبيانات. 

• 27 أكتوبر 2026 – إزالة جذر emSign ECC Root CA – G3 من متصفح Chrome تصل إلى جميع الأجهزة. يجب على مشغلي المواقع الإلكترونية التي لا تزال مرتبطة بهذا الجذر الترحيل إلى شهادة جديدة فوراً لتجنب انقطاع الخدمة. 

هل تم استغلال هذا الضعف؟ 

حتى تاريخ 27 أكتوبر 2026، لم يتم تأكيد أي استخدام ضار. وأفادت تقارير Google بأنه لم يتم تسجيل أي شهادة TLS مرتبطة بالشهادات الوسيطة المتأثرة في سجلات شفافية الشهادات (Certificate Transparency - CT)، مما يستبعد وقوع هجمات ضد العملاء الذين يفرضون سياسات CT. 

ولكن هناك نقطتان هامتان يجب أخذهما في الاعتبار عند التخطيط لإدارة المخاطر: 

1. كانت المفاتيح قابلة للاسترداد لمدة 17 شهراً لأي جهة تبحث عنها، ولا يوجد أي سجل تقني يوثق من قام بذلك بالفعل. 

2. لا يتم تسجيل شهادات توقيع الشيفرات البرمجية (Code-signing) في سجلات CT. نظرياً، كان بإمكان مفتاحي EM OV CS CA توقيع ملفات ثنائية تظهر وكأنها صادرة عن جهة نشر موثوقة ومتحقق منها على أنظمة Windows التي تتخطى عمليات فحص الإلغاء. ولا يوجد أي سجل عام يوضح ما تم توقيعه بواسطتها، إن وُجد. 

يجب التعامل مع جميع المفاتيح الثمانية على أنها مكشوفة ومعروفة للمهاجمين. 

لماذا تختلف هذه الحادثة عن حادثتي DigiNotar وSymantec؟ 

إن حوادث انهيار الثقة في سلطات الشهادات ليست جديدة؛ فقد انتهت حادثتا DigiNotar (عام 2011) وSymantec (عام 2017) بنهايات مشابهة. لكن حادثة eMudhra تمثل نمط فشل مختلفاً تماماً: 

• كانت DigiNotar اختراقاً أمنياً، حيث سرق المهاجمون المفاتيح من بنية تحتية تم التسلل إليها. 

• كانت Symantec فشلاً في الحوكمة التشغيلية، تمثل في إصدار شهادات غير صحيحة تم اكتشافها عبر سجلات CT. 

• أما eMudhra فتعد فشلاً في مراسم توليد المفاتيح (Key Ceremony Failure) - حيث كان الأساس التشفيري نفسه معيباً منذ لحظة التوليد، داخل العملية التي يُفترض أن تكون الأكثر صرامة ورقابة من بين جميع عمليات سلطة الشهادات. 

يكتسب هذا التمايز أهميته لأن مراسم المفاتيح هي ركيزة الثقة للبنية التحتية للمفاتيح العامة (PKI) في المؤسسات، ولتوقيع الشيفرات البرمجية المدعوم بوحدات أمان الأجهزة (HSM)، وللهوية الرقمية الصناعية بشكل متزايد. وإذا تمكنت هذه المراسم من إنتاج مفتاح بقيمة "4" دون أن يُكتشف ذلك، فإن جميع الافتراضات الأمنية المبنية عليها تنهار تماماً. 

الجانب الذي لا يتحدث عنه أحد: ماذا يعني هذا لشبكات PKI الصناعية والتكنولوجيا التشغيلية (OT)؟ 

هنا تصبح هذه القضية مصدر قلق مباشر للمؤسسات التي تدير البنى التحتية الحيوية. 

1. تم تحديث متصفحاتكم، ولكن أسطول أجهزة التكنولوجيا التشغيلية (OT) لديكم لم يتم تحديثه على الأرجح. 

حصل مستخدمو Chrome وFirefox على الحماية في غضون ساعات. ومع ذلك، يعتمد نموذج الحماية هذا على التوزيع الآلي لبيانات الإلغاء - مثل CRLSet وOneCRL وCRLite - للعملاء الذين يقومون بالتحديث باستمرار. 

الآن، ألقِ نظرة على بيئة التكنولوجيا التشغيلية لديك: 

• خوادم حفظ البيانات التاريخية لأنظمة SCADA (Historians) ومحطات واجهة المستخدم الرسومية (HMI) التي تعمل بإصدارات Windows لم تتلقَ تحديثاً لمخزن شهادات الجذر منذ سنوات. 

• وحدات RTU، ومتحكمات PLC، والوحدات الطرفية البعيدة التي تعتمد على حزم شهادات وسلطات مدمجة ومبرمجة منذ عقد من الزمن. 

• بوابات VPN الصناعية وأجهزة الوصول عن بُعد القائمة على الاتصال الخلوي أو التردد اللاسلكي (RF) التي تتحقق من صحة الشهادات عبر مخازن ثقة على مستوى البرامج الثابتة (Firmware). 

• حاويات Docker، ومسارات البناء البرمجي (Build Pipelines)، ونصوص الأتمتة البرمجية المعتمدة على Python والتي تستخدم حزم certifi محددة وثابتة منذ أشهر. 

• أجهزة Linux المضمنة في المحطات الفرعية وخطوط الأنابيب التي لا تتلقى أي تحديثات لمخازن الثقة على الإطلاق. 

يشير التقرير الإرشادي لشركة Fortinet صراحةً إلى الأجهزة المضمنة وأجهزة إنترنت الأشياء (IoT)، والأجهزة القديمة (Legacy)، والأجهزة الافتراضية والحاويات، والأدوات التي تحتفظ بمخازن ثقة SSL خاصة بها (مثل Python)، باعتبارها الفئات الأكثر عرضة للمخاطر. 

وقد أكدت Red Hat أن جميع إصدارات RHEL المدعومة - من الإصدار 6 إلى 10 - كانت تتضمن السلسلة المخترقة في حزمة ca-certificates، وأن أي اتصال TLS يعتمد على أنظمة RHEL يظل قادراً على الوثوق بالشهادات الصادرة بطرق احتيالية حتى يتم تحديث تلك الحزمة. 

2. خطر الهجوم عبر وسيط (MITM) في بيئات التكنولوجيا التشغيلية هيكلي وليس مجرد احتمال نظري. 

في تكنولوجيا المعلومات (IT)، يتطلب تنفيذ هجوم الوسيط (Man-in-the-Middle) الوصول إلى المسار الشبكي. أما في التكنولوجيا التشغيلية (OT)، فغالباً ما يكون المسار الشبكي نفسه البيئة الأكثر ملاءمة للمهاجم: 

• الشبكات المسطحة (Flat Networks) أو ضعيفة التقسيم في المنشآت والمصانع القديمة. 

• أنفاق الوصول عن بُعد الخاصة بالموردين التي تنتهي عند مضيفات القفز (Jump Hosts) والتي تثق في مخازن شهادات النظام العامة. 

• واجهات الإدارة خارج النطاق (Out-of-band) في المعدات القديمة. 

• بوابات ومحولات البروتوكولات التي تنهي اتصال TLS وتعيد التشفير في مسار النقل التالي. 

إن المهاجم الذي يمتلك مفتاح سلطة شهادات وسيطة مخترقاً ويتواجد على شبكة OT مسطحة يمكنه انتحال شخصية محطة عمل هندسية أمام خادم Historian، أو انتحال شخصية خادم Historian أمام شاشة HMI، واعتراض حركة البيانات أو تعديلها - بما في ذلك الأوامر التشغيلية. وبالنسبة للبيئات التي يُستخدم فيها بروتوكول TLS لحماية جلسات الهندسة والتحكم عن بُعد، فإن هذا لا يعتبر مجرد قلق نظري بل تهديد حقيقي. 

3. يصل توقيع الشيفرات البرمجية مباشرة إلى سلاسل التوريد الخاصة بكم. 

ترتبط الشهادتان الوسيطتان المخترقتان لتوقيع الشيفرات البرمجية (EM OV CS CA – G3B/G3C) بجذر emSign Root CS CA – G3 الموثوق من Microsoft. وتصرح eMudhra بأنه لم تدخل أي من سلطتي الشهادات حيز التشغيل الفعلي. ولكن إذا كانت مؤسستك تتحقق من صحة البرامج الثابتة الموقعة، أو الأدوات المساعدة الموقعة من الموردين، أو تحديثات أنظمة SCADA الموقعة على أنظمة Windows التي تعاني من بطء أو عدم تحديث إجراءات الإلغاء، فإن هذا الحادث هو تذكير بأن قرار الثقة الخاص بك يعتمد على أضعف سلطة شهادات في مخزن الجذر لديك - وأنت لا تملك القدرة على تحديد سلطات الشهادات التي يختارها الموردون. 

4. إشارة التحذير في قوائم CRL لعام 2025 هي الدرس الحقيقي. 

في يونيو 2025، سجلت Mozilla توقيعات CRL غير صالحة من نفس هذه الشهادات الوسيطة الست لبروتوكول TLS. وأرجعت eMudhra ذلك إلى إجراء يدوي استخدم المفتاح الخطأ، وقامت بنشر قوائم CRL مصححة، وأُغلق بلاغ الخلل. 

كان ذلك هو السبب الجذري نفسه، وكان مرئياً قبل 16 شهراً ولكن تم تشخيصه بشكل خاطئ. والدرس المستفاد لقادة أمن التكنولوجيا التشغيلية قاطع ومباشر: راقبوا سلامة سلطات الشهادات في تبعيات الشهادات لديكم تماماً كما تراقبون الثغرات الأمنية (CVEs) في برمجياتكم. إن سلطة الشهادات التي تنتج قوائم CRL غير صالحة هي سلطة يجب التشكيك في إجراءات مراسم المفاتيح الخاصة بها فوراً. 

قائمة الإجراءات العملية لفرق التكنولوجيا التشغيلية والبنية التحتية الحيوية 

إجراءات فورية (خلال هذا الأسبوع): 

1. إجراء جرد شامل لكل نظام في بيئة OT لديك يتحقق من صحة اتصالات TLS أو التوقيعات الرقمية - بما في ذلك الأجهزة والعتاد الشبكي، والبوابات، ووحدات أمان الأجهزة (HSMs)، وصور الحاويات، والأجهزة المضمنة. افترض أن المتصفحات تم التعامل معها وتحديثها؛ فكل ما عدا ذلك يقع تحت مسؤوليتك المباشرة. 

2. تحديث مخازن الثقة إلى ما هو أبعد من مستوى نظام التشغيل: بيئات تشغيل لغات البرمجة (مثل certifi، ومكتبة crypto/x509 في Go - والتي تم تصحيحها في الإصدارين Go 1.26.10 و1.27.3 وتتبع بالرمز CVE-2026-111943)، ومخازن ثقة JVM، والبرامج الثابتة للأجهزة، وقوائم CA المحددة من الموردين. 

3. التحقق من مخاطر التوقيع المتبادل لـ Sectigo. ابحث في مخازن الثقة عن جذر "AAA Certificate Services" المتروك وغير الموصى به - على سبيل المثال، ينبغي لمسؤولي FortiOS فحص قائمة CA لديهم والبحث عن "AAA" لرصد أي نسخ تم استيرادها يدوياً. 

4. التحقق من وجود أي شهادات صادرة عن emSign في بيئتكم الرقمية؛ حيث سيتم تفعيل إلغاء Chrome لجذر emSign ECC Root CA – G3 بالكامل في 27 أكتوبر 2026 - وأي اتصال يعتمد عليه سيتوقف عن العمل هذا الأسبوع. 

إجراءات قصيرة المدى (خلال 30 يوماً): 

1. تدقيق سياسات تثبيت الشهادات (Certificate Pinning) وسلوك الإلغاء في تطبيقات التكنولوجيا التشغيلية (OT). إن الأنظمة التي تتخطى التحقق من الإلغاء أو التحقق من شفافية الشهادات (CT) كانت - ولا تزال - هي الفئة الأكثر عرضة للاختراق. 

2. مراجعة آليات الوصول عن بُعد للموردين. تأكد من أن مضيفات القفز، وبوابات VPN، وخوادم البروكسي التي تنهي اتصالات TLS تعمل باستخدام حزم ثقة محدثة، وليست قوائم CA مدمجة في البرامج الثابتة منذ عام 2021. 

3. حظر كلا جذري التوقيع (Blocklist) كإجراء دفاعي متعمق: emSign Root TLS CA – G3 وجذر AAA Certificate Services التابع لـ Sectigo (وفقاً لتوجيهات Red Hat). 

إجراءات استراتيجية: 

1. الحد من انتشار وتعدد سلطات الشهادات غير الضرورية (CA Sprawl). يمثل كل جذر موثوق به سطح هجوم لا تملك السيطرة عليه. احرص على حصر إصدار الشهادات في سلطات ذات دقة وانضباط تشغيلي مثبت، وقم بتوثيق سلطات الشهادات التي يستخدمها الموردون لديك. 

2. إدراج مراقبة سلطات الشهادات ضمن برنامج استخبارات التهديدات لديك. تُعد شذوذات وتناقضات قوائم CRL، وعمليات التوقيع المتبادل غير المتوقعة، ومداولات برامج شهادات الجذر (Common CA Database وmozilla.dev.security.policy) مؤشرات إنذار مبكرة بالغة الأهمية. 

3. اختبار ومراجعة دقة مراسم المفاتيح لديكم. إذا كانت مؤسستك تدير بنية تحتية للمفاتيح العامة (PKI) داخلية - وهو ما تفعله معظم الجهات المشغلة الكبرى لـ OT لتأمين هويات الأجهزة والوصول الهندسي - فقم بتدقيق برمجيات مراسم HSM النصية، وتسميات المفاتيح، وخطوات التحكم المزدوج (Dual-control). لقد نتج فشل eMudhra عن خطأ برمجي اقترن بخطأ بشري وسوء تشخيص لإنذار مبكر؛ وهو مزيج يتكرر في العديد من أقسام PKI بالمؤسسات. 

خلاصة القول 

سيظل حادث eMudhra حاضراً في الذاكرة ليس بسبب حجم تأثيره - الذي يبدو محدوداً للغاية بفضل الاستجابة السريعة من Chrome وMozilla في أقل من ساعتين - وإنما لما كشف عنه من حقائق؛ إذ قامت سلطة شهادات مسؤولة عن أكثر من 60 مليون شهادة وتثق بها كافة برامج الجذور الرئيسية بتوليد مفاتيح توقيع تفتقر تماماً إلى العشوائية، وتركتها مكشوفة لمدة 17 شهراً، وتجاهلت إشارات التحذير الصادرة عنها، لتنهار أعمالها خلال خمسة أيام فقط من الكشف عن الحادث. 

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

في الأمن السيبراني للتكنولوجيا التشغيلية (OT)، نبذل جهوداً هائلة لتحصين النقاط الطرفية وتقسيم الشبكات. ويأتي هذا الحادث كتذكير حاسم بأن سلسلة الثقة الرقمية الأساسية - التي تشمل الشهادات وسلطات الإصدار ومراسم المفاتيح - تتطلب نفس المستوى من الدقة والصرامة؛ لأنه عندما يكون الأساس هشاً، فلن تجدي متانة الجدران نفعاً مهما بلغت قوتها. 

تعتبر Shieldworkz شركة رائدة ومتخصصة في تقديم حلول الأمن السيبراني الشاملة للتكنولوجيا التشغيلية (OT) الصناعية، حيث تتولى تأمين بيئات SCADA وOT وإنترنت الأشياء (IoT) عبر مختلف قطاعات البنية التحتية الحيوية. إذا لم تكن متأكداً مما إذا كانت بيئة OT لديك لا تزال تثق بسلاسل شهادات مخترقة - بما في ذلك النسخ الموقعة توقيعاً متبادلاً والمخفية وراء جذور Sectigo القديمة - فيمكنك [التواصل مع فريقنا الخبير] للحصول على تقييم شامل لحالة الثقة بالشهادات والبنية التحتية للمفاتيح العامة (PKI).