كيف تعمل هذه الهجمات؟
بحسب تقرير IBM X-Force، تعتمد هذه التقنية على:
-
استغلال تطبيقات Electron الموثوقة التي تحتوي على إصدارات ضعيفة من V8.
-
استبدال ملف main.js ببرنامج ضار يستغل الثغرات في محرك V8.
-
تنفيذ شل كود (Shellcode) مباشرة على النظام، مما يتيح للمهاجمين التحكم في الجهاز.
“السيناريو معروف: يتم استغلال ملف ثنائي موثوق به ولكنه يحتوي على ثغرة، والاستفادة من ثقته للوصول إلى النظام.”
— IBM X-Force
لماذا يعتبر WDAC عرضة لهذا النوع من الهجمات؟
-
يعتمد WDAC على قوائم بيضاء (Whitelisting) تسمح فقط بتشغيل التطبيقات الموقعة من جهات موثوقة مثل Microsoft.
-
إذا كان التطبيق المستغل (مثل تطبيق Electron) موقّعًا من Microsoft، فإن WDAC سيتعامل معه على أنه آمن، مما يتيح للمهاجمين تنفيذ أكواد خبيثة دون اكتشافها.
هجمات مماثلة: استغلال WinDbg Preview لاختراق WDAC
في سياق متصل، كشفت شركة CerberSec الشهر الماضي عن طريقة أخرى لاختراق WDAC تعتمد على:
-
استغلال أداة WinDbg Preview (أداة تصحيح الأخطاء من Microsoft).
-
استخدامها كـ”حصان طروادة” لتجاوز سياسات WDAC نظرًا لأنها موقعة من Microsoft.
ما هي الخطوات التي يمكن اتخاذها للحماية؟
-
تحديد إصدارات V8 في تطبيقات Electron:
-
التأكد من أن جميع التطبيقات المستندة إلى Electron تستخدم أحدث إصدار من V8 لتجنب الثغرات المعروفة.
-
-
مراجعة سياسات WDAC:
-
تقييد التطبيقات المسموح بها بشكل أكثر صرامة، حتى لو كانت موقعة من Microsoft.
-
-
استخدام حلول متعددة للحماية:
-
دعم WDAC بأدوات أخرى مثل AppLocker أو Microsoft Defender for Endpoint.
-
-
مراقبة سلوك التطبيقات:
-
اكتشاف أي محاولات غير عادية لتنفيذ أكواد أو تعديل ملفات النظام.
-
هل WDAC لم يعد آمنًا؟
-
WDAC لا يزال قويًا، لكنه يعتمد على الثقة في التطبيقات الموقعة.
-
المهاجمون يبحثون دائمًا عن ثغرات في البرامج الموثوقة لاستغلالها.
-
الحل الأمثل هو التحديث المستمر وتطبيق سياسات أمان صارمة.
“الهجمات تتطور، والأمان يجب أن يتطور معها.”
— خبير أمني في IBM