CVE-2017-8464 / بحث + PoC

أنشئ اختصارًا + ملف .DLL يحتوي على حمولة خبيثة => ضعه في USB وأرسله إلى الضحية => يفتح الضحية USB => تُنفَّذ الحمولة تلقائيًا!

السبب الجذري

أولاً، علينا أن نعرف بالضبط من أين يأتي هذا الخطأ! إنه بسبب ميزة تسمى Plug-and-Play (التوصيل والتشغيل) حيث يكتشف نظام التشغيل الجهاز تلقائيًا، ويخصص الموارد، ويحمّل برنامج التشغيل (Driver) المناسب ليعمل فورًا دون الحاجة إلى إعادة تشغيل الجهاز. عندما تُدخل USB وتفتح المجلد عبر مستكشف Windows explorer.exe، يقوم نظام التشغيل بفحص الملفات لعرض الأيقونات المناسبة للمستخدم!
منذ إصدارات Windows القديمة، أرادت Microsoft أن تتمكن الاختصارات (shortcut .lnk) التي تشير إلى ميزات لوحة التحكم Control Panel (وهي في الأساس ملفات .cpl أو .dll) من عرض أيقونات ديناميكية بمرونة. لذلك، صُممت دالة باسم CPL_LoadCPLModule في مكتبة الواجهة الأساسية لنظام Windows وهي shell32.dll.
استخدام LoadLibrary بشكل أعمى: للحصول على الأيقونة من ملف Control Panel Applet، لا يقرأ نظام التشغيل ملف صورة ثابتًا فحسب، بل يستخدم الدالة LoadLibraryW لتحميل مكتبة الارتباط الديناميكي بالكامل مباشرةً في مساحة ذاكرة عملية explorer.exe. وبعد التحميل، يستدعي دالة تصدير قياسية هي CPlApplet للحصول على الأيقونة وعرضها على الشاشة.

لإثبات أن LoadLibraryW مرتبطة فعلًا بسلسلة الاستغلال أعلاه:

1/ شغّل x64dbg بصلاحيات المسؤول

2/ اربط (Attach) بـ explorer.exe

3/ اكتب الأمر bp LoadLibraryW

4/ اضغط F9 لاستئناف تشغيل explorer.exe

5/ أدخل USB وستصل إلى نقطة التوقف (breakpoint) فورًا!

مشكلة PoC والحل

واجهت مشكلة أن سلسلة الاستغلال صامتة تمامًا، ورغم محاولتي الفحص والتنقيح (debug) لم أستطع إيجاد طريقة للإصلاح! بعدها جرّبت البحث عن PoC لشخص آخر وتشغيلها لكنها فشلت أيضًا!

مثال: https://github.com/3gstudent/CVE-2017-8464-EXP

لكن عندما ذهبت لتناول الغداء ثم عدت، استعدت تركيزي وهدوئي، وبدأت أطرح سؤالًا: لماذا نجح PoC لذلك الشخص لكنه لا يعمل على جهازي؟ حسنًا، بدأت بعمل هندسة عكسية خفيفة لملفَي .lnk و.dll خاصته فاكتشفت شيئين!

1 / ملف .dll الخاص بي أطول من ملفه! لكن لا بأس، فهذه ليست المشكلة!

2 / عندما ألقيت ملف .lnk في HxD لقراءة النصوص (strings)، اكتشفت أنه لم يستخدم مسارًا نسبيًا بل مسارًا مطلقًا!

نسبي: ../example.dll

مطلق: O:/example.dll

حسنًا، طريقة الإصلاح الآن هي أن نعرف ما اسم محرك الأقراص الذي سيُعطى تلقائيًا للـ USB عند توصيله بجهاز الضحية، ثم نضع المسار المطلق وسينجح الأمر. على جهازي بنظام Win7، عند توصيل USB يظهر دائمًا كمحرك F، لذا كانت صيغة البناء (build) الخاصة بي هي:

python Make_PoC.py FakeGoogleChrome F:\Pwned.dll

كيف قامت Microsoft بتصحيح هذه البنية؟

نظرًا لأن هذا الخطأ يعود إلى خلل في تفكير وتصميم بنية النظام (Logic/Architecture Flaw) وليس خطأ تجاوز سعة الذاكرة (buffer overflow)، كان على Microsoft تغيير طريقة التعامل مع Control Panel بالكامل:

التوقيع الرقمي (Code Signing): تفرض أنظمة التشغيل الحديثة أن تكون ملفات .cpl أو .dll التي تُحمَّل بواسطة عمليات النظام موقعة رقميًا بتوقيع Microsoft صالح أو موجودة داخل مجلدات نظام محمية بشكل صارم (مثل System32) لتجنب خطأ "Binary Planting" من USB.
عزل العمليات (Process Isolation): بدلاً من التحميل مباشرةً في العملية الحرجة explorer.exe [cite: 1058]، تقوم إصدارات Windows الجديدة بتشغيل تطبيقات Control Panel عبر عملية وسيطة معزولة (مثل dllhost.exe أو rundll32.exe). إذا تعطلت الـ DLL أو احتوت على برمجيات خبيثة، فسيؤدي ذلك فقط إلى انهيار العملية الوسيطة ولن تتمكن من السيطرة على نظام الواجهة بأكمله.

المراجع

أبحاث VN

https://github.com/TrG-1999/DetectPacket-CVE-2017-8464

PoC

https://github.com/3gstudent/CVE-2017-8464-EXP

أداة بناء ملف .lnk المستغل

https://github.com/nixawk/labs/blob/master/CVE-2017-8464/exploit_CVE-2017-8464.py

POC-CVE-2017-8464-OpenCalculator

الأكثر شعبية