في خطوة مهمة، قامت مايكروسوفت بإصلاح ثغرات Secure Boot التي كانت موجودة منذ عام 2013، مما يعكس أهمية تحديثات الأمان في عالم التكنولوجيا المتطور.
لماذا يهم الأمر:
تعود نقطة الضعف المستمرة في نظام أمان الكمبيوتر الرئيسي إلى مشكلة أبسط: مكونات قديمة لم يتم إلغاؤها. وقد وجدت أبحاث ESET أن مجموعة من محملات الإقلاع “shim” الضعيفة – بعضها يعود إلى عام 2013 – ظلت موثوقة من قبل مايكروسوفت لسنوات بعد أن كانت عيوبها معروفة. ونتيجة لذلك، كان بإمكان المهاجمين تجاوز Secure Boot على كل من أنظمة ويندوز ولينكس بسهولة نسبية.
التأثيرات العملية
تؤثر المشكلة على 11 ثنائيًا من shims كانت لا تزال موقعة ومقبولة من قبل الأنظمة التي تفرض Secure Boot. تلك التوقيع هو ما يسمح بتشغيل الشيفرة خلال عملية الإقلاع. إذا تم اختراق مكون موثوق، يمكن أن تتأثر كل ما يلي.
كتب الباحث في ESET، مارتن سمولار: “ما يجعل هذه الشيمات القديمة خطيرة ليس ثغرة جديدة، بل إنه لا حاجة إلى ثغرة جديدة لتجاوز UEFI Secure Boot. يحتاج المهاجم فقط إلى نسخة من ثنائي shim قديم، لا يزال موثوقًا، ولكن لم يتم إلغاؤه، وفهم أساسي لكيفية عمل shims UEFI. وهذا يكفي لتجاوز ميزة أمان أساسية مثل UEFI Secure Boot.”
يمكن للمهاجم استخدام أحد هذه الشيمات لتحميل برامج ضارة قبل بدء نظام التشغيل. يمكن أن تبقى هذه الأنواع من البرمجيات الضارة حتى بعد إعادة تثبيت نظام التشغيل أو حتى تغييرات الأجهزة مثل استبدال القرص الصلب.
تاريخ Secure Boot
تم تقديم Secure Boot في عام 2012 لمنع هذا النوع من الهجمات. يعمل عن طريق مطالبة كل جزء من الشيفرة في سلسلة الإقلاع بأن يكون موقّعًا من قبل سلطة موثوقة. تعمل مايكروسوفت كجذر للثقة في النظام، حيث تقوم بتوقيع محمل الإقلاع الخاص بها وshims المستخدمة من قبل لينكس وبرامج أخرى.
تعتبر shims في الأساس حلاً يسمح للبرامج غير التابعة لمايكروسوفت بالعمل في بيئة Secure Boot. بمجرد أن تقوم مايكروسوفت بتوقيع shim، يمكنها الموافقة على مكونات أخرى باستخدام شهاداتها المدمجة.
مشكلات الثغرات
تأتي الشيمات المتأثرة من مجموعة من المصادر، بما في ذلك بائعي لينكس مثل Red Hat وopenSUSE وOracle، بالإضافة إلى بعض الأدوات الخارجية. تم إنشاء بعضها قبل وجود حماية جديدة مثل SBAT وقوائم حظر MOK. تحتوي أخرى على أخطاء أو تسمح بتحميل مكونات معروفة بأنها ضعيفة.
أشارت ESET إلى أحد shims من Oracle الذي يسمح بتشغيل ثنائي ضعيف ضد CVE-2015-5381، مشيرة إلى أن استغلاله يتطلب مهارة نسبية قليلة.
تعقيد Secure Boot
جزء من المشكلة هو مدى تعقيد Secure Boot. يعتمد النظام على عدة طبقات – قواعد بيانات التوقيع الموثوقة، قوائم الإلغاء، وضوابط قائمة على الإصدارات مثل SBAT – لتحديد ما يمكن تشغيله. يجب تحديث كل جزء وصيانته بشكل صحيح.
“باختصار، حيث تقوم dbx بإلغاء الثنائيات، تقوم SBAT وSVN Secure Boot من مايكروسوفت بإلغاء الإصدارات،” أوضح سمولار.
يتضمن كل مكون إقلاع بيانات وصفية مع رقم إصدار، ومن المفترض أن تقوم الأنظمة بحظر أي شيء أقدم من عتبة محددة. ولكن هذا يعمل فقط إذا تم تحديث تلك العتبات.
حتى انتهاء صلاحية الشهادة المستخدمة من قبل مايكروسوفت لتوقيع هذه الشيمات لم يمنعها تلقائيًا، مما يبرز مدى اعتماد النظام على الإلغاء النشط بدلاً من انتهاء الصلاحية المدمجة.
الأنظمة التي قامت بتثبيت تلك التحديثات لم تعد عرضة للخطر على ويندوز، بينما يُنصح مستخدمو لينكس بالتحقق مع توزيعاتهم أو استخدام أدوات مثل fwupd للتأكد من أنهم محميون.
المخاوف الأكبر
المخاوف الأكبر هي ما يقوله هذا عن النظام ككل. لقد أثبتت إدارة الثقة عبر العديد من المكونات والبائعين والتحديثات أنها صعبة.
قال إتش دي مور، الرئيس التنفيذي ومؤسس runZero، في مقابلة: “هذا انتقاد قوي لنموذج الإقلاع الآمن بأكمله.” وأكد أن هناك العديد من المكونات الموقعة التي لا تزال تُتبع بشكل ضعيف ويمكن استخدامها بطرق غير مقصودة. “النتيجة النهائية هي عدد هائل من الأشياء الموقعة (لا يعرفها أحد سوى مايكروسوفت) التي تتجاوز Secure Boot – وبعضها يمكن استخدامه بعد ذلك لتشغيل أشياء أخرى – ولديها أخطاء أمان عادية وأخطاء أخرى تعني أنها يمكن استخدامها لتشغيل أي شيء تقريبًا،” أضاف مور. “النظام البيئي بأكمله معطل إلى حد ما ويحتاج إلى إعادة تشغيل.”
تظهر هذه الحادثة ضرورة إدارة الثقة في الأنظمة المعقدة، مما يستدعي إعادة تقييم شامل لنموذج Secure Boot لضمان سلامة الأجهزة والبرامج.
