Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
NotSecDrv — PoC لـ CVE-2018-7249 | Kitploit
أدوات/GitHubGitHub/alonhr/notsecdrv
تحليل الذاكرة الجنائيتحليل الثغرات الأمنيةالاستغلالالهندسة العكسيةالتعلم والتعليماستغلال الملفات الثنائية
GitHubalonhr/notsecdrv

NotSecDrv

PoC لـ CVE-2018-7249

عرض المستودع
1533منذ سنة واحدةلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

NotSecDrv - كود إثبات المفهوم لـ CVE-2018-7249

الوصف العام

تم اكتشاف ثغرة في ملف secdrv.sys كما هو مضمّن في Microsoft Windows Vista وWindows 7 وWindows 8 وWindows 8.1 قبل KB3086255، وكما هو مضمّن في Macrovision SafeDisc. يمكن لاستدعاءين موقوتين بعناية لـ IOCTL 0xCA002813 أن يسببا حالة سباق تؤدي إلى استخدام بعد التحرير (use-after-free). عند استغلالها، يمكن لمهاجم غير مميز تشغيل كود عشوائي في النواة.

تم إبلاغ Microsoft بهذه الثغرة، وبما أنها لا تؤثر على جهاز Windows محدّث (فقط الإصدارات السابقة لـ KB3086255)، لن يتخذوا أي إجراء. تم اختبارها واستغلالها بنجاح على Windows 7 x86.

يرتبط أيضًا بـ CVE-2018-7250.

لقطة الشاشة

لقطة شاشة

التفاصيل

توثق هذه الصفحة بحثي الصغير حول برنامج التشغيل secdrv.sys. جميع السلوكيات الموصوفة لبرنامج التشغيل تم استنتاجها عبر الهندسة العكسية وقد تكون غير صحيحة / غير دقيقة.

الإزاحة 0x4 من المخزن المؤقت للإدخال إلى IOCTL (0x0CA002813) تحتوي على رقم سأشير إليه باسم TYPE. تستقبل دالة المعالج الرئيسية لهذا IOCTL (0x0CA002813)، وهي sub_11A88، ثلاثة أنواع مختلفة: 0x96 و0x97 و0x98.

  • 0x96 يخصّص كتلة PagedPool، ويخزّنها في مصفوفة بحجم 0x64، ويهيئها (نوعًا ما :))، وينسخ جزءًا منها إلى المخزن المؤقت المقدَّم من المستخدم عند الإزاحة 0x10.
  • 0x97 يستخدم كتلة مخصصة مسبقًا، تم تخصيصها باستخدام 0x96 (يجد الكتلة الصحيحة في المصفوفة المذكورة عبر وسم)، ويستخدمها لتشفير مخزن الإدخال الخاص بالمستخدم باستخدام نوع من خوارزمية تشفير xor معدّلة. ثم يستدعي دالة مخزنة في بنية أخرى، يتم الإشارة إليها بواسطة حقل في الكتلة المخصصة.
  • 0x98 يحرر كتلة تم تخصيصها باستخدام 0x96. يجد الكتلة الصحيحة بالبحث عن الوسم المعطى لها أثناء عملية التخصيص.

تسريب المعلومات (CVE-2018-7250)

بعد أن يخصص IOCTL من النوع 0x96 كتلة جديدة ويهيئها، ولكن ليس بشكل كامل، ينسخ الكتلة إلى وضع المستخدم. 16 بت في الكتلة المخصصة حديثًا لم تتم تهيئتها، وتحتوي على بيانات من تخصيصات PagedPool السابقة. ثم تُنسخ البتات غير المهيأة إلى وضع المستخدم عند .text:00011BE9 بواسطة تعليمة REP MOVSD. كود إثبات المفهوم هنا.

تنفيذ كود تعسفي (CVE-2018-7249)

عند استدعاء IOCTL من النوع 0x97، فإنه يجد الكتلة المطلوبة، التي تم تخصيصها مسبقًا بالنوع 0x96، عن طريق وسمها. إذا كانت الكتلة قد حُررت بالفعل بواسطة IOCTL من النوع 0x97، يقوم DeviceIoControl بإرجاع خطأ. الثغرة هنا هي أن الكتلة المستخدمة بواسطة النوع 0x97 يمكن تحريرها أثناء عملها (نظرًا لعدم استخدام آليات مزامنة)، وبالتالي يتم استخدامها بعد تحريرها إذا تم كسب السباق. إذا تمكن المهاجم من تحرير الكتلة أثناء عمل IOCTL من النوع 0x97 (باستخدام النوع 0x98)، وتخصيص كتلة جديدة يتحكم فيها في نفس موقع الذاكرة تمامًا، فيمكنه استبدال مؤشر إلى بنية أخرى، تحتوي على مؤشر دالة يمكن استخدامه في النهاية لاختطاف تدفق تنفيذ برنامج التشغيل وتنفيذ كود عشوائي في ring 0. نظرًا لأن روتين التشفير يتم على مخزن مؤقت مقدم من المستخدم، والذي يمكن أن يكون ضخمًا في الحجم، فقد يستغرق التشفير وقتًا طويلاً للتنفيذ، مما يوفر نافذة زمنية مثالية لـ IOCTL من النوع 0x98 لتحرير الكتلة بينما لا تزال قيد الاستخدام. يمكن أن تكون النوافذ الزمنية طويلة جدًا (أكثر من ثانية واحدة!)، بحيث يمكن كسب السباق بشكل موثوق من المحاولة الأولى. يبدأ استخدام بعد التحرير عند .text:00011B68، والاستدعاء الفعلي، الذي سيتم اختطافه للقفز إلى shellcode، يحدث عند .text:00011B86.

الخطوات المتخذة لاستغلال هذه الثغرة بنجاح هي كما يلي:

  • تحرير جميع الكتل السابقة بالوسم الذي نخطط لاستخدامه لاحقًا، والتأكد من أن جميع IOCTLs تعمل على نفس كتلة PagedPool.
  • رش PagedPool وإنشاء فجوات تطابق حجم التخصيصات في IOCTL من النوع 0x96 (0x30 بايت). هذا ضروري لاحقًا لتخصيص بديل مزيف بشكل موثوق بدلاً من الكتلة المحررة.
  • تخصيص كتلة باستخدام IOCTL من النوع 0x96. سيتم تخصيص هذه الكتلة في إحدى الفجوات التي تم إنشاؤها مسبقًا.
  • تخصيص منطقة كبيرة من ذاكرة مساحة المستخدم واستدعاء IOCTL من النوع 0x97. ستضمن منطقة الذاكرة الكبيرة أن الخيط الذي يحرر التخصيص لديه وقت كافٍ لكسب السباق.
  • بدء خيط جديد يستدعي IOCTL من النوع 0x98 ويحرر الكتلة التي يعمل عليها الخيط الآخر.
  • رش التجمع (pool) مرة أخرى من الخيط الجديد (بعد تحرير الكتلة) من أجل استبدال الكتلة المحررة بتخصيص يتحكم فيه المهاجم. يجب أن تحتوي هذه الكتلة المزيفة على مؤشرات صالحة للبنى اللازمة.
  • وضع عنوان shellcode في الإزاحة الصحيحة لمؤشر الدالة في البنية المزيفة التي أنشأناها، وانتظار استدعائه (سيتم استدعاؤه من IOCTL من النوع 0x97، بعد انتهائه من التشفير).
  • استمتع!

بيئة الاختبار

نظام التشغيل: Windows 7 Kernel Version 7600 MP (1 procs) Free x86 compatible Built by: 7600.16385.x86fre.win7_rtm.090713-1255 الجهاز الافتراضي: 4GB RAM, 1 CPU العتاد: Windows 10 Pro 64 bit, Motherboard Gigabyte Z370 HD3, 16GB RAM, Intel i5-8400 2.80GHz (6 CPUs)

تنزيل الأداة