تحليل واستغلال CVE-2025-4275 (Hydr0ph0bia)، وهو ضعف في سلسلة الثقة الخاصة بـ Secure Boot حيث تُستخدم متغيرات البرامج الثابتة لإدخال شهادات يتحكم فيها المهاجم وتكون موثوقة من قِبل مكونات الإقلاع اللاحقة.
يحتوي هذا المستودع على مواد بحثية متعلقة بـ CVE-2025-4275، وهي ثغرة تجاوز Secure Boot تؤثر على البرامج الثابتة المتوافقة مع UEFI والمبنية على Insyde H2O. وهو يركّز التحليل التقني للثغرة، والملفات الثنائية المتضمنة في المشكلة، بالإضافة إلى الوثائق والأدوات التي تهدف إلى مساعدة الباحثين على فهم هذه الثغرة ودراستها والتجريب بها بشكل أفضل في السياقات الواقعية والتعليمية على حد سواء.
تم اكتشاف CVE-2025-4275 في الأصل والإفصاح عنه بمسؤولية من قبل Nikolaj Schlej، مع تنسيق تم عبر CERT/CC. المراجع الرسمية والمجتمعية:
CVE-2025-4275، الملقّبة بـ Hydroph0bia (تلاعب لفظي على Insyde H2O)، هي ثغرة تجاوز Secure Boot تؤثر على البرامج الثابتة المتوافقة مع UEFI والمبنية على منصة Insyde H2O. تنبع الثغرة من خلل تصميمي في النظام الفرعي لتحديث البرامج الثابتة: شهادة توقيع يُفترض تحميلها في متغير NVRAM متطاير بواسطة برنامج تشغيل موثوق يمكن بدلاً من ذلك تعبئتها مسبقًا كمتغير غير متطاير من قبل المهاجم، مما يجعل البرنامج الثابت يثق بشيفرة خارجية عشوائية كما لو كانت موقّعة من Insyde نفسها.
ما يجعل هذه الثغرة ذات تأثير بالغ بشكل خاص هو الجمع بين بساطتها ومداها. لا يتطلب الاستغلال سوى صلاحيات مسؤول محلي، وهو ما يكفي لكتابة ملفات إلى EFI System Partition وإنشاء متغيرات NVRAM، ويؤثر على أي نظام يعمل ببرنامج ثابت Insyde H2O مبني قبل 10 يونيو 2025. الهجوم مستقل عن الشركة المصنعة (OEM-agnostic)، مما يعني أنه ينطبق على نطاق واسع عبر Acer و Dell و Framework و Fujitsu و HP و Huawei و Lenovo وأي بائع آخر يوفّر برامج ثابتة مبنية على Insyde.
يوفّر UEFI واجهة مجرّدة لتخزين المتغيرات غير المتطايرة تُعرف باسم NVRAM. من الخصائص الغريبة القديمة لهذه الواجهة أن متغيرًا غير متطاير باسم و GUID محددين يمكن أن يتواجد جنبًا إلى جنب مع متغير متطاير بنفس الهوية، ويظلله. إذا كانت الشيفرة تتوقع متغيرًا متطايرًا (يُنشأ في وقت التشغيل بواسطة برنامج تشغيل موثوق) لكن متغيرًا غير متطاير بنفس الاسم موجود بالفعل، فقد يتم استهلاك النسخة غير المتطايرة بدلاً منه. هذا السلوك، الذي يُسمى أحيانًا تظليل متغيرات NVRAM، هو أساس هذه الثغرة.
يعتمد النظام الفرعي لتحديث البرامج الثابتة في Insyde H2O على متغيرَي NVRAM لنقل شهادة توقيع بين برامج التشغيل:
في التدفق المتوقع، يُنشأ كلا المتغيرين كمتغيرات متطايرة بواسطة BdsDxe أثناء عملية تحديث البرامج الثابتة. ثم يستهلكهما SecurityStubDxe للتحقق من أن isflash.bin موقّع بشهادة Insyde قبل السماح بتنفيذه. الخلل الحرج هو أن SecurityStubDxe لا يتحقق مما إذا كانت هذه المتغيرات متطايرة أم غير متطايرة قبل الوثوق بمحتوياتها.
السبب الجذري لـ CVE-2025-4275 هو أن SecurityStubDxe يستخدم دالة مكتبة عامة لقراءة SecureFlashSetupMode و SecureFlashCertData بدلاً من استدعاء خدمة GetVariable وقت التشغيل مباشرة. وهذا يعني أنه لا يستطيع التمييز بين متغير متطاير تضبطه BdsDxe موثوقة ومتغير غير متطاير يعبّئه المهاجم مسبقًا (للحصول على شرح مفصّل لهذه التقنية تحديدًا، راجع المستودع التالي "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
ونتيجة لذلك، يمكن لمهاجم يمتلك صلاحيات مسؤول محلي:
عند الإقلاع التالي، سيجد SecurityStubDxe كلا المتغيرين، ويعاملهما كشرعيين، ويثق بأي ملف تنفيذي UEFI موقّع بشهادة المهاجم، متجاوزًا بذلك Secure Boot بالكامل. لا يُشترط أي تفاعل على مستوى البرنامج الثابت، أو وصول إلى العتاد، أو استغلال لبدائية إفساد الذاكرة. سطح الهجوم هو ببساطة واجهة كتابة UEFI NVRAM، المتاحة من جلسة نظام تشغيل ذات صلاحيات.
تم اكتشاف الثغرة أثناء مراجعة أمنية لجهاز HUAWEI MateBook 14 2023، يعمل ببرنامج ثابت مبني على Insyde H2O مع تفعيل Secure Boot وكلمة مرور البرنامج الثابت وميزات أمنية حديثة أخرى. وعلى الرغم من هذه الحمايات، تم تحقيق الاستغلال الكامل باستخدام صلاحيات مسؤول على مستوى نظام التشغيل فقط.
تتطلب مرحلة الاستغلال الأولية أداة Windows صغيرة (SFCD) تقوم بما يلي:
بعد إعادة التشغيل، يقرأ SecurityStubDxe كلا المتغيرين ويبدأ بالثقة بأي شيء موقّع بشهادة المهاجم. من الأمثلة العملية على هذه المرحلة الأولى تحميل برنامج تشغيل UEFI مخصص باسم CrScreenshotDxe موقّع بشهادة مخصصة، والذي ينجح في التقاط لقطة شاشة لشاشة إعداد BIOS، مع تفعيل Secure Boot، كدليل على تنفيذ شيفرة عشوائية في بيئة البرنامج الثابت.
ملاحظة مهمة: غالبًا ما يكون متغير IhisiParamBuffer الموجود في CVE-2025-3052 مقفلًا على المنصات المبنية على Insyde، مما يجعل الاستغلال المباشر أصعب هناك. لا يتطلب CVE-2025-4275 أن يكون أي متغير من هذا القبيل قابلًا للكتابة ولا يعتمد على أي بدائية إفساد للذاكرة. يعمل الهجوم على أي نظام Insyde H2O يستطيع فيه المهاجم الكتابة إلى NVRAM، وهو السلوك الافتراضي على البرامج الثابتة غير المصحّحة.
يصف ما يلي الهجوم من البداية إلى النهاية لمرحلة تجاوز Secure Boot الأولية، بافتراض مهاجم ذي صلاحيات ووصول على مستوى نظام التشغيل:
يفتح تجاوز Secure Boot المحقق في الجزء 1 الباب لمرحلة ثانية ذات تأثير أكبر بكثير: الاستيلاء الكامل على وحدة تخزين DXE، ويُحقَّق ذلك عبر اختطاف عملية تحديث البرامج الثابتة في Insyde نفسها.
يعمل النظام الفرعي لتحديث البرامج الثابتة في Insyde H2O على النحو التالي: يضع محدّث نظام التشغيل كبسولة البرنامج الثابت وتطبيق التحديث الموقّع (isflash.bin) على EFI System Partition، ثم يضبط علم SecureFlashTrigger=1 داخل متغير NVRAM المسمى SecureFlashInfo. عند الإقلاع التالي، يكتشف البرنامج الثابت المشغّل، ويعطّل حمايات الكتابة إلى الفلاش أثناء PEI، ثم يستدعي في النهاية LoadImage على isflash.bin بعد التحقق منه مقابل شهادة Insyde، وهي نفس آلية الشهادة التي يسمح CVE-2025-4275 للمهاجم باستبدالها.
هناك ثلاث خطوات تقنية إضافية مطلوبة للتصعيد من تجاوز Secure Boot إلى الاستيلاء على DXE:
بمجرد استيفاء الشروط الثلاثة، يعيد البرنامج الثابت الإقلاع إلى وضع التحديث، ويحمّل ملف isflash.bin المخصص للمهاجم (الموقّع بشهادة المهاجم، التي أصبحت موثوقة الآن بسبب SecureFlashCertData المظلَّل)، وينفّذه مع فلاش SPI غير محمي. من هذا الموقع، يمكن للمهاجم كتابة محتوى عشوائي إلى وحدة تخزين DXE، وتثبيت برامج تشغيل دائمة أو تعديل مكونات البرنامج الثابت بطرق تصمد أمام إعادة تثبيت نظام التشغيل ومعظم الضوابط الأمنية.
أصدرت Insyde إصلاحًا كجزء من دورة تصحيحات 10 يونيو 2025. تم تحليل الإصلاح بمقارنة تحديثَي BIOS متتاليين من Dell (أحدهما قبل التصحيح والآخر بعده) باستخدام تقارير مولّدة بواسطة UEFITool ومقارنة ثنائية عبر Diaphora.
تركزت التغييرات في ثلاثة برامج تشغيل:
الإصلاح فعّال بافتراض أن المهاجم لا يستطيع تجاوز VariablePolicy أو LibSetSecureVariable. ومع ذلك، يستخدم التنفيذ الافتراضي لـ VariablePolicy في EDK2 علمًا عامًا داخليًا، وهو مشابه بنيويًا لـ InsydeVariableLock الذي أُبطل في الجزء 2. كما أن تحرير NVRAM فيزيائيًا عبر عتاد برمجة SPI سيتجاوز الإصلاح بالكامل، رغم أن الهجمات الفيزيائية تُعتبر تقليديًا خارج نطاق نماذج تهديد Secure Boot.
المعالجة الموصى بها من الباحث، أي إزالة NVRAM بالكامل من آلية تمرير الشهادة بين BdsDxe و SecurityStubDxe، حاولت Insyde تنفيذها لكنها تسببت في تراجعات وأُجّلت إلى دورة هندسية مستقبلية.
أي بائع يوفّر برامج ثابتة مبنية على Insyde H2O ومبنية قبل 10 يونيو 2025 قد يكون متأثرًا. الحالة المؤكدة وقت الإفصاح:
| البائع | الحالة |
|---|
| Dell | مُصلَّح - أُصدرت تحديثات BIOS بعد وقت قصير من انتهاء الحظر |
| Lenovo | معرّض للثغرة - أُعلنت الإصلاحات، والتسليم من 2025-07-30 فصاعدًا |
| Framework | معرّض للثغرة - لم يُقدَّم تقدير للتسليم وقت الإفصاح |
| Acer | لم يُنشر أي إشعار أو إصلاح وقت الإفصاح |
| Fujitsu | لم يُنشر أي إشعار أو إصلاح وقت الإفصاح |
| HP | لم يُنشر أي إشعار أو إصلاح وقت الإفصاح |
| Huawei | بائع جهاز الاختبار الأصلي - حالة الإصلاح غير معروفة |
هل تعمل على شيء مشابه؟ هل تبحث في أمن UEFI أو Kernel أو الاستغلال أو موضوع أمني آخر مثير للاهتمام؟ إذا كنت بحاجة إلى مساعدة في تطوير استغلال، أو استكشاف تقنية، أو مجرد تبادل الأفكار، فلا تتردد في التواصل. أنا دائمًا منفتح لمناقشة الأبحاث، والمساعدة حيث أستطيع، والتعاون في المشاريع المثيرة للاهتمام. لا تتردد في التواصل معي على LinkedIn.
