themalwareguardian/cve-2026-79298مستودع بحثي يوثّق CVE-2026-79298، وهو إصلاح غير مكتمل لتجاوز UEFI Secure Boot في مسار الإقلاع IA-32 الخاص بـ Howyar SysReturn، مع مواد الهندسة العكسية وإثبات المفهوم.
تم ترقيع ثغرة أمنية. وتم إبطال ملف ثنائي. لكن نصف البنية فقط هو ما تم إصلاحه. بعد ثمانية عشر شهرًا، كان مسار الإقلاع IA-32 لا يزال يحمل نفس محمّل PE المخصص، ونفس التحقق المتجاوز من Secure Boot، ونفس تجزئة Authenticode المُبطلة - يُشحن تجاريًا في كل نسخة من SysReturn NetCopy حتى يوليو 2026. هذه هي CVE-2026-79298.
أنا باحث في الأمن الهجومي متخصص في استغلال ثغرات UEFI firmware، وتطوير bootkit/rootkit، وبحوث الثغرات الأمنية. هذا هو المجال الذي اخترت أن أكرّس له مسيرتي المهنية، وهو ما يشكّل كل ما أنشره.
شاركت في تأليف كتاب UEFI Bootkits and Kernel-Mode Rootkits Development - وهو كتاب رائد في تطوير البرمجيات الخبيثة الهجومية على مستوى firmware. قمت ببناء وإصدار Abyss، وهو bootkit كامل لـ Windows UEFI، و**Antarctic، وهو أول إطار عمل bootkit لـ UEFI متاح للعموم لنظام Linux. كلاهما أدوات مفتوحة المصدر مصممة لمشغّلي الفرق الحمراء والباحثين الأمنيين لفهم ومحاكاة والدفاع ضد تهديدات firmware الواقعية. وإلى جانبهما، طوّرت Benthic، وهو rootkit لنواة Windows، وBehemoth**، وهي أداة للتحليل الآلي لملفات UEFI الثنائية.
بناء أدوات هجومية على هذا المستوى يعني فهم ليس فقط كيفية عمل bootkits، بل كيفية تثبيتها. وهنا يأتي دور ثغرات UEFI. كل تجاوز لـ Secure Boot، وكل bootloader موقّع بشكل غير صحيح، وكل محمّل PE مخصص يتخطى التحقق - هذه هي الأبواب التي تمر عبرها البرمجيات الخبيثة على مستوى firmware. إن البحث عن تلك الثغرات واستغلالها هو امتداد طبيعي لهذا العمل. لا يمكنك بناء أدوات هجومية واقعية دون فهم سطح الهجوم الحقيقي.
هذا المسار البحثي - تطوير برمجيات UEFI الخبيثة، ثم دراسة الثغرات التي تتيح نشرها - هو ما قادني إلى CVE-2024-7344 وفي النهاية إلى النتائج الموثّقة هنا.
في يناير 2025، نشر Martin Smolár وفريق ESET Research إفصاحًا عن CVE-2024-7344 (Under the cloak of UEFI Secure Boot)، وهو تجاوز لـ Secure Boot يؤثر على عدة منتجات لبرمجيات الاستعادة، بما في ذلك Howyar SysReturn. كانت الثغرة ناتجة عن تطبيق UEFI موقّع من Microsoft نفّذ محمّل PE المخصص الخاص به (RxPE)، متجاوزًا بذلك خدمتي LoadImage وStartImage القياسيتين بالكامل. فبدلاً من الاعتماد على التحقق المدمج من Secure Boot في firmware، قام التطبيق بتحليل وتنفيذ حمولة غير موقّعة يدويًا من ملف يُسمى cloak.dat، مشفّر بـ XOR بمفتاح من بايت واحد، دون أي فحص للتوقيع، وبثقة كاملة على مستوى firmware.
أبطلت Microsoft الملفات الثنائية المتأثرة في تحديث Patch Tuesday لشهر يناير 2025. نُشر التنبيه. ومضى المجتمع الأمني قدمًا. لكنني لم أفعل.
لقد أمضيت سنوات في دراسة ثغرات UEFI - ليس فقط CVE-2024-7344، بل المشهد بأكمله لتجاوزات Secure Boot، ومحمّلات PE المخصصة، والعيوب على مستوى التصميم في مكونات UEFI الموقّعة. وهناك نمط رأيته مرارًا وتكرارًا: نفس فئات قرارات التصميم الخاطئة تظهر من جديد عبر البائعين وعبر السنوات. تُفصح عن ثغرة، ويُبطل ملف ثنائي، وبعد أشهر أو سنوات يظهر عيب مشابه - أحيانًا في نفس المنتج، وأحيانًا في منتج مختلف من نفس البائع، وأحيانًا في قاعدة كود بائع مختلف تمامًا يتشارك نفس الافتراضات المعمارية.
هذا النمط جعلني أطرح سؤالًا أعتقد أن صناعة الأمن لا تطرحه كثيرًا بما يكفي:
كيف يبدو المنتج بعد CVE؟ ليس خلال اندفاع الترقيع - بل بعد ثمانية عشر شهرًا، عندما لا يراقب أحد بعد.
قررت أن أكتشف ذلك. والمنتج الذي اخترته كان Howyar SysReturn.
تواصلت مع Howyar Technologies مباشرة وحصلت على نسخة تقييم من SysReturn لتقييم شراء احترافي - وهو سياق مشروع نشأ من عمل واقعي لتقييم برمجيات الاستعادة لعمليات نشر تعليمية واسعة النطاق.
ما وجدته في SysReturn v11.2.031، الصادر في أبريل 2026 - أي بعد أكثر من خمسة عشر شهرًا من إبطال Microsoft - أكّد بالضبط ما كان النمط يشير إليه.
كان قد تمت معالجة مسار الإقلاع x64. لكن مسار الإقلاع IA-32 لم تتم معالجته قط. الملف الثنائي BOOTia32.efi، الموزّع كجزء من ميزة SysReturn NetCopy، كان لا يزال يحتوي على نفس محمّل PE المخصص (RxPE)، ولا يزال يحمّل حمولات غير موقّعة من ملف يُسمى cloak32.dat باستخدام نفس تنسيق ALRM وتشفير XOR بمفتاح من بايت واحد، ولا يزال يحمل نفس تجزئة Authenticode التي أبطلتها Microsoft في يناير 2025.
لم يتم إصلاح السبب الجذري أبدًا في معمارية IA-32. ما تغيّر كان تشغيليًا - تم تحديث مسار x64، وتمت معالجة الضغط الفوري الناتج عن الإفصاح - لكن البنية الأساسية ظلت دون مساس في المكوّن 32-بت، وتُشحن تجاريًا في كل نسخة من المنتج.
| الحقل | التفصيل |
|---|
| معرّف CVE | CVE-2026-79298 |
| نوع الثغرة | معالجة غير مكتملة لتجاوز UEFI Secure Boot (CWE-693: فشل آلية الحماية) |
| البائع | Howyar Technologies Inc. |
| المنتج | SysReturn (ميزة NetCopy) |
| الإصدارات المتأثرة | الإصدارات الأقدم من 11.3.034 (مؤكّد في v11.2.031 وv11.3.033) |
| الإصدار المُصلح | v11.3.034 (يوليو 2026) |
| المكوّن المتأثر | BOOTia32.efi (تطبيق UEFI IA-32 موقّع من Microsoft)، محمّل PE المخصص RxPE (UEFI\RxPE.cpp)، cloak32.dat (حمولة مشفّرة بـ XOR بتنسيق ALRM) |
| نوع الهجوم | محلي |
| التأثير | تنفيذ تعليمات برمجية عشوائية، تصعيد الصلاحيات |
| ناقل الهجوم | يمكن لمهاجم لديه صلاحية الكتابة على EFI System Partition (مسؤول محلي على Windows، أو root على Linux) وضع BOOTia32.efi وcloak32.dat مُصمّم خصيصًا على ESP. عند إعادة التشغيل، ينفّذ الملف الثنائي الحمولة غير الموقّعة عبر RxPE، متجاوزًا التحقق من Secure Boot بالكامل. يتطلب نظام IA-32 UEFI مع تفعيل Secure Boot يثق في Microsoft Corporation UEFI CA 2011 ولم يطبّق تحديث إبطال dbx لشهر يناير 2025. |
| إقرار البائع | مؤكّد. أقرّ البائع خلال الإفصاح المنسّق بأن مسار الإقلاع IA-32 لم يُدرج قط في المعالجة الأصلية لـ CVE-2024-7344. |
أُجريت عملية الإفصاح المنسّق عن هذه الثغرة مباشرة مع Howyar Technologies على مدى فترة تقارب شهرين.
ملخص الجدول الزمني:
تم إعادة إنتاج تجاوز Secure Boot ديناميكيًا باستخدام QEMU/OVMF IA-32 مع تفعيل Secure Boot. جميع عناصر إعادة الإنتاج الكاملة، وتوثيق الهندسة العكسية، والتحقق من تجزئة Authenticode، ومواد إثبات المفهوم، وكل بريد إلكتروني تم تبادله خلال عملية التنسيق مُدرجة في مستودع البحث الأساسي.
تم تعيين معرّف CVE هذا بعد أن كان البحث قد أُجري بالفعل، ووُثّق، وشارك عبر مستودعين مخصصين. تحتوي تلك المستودعات على العمق التقني الكامل - الملفات الثنائية القابلة للاستغلال، والهندسة العكسية، ومراسلات البائع، وأدوات إثبات المفهوم، ومواد إعادة الإنتاج. يعمل هذا المستودع كنقطة دخول مفهرسة بـ CVE تربط كل شيء معًا.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
هذا هو مستودع البحث الأساسي. يحتوي على:
BOOTia32.efi، cloak32.dat، والمكونات ذات الصلة)BOOTia32.efi: تنسيق حمولة ALRM، وفك تشفير XOR، ومحمّل PE المخصص RxPE، والتحقق من تجزئة Authenticode مقابل الملف الثنائي المُبطل، وتحليل ما تم تغييره مقابل ما تُرك دون مساسdecode_cloak.py، authenticode_hash.py، create_cloak.py)هذا هو المستودع المرافق الذي يوثّق الثغرة الأصلية التي تنبع منها CVE-2026-79298. يحتوي على:
هل تعمل على شيء مشابه؟ هل تبحث في UEFI، أو أمن النواة، أو الاستغلال، أو موضوع أمني آخر مثير للاهتمام؟ إذا كنت بحاجة إلى مساعدة في تطوير استغلال، أو استكشاف تقنية، أو ترغب فقط في تبادل الأفكار، فلا تتردد في التواصل. أنا دائمًا منفتح لمناقشة البحث، والمساعدة حيث أستطيع، والتعاون في مشاريع مثيرة للاهتمام.
لا تتردد في التواصل معي على LinkedIn.