العودة إلى التحديثات
UpdatedSep 3, 2026

CVE-2026-25250 — Updated!

تحليل واستغلال لثغرة CVE-2026-25250، وهي تجاوز لـ Secure Boot في Horizon DataSys Reboot Restore حيث يقوم shdloader.efi بتحميل Shield.efi دون تحقق.

مشاركة

🕷️ CVE-2026-25250: التحقق غير السليم من سلسلة محمل الإقلاع الموثوقة

محمل إقلاع تابع لجهة خارجية موقّع من مايكروسوفت يقوم بتحميل ملف EFI ثانوي دون أي تحقق من التوقيع أو السلامة، مما ينهار سلسلة الثقة الخاصة بـ Secure Boot من الداخل.

📑 جدول المحتويات

🧠 السياق البحثي

يوثق هذا المستودع البحث حول CVE-2026-25250، وهي ثغرة تجاوز لـ Secure Boot تم الإبلاغ عنها لمايكروسوفت وتم تخصيص CVE لها في أبريل 2026. وسرعان ما برزت كواحدة من أهم قضايا أمان البرامج الثابتة لهذا العام، تحديدًا لأن المكوّن القابل للاستغلال موقّع من مايكروسوفت وبالتالي فهو موثوق به دون قيد أو شرط عبر الغالبية العظمى من أنظمة Windows التي تدعم UEFI.

تم اكتشاف الثغرة بواسطة Mickey Shkatov وStanislav Lyakhov في Eclypsium، أحد أبرز فرق أبحاث أمان البرامج الثابتة وسلسلة التوريد في الصناعة. Mickey Shkatov هو شخصية بارزة منذ فترة طويلة في أبحاث هجوم UEFI، ومؤلف BootHole (CVE-2020-10713، ثغرة حرجة في تجاوز Secure Boot عبر GRUB2 أثرت على كل توزيعات لينكس تقريبًا وأنظمة الإقلاع المزدوج مع Windows)، ومقدّم عرض "One Bootloader to Load Them All" في DEF CON 30 إلى جانب Jesse Michael، وهو حديث قام بشكل منهجي بتصنيف كيفية تمثيل محملات الإقلاع التابعة لجهات خارجية والموقّعة من مايكروسوفت لضعف على مستوى الفئة في نظام Secure Boot البيئي.

تقع CVE-2026-25250 مباشرة ضمن تلك الفئة.

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

📌 المراجع الرسمية

تم اكتشاف CVE-2026-25250 أثناء تحليل مكونات إقلاع UEFI التابعة لجهات خارجية والمنشورة في بيئات الاسترداد المؤسسية. المنتج المتأثر هو حل Reboot Restore من Horizon DataSys.

تم تخصيص الثغرة بواسطة MITRE وليس مايكروسوفت، لأن الخلل يكمن في برامج ثابتة تابعة لجهة خارجية (shdloader.efi)، وليس في Windows أو أي كود من تأليف مايكروسوفت.

المراجع الرسمية:

🔬 أعد إنتاج الثغرة بنفسك

إفصاح Eclypsium، المنشور على LinkedIn بواسطة فريق الاكتشاف، يوفر سياقًا كافيًا لتحديد البرنامج المتأثر وتنزيله مباشرة من موقع البائع.

مثبّت Horizon DataSys Reboot Restore متاح للجمهور، وتثبيته على نظام اختبار يضع كلاً من shdloader.efi وShield.efi في قسم نظام EFI، حيث يمكن فحصهما بشكل ثابت أو ملاحظتهما أثناء التشغيل.

إعداد المختبر الموصى به:

Windows 10/11 VM (QEMU أو VMware)
├── Secure Boot: مفعّل
├── Horizon DataSys Reboot Restore: مثبّت
├── الوصول إلى ESP عبر: mountvol X: /S
└── الأهداف:
	HorizonDataSys
        X:\EFI\shdloader.efi ← موقّع، موثوق، يحمّل المرحلة التالية
        X:\EFI\Shield.efi    ← يتم تحميله دون أي تحقق

بمجرد التثبيت، يمكن تأكيد أن shdloader.efi موقّع بـ Microsoft CA 2011 عبر sigcheck.exe (Sysinternals) أو pesign. غياب أي استدعاء LoadImage / StartImage في مسار تحميل Shield.efi يكون مرئيًا فورًا في التحليل الثابت.

🐜 سلسلة الإقلاع القابلة للاستغلال

تؤثر هذه الثغرة على سلسلة إقلاع متعددة المراحل، وليس على ملف ثنائي واحد.

🧨 المرحلة 1 - محمل الإقلاع الموثوق

  • shdloader.efi
    • موقّع رقميًا بـ Microsoft UEFI CA 2011
    • موثوق به دون قيد أو شرط بواسطة سياسة Secure Boot في البرنامج الثابت
    • مثبّت في ESP بواسطة برنامج Horizon DataSys

⚠️ المرحلة 2 - الحمولة غير الموثوقة

  • Shield.efi
    • يتم تحميله ديناميكيًا بواسطة shdloader.efi أثناء الإقلاع
    • ❌ لا يوجد تحقق من التوقيع
    • ❌ لا يوجد فحص للسلامة
    • ❌ لا استخدام لواجهات برمجة UEFI LoadImage / StartImage
    • ✅ قابل للاستبدال بحرية بواسطة أي مسؤول محلي

📌 الملاحظة الرئيسية

الثغرة لا تكمن في البرنامج الثابت. إنها تكمن في منطق محمل إقلاع موثوق، وهو ملف ثنائي وافق عليه البرنامج الثابت بالفعل، يختار تحميل ملف ثنائي ثانوي عبر مسار كود يتجاوز كل فحوصات الأمان.

Firmware
  └── يتحقق من shdloader.efi          ✅ Microsoft CA 2011، موثوق
        └── ManualPEParse(Shield.efi) ❌ لا LoadImage، لا فحص توقيع
              └── EntryPoint()        💥 كود يتحكم به المهاجم، قبل نظام التشغيل

محيط Secure Boot قوي فقط بقدر قوة أقل ملف ثنائي يثق به.

🧪 نظرة عامة على الثغرة

CVE-2026-25250 هي ثغرة تجاوز لـ Secure Boot ناتجة عن تحقق غير سليم من ملف EFI ثانوي يتم تحميله أثناء عملية الإقلاع. محمل الإقلاع المتأثر (shdloader.efi) موقّع وموثوق بواسطة Secure Boot، لكنه يحمّل Shield.efi عبر روتين تحليل PE يدوي دون أي تحقق تشفيري من أي نوع.

إنه فشل في التصميم ونموذج الثقة، مكوّن موثوق يتخذ قرارًا غير آمن يلغي جميع الحمايات اللاحقة.

🔐 Secure Boot ونموذج الثقة

يفرض Secure Boot سلسلة ثقة يتم فيها التحقق من كل مكوّن يتم تنفيذه أثناء تسلسل الإقلاع قبل نقل التحكم. النموذج يصمد فقط إذا التزم كل ملف ثنائي موثوق في السلسلة بهذا العقد:

Firmware → يتحقق من محمل الإقلاع → محمل الإقلاع ينفذ فقط الكود الموثوق

CVE-2026-25250 تكسر الحلقة الثانية:

Firmware → يتحقق من shdloader.efi (✅ موثوق)
             ↓
           shdloader.efi → يحمّل Shield.efi (❌ غير موثوق)
                             ↓
                           كود عشوائي غير موقّع يُنفَّذ قبل الإقلاع

إنفاذ Secure Boot على مستوى البرنامج الثابت يصبح غير ذي صلة بمجرد أن يقدم ملف ثنائي موثوق مسار تنفيذ غير موثوق.

🧬 تحليل السبب الجذري

مصنّف كالتالي:

الخطوةتم تنفيذهاملاحظات
تحديد موقع Shield.efi على ESP✅وصول قياسي لنظام الملفات
قراءة الملف في الذاكرة✅-
تحليل ترويسات PE يدويًا✅تنفيذ مخصص
التحقق من التوقيع❌لم يتم تنفيذه
الفحص مقابل db / dbx❌لم يتم تنفيذه
استدعاء LoadImage / StartImage❌تم تجاوزه بالكامل
نقل التنفيذ إلى نقطة الدخول✅استدعاء مباشر

غياب LoadImage / StartImage هو السبب الجذري. خدمات الإقلاع UEFI هذه هي نقطة التكامل لإنفاذ سياسة Secure Boot، وتجاوزها يعني تجاوز كل شيء.

💥 عملية الاستغلال

يتطلب الاستغلال وصول مسؤول محلي وإعادة تشغيل واحدة.

  1. قم بتركيب قسم نظام EFI
  2. استبدل Shield.efi بملف EFI ثنائي عشوائي غير موقّع
  3. أعد التشغيل

عند الإقلاع التالي، يتم تنفيذ shdloader.efi (موثوق بواسطة البرنامج الثابت)، ويحمّل الملف الثنائي الذي يتحكم به المهاجم، وينقل التنفيذ، قبل نظام التشغيل، قبل EDR، قبل إنفاذ أي سياسة إقلاع مُقاسة، دون أي اعتراض من Secure Boot.

يتيح:

  • Bootkits UEFI دائمة تنجو من إعادة تثبيت نظام التشغيل ومسح القرص الكامل.
  • غرسات في مرحلة مبكرة غير مرئية لأي أدوات أمان على مستوى نظام التشغيل.
  • تهرب كامل من حمايات وضع النواة (EDR، PatchGuard، VBS/HVCI).

📚 الموارد

🤝 البحث والتعاون

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

اقرأ المزيد

الفئات

آليات الاستمراريةتحليل الثغرات الأمنيةالاستغلالتحليل الملفات الثنائيةالتعلم والتعليمتحليل البرامج الثابتة