تطوير هجمات BYOVD: استغلال برمجيات التعريف الضعيفة دون عتادها المادي

مقدمة تحليلية

تمثل هجمات "جلب برمجيات التعريف الضعيفة" المعروفة باسم BYOVD (Bring Your Own Vulnerable Driver) واحدة من أكثر التكتيكات الهجومية فتكاً ببيئات تشغيل Windows الحديثة. تسجل هذه الهجمات أولوية قصوى تبلغ 9.5 درجة من حيث الخطورة والأهمية الأمنية، نظراً لقدرتها على تجاوز ضوابط الأمان الصارمة على مستوى النواة (Kernel Mode) وتدمير آليات الدفاع مثل حلول الكشف والاستجابة لنقاط النهاية EDR. ومع ذلك، لطالما واجه الباحثون والمهاجمون عقبة تقنية كبرى تسمى "بوابات العتاد" (Hardware-Gating)، حيث تتطلب العديد من برمجيات التعريف وجود مكونات مادية محددة لتفعيل كود الاستغلال البرمجي والوصول إلى الثغرات الكامنة فيها.

في هذا التحليل المعمق المستند إلى تجارب حية على نظام التشغيل Windows 11 الإصدار 23H2 (رقم البناء 10.0.22631.3007)، نفكك المنهجية التقنية التي تتيح تجاوز هذه البوابات المادية بالكامل ومحاكاتها برمجياً من وضع المستخدم (User Mode) فقط، ودون الحاجة لأي وصول إلى العتاد الأصلي أو بيئات المحاكاة الافتراضية المعقدة Hypervisor. يهدف هذا البحث إلى تغيير النموذج المتبع في تقييم أسطح الهجوم عبر توضيح كيف يمكن جعل الثغرات البرمجية في النواة قابلة للاستغلال الفوري حتى في غياب الأجهزة المادية المرتبطة بها.

التحليل التقني

لفهم كيفية تفكيك بوابات العتاد، يجب أولاً دراسة دورة حياة كائنات الأجهزة (Device Objects) وبنية Plug and Play (PnP) في نظام تشغيل Windows. عندما يتم تحميل برمجيات التعريف التقليدية غير المتوافقة مع PnP، يتم إنشاء كائن الجهاز التحكمي (CDO) مباشرة من دالة المدخل الرئيسية DriverEntry. لكن في برمجيات التعريف المتوافقة مع PnP، يتم تأجيل عملية إنشاء الأجهزة وإعداد المتغيرات الداخلية إلى مرحلة لاحقة يتم استدعاؤها بواسطة دالة AddDevice (أو EvتDriverDeviceAdd في بيئات KMDF) والمنوطة بالتعامل مع كائنات الأجهزة الوظيفية (FDO) وكائنات التصفية (Filter DO).

يتم تخزين مؤشر دالة AddDevice داخل بنية DRIVER_EXTENSION عند الإزاحة 0x8، والتي يتم الوصول إليها عبر مؤشر بنية DRIVER_OBJECT عند الإزاحة 0x30. عندما يكتشف مدير المكونات المادية عتاداً جديداً، فإنه يقوم باستدعاء دالة AddDevice وتمرير كائن الجهاز المادي (PDO) كمعامل ثانٍ. داخل هذه الدالة، تجري العمليات الحيوية التالية التي يعتمد عليها الاستغلال:

• استدعاء دالة IoCreateDevice لإنشاء كائن الجهاز الوظيفي (FDO).
• تخصيص وتهيئة بنية Device Extension الخاصة بكل كائن جهاز (الموجودة عند الإزاحة 0x40 من كائن DEVICE_OBJECT)، حيث تحتفظ برمجيات التعريف بالمتغيرات الداخلية التي تفرّق بين مسارات التنفيذ الآمنة والضعيفة.
• ربط كائن الجهاز الجديد بسلسلة كائنات الأجهزة عبر استدعاء IoAttachDeviceToDeviceStack.
• تسجيل واجهات الأجهزة الفرعية وتسجيل معالجات رسائل المقاطعة والوصول المباشر للذاكرة DMA.

تكمن الخطورة التقنية في أن استدعاء AddDevice لا يتم تلقائياً بمجرد تحميل برمجية التعريف باستخدام أوامر مثل sc.exe المعتادة، بل يتطلب إشارة من مدير PnP. لتجاوز هذا القيد برمجياً من وضع المستخدم، يعمد المهاجمون إلى توليد أجهزة برمجية افتراضية مع محاكاة المعرف المادي (Hardware ID) لبرمجية التعريف المستهدفة.

عند تفعيل برمجية التعريف، تبدأ بعض الأكواد في إجراء فحص مباشر وتفاعل نشط مع العتاد عبر واجهات متعددة قد تبدو للوهلة الأولى عصية على التخطي بدون الشريحة الفيزيائية:

• واجهة Memory-Mapped I/O (MMIO) عبر استدعاء MmMapIoSpace لقراءة سجلات اللوحة الأم.
• سجلات فحص منافذ الدخل والخرج القديمة x86 Port I/O من خلال READ_PORT_UCHAR و WRITE_PORT_UCHAR.
• الوصول إلى مساحة تكوين ناقل المكونات الطرفية PCI Configuration Space باستخدام HalGetBusDataByOffset.
• تقييم توجيهات لوحة التحكم بالطاقة ACPI عبر طلبات الأجهزة البرمجية IOCTL_ACPI_EVAL_METHOD.

لمراقبة سلوك برمجية التعريف والتحقق من مدى نجاح محاكاة العتاد، تبرز أداة NtObjectManager كأداة لا غنى عنها للباحثين الأمنيين. من خلال تتبع الدليل \Devices قبل وبعد عملية التحميل الاصطناعي ومقارنة الفوارق، يظهر بوضوح كيف تفتح منافذ جديدة للاتصال. كما يمكن استخراج لغة تعريف واصف الأمان (SDDL) للتحقق من صلاحيات الوصول والتأكد من إمكانية فتح مقبض (Handle) آمن من رتبة المستخدم العادي لتمكين الاستغلال البرمجي السلس.

لتوضيح سيناريو بوابات العتاد، لنتأمل برمجية تعريف تستخدم MMIO للوصول إلى سجل رقمي معين للتحقق من هوية الشريحة (Chip ID) قبل السماح بتمرير ميزة الكتابة العشوائية في الذاكرة المادية. إذا قامت البرمجية بقراءة الإزاحة BAR_SIZE وتلقت قيمة فارغة أو خاطئة لعدم وجود العتاد، فسينتهي التنفيذ ولن يصل المهاجم إلى الثغرة. ولكن، من خلال استغلال آليات محاكاة ناقل الأجهزة البربجي المتاحة محلياً في Windows، يمكن صياغة كائنات أجهزة وهمية تخدع برمجية التعريف وتوفر الاستجابات المتوقعة للتحقق من المعرّف الفريد، مما يجعل كود الكتابة العشوائية قابلاً للتنفيذ الفوري.

السياق وتأثير السوق

تاريخياً، ارتبطت هجمات BYOVD باستخدام أدوات شائعة مثل Terminator وأدوات برمجيات تعريف الألعاب ومضادات الفيروسات القديمة (مثل برمجيات gdrv.sys و zam64.sys). تعتمد هذه الأدوات على برمجيات تعريف تقدم وصولاً غير مقيد للقراءة والكتابة في الذاكرة الفيزيائية بشكل مباشر دون شروط معقدة. ومع قيام مايكروسوفت بتوسيع قوائم الحظر النشطة وتفعيل ميزات مثل سلامة الرمز المستندة إلى المحاكاة الافتراضية (HVCI/VBS)، بدأ المهاجمون في البحث عن برمجيات تعريف متخصصة وموقعة رقمياً صممت لإدارة عتاد محدد لشركات تصنيع كبرى، والتي غالباً ما تفلت من رادار قوائم الحظر العامة لصعوبة الاستغلال المباشر لها بسبب بوابات العتاد.

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

رؤية Glitch4Techs

من وجهة نظرنا التحليلية في منصة Glitch4Techs، فإن الاعتماد المستمر من قبل صناع القرار الأمني على استراتيجية "قوائم الحظر التفاعلية" (Reactive Blocklists) لمعالجة ثغرات برمجيات التعريف هو بمثابة مسكن مؤقت لا يعالج جذور الأزمة الأعمق. إن كشف المنهجية البرمجية لتجاوز قيود العتاد يثبت أن الحواجز الفيزيائية والمادية التي لطالما اعتقد المطورون أنها تحمي برمجيات التعريف الخاصة بهم من إساءة الاستخدام هي حواجز وهمية يسهل اختراقها وتزييفها بالكامل من وضع المستخدم الإداري الاعتيادي.

نتوقع في الفترة القادمة تصاعداً كبيراً في استغلال برمجيات تعريف العتاد المتخصصة (مثل مكونات خوادم مراكز البيانات وبطاقات الشبكات الصناعية) في عمليات الاختراق المنظم. يستدعي هذا التهديد إعادة تصميم جذرية لنموذج الثقة في نواة ويندوز، بحيث لا يكفي توقيع مايكروسوفت الرقمي لإثبات سلامة السلوك البرمجي لبرمجية التعريف، بل يجب تفعيل فحص استباقي صارم لجميع طلبات الاتصال بقنوات الإدخال والإخراج وتوسيع آليات التدقيق الديناميكي لنشاط الدوال الحيوية مثل MmMapIoSpace في بيئات التشغيل الحساسة.