PINKPANTHER

نبذة

شيلكود مكتوب يدويًا لوضع النواة (kernel-mode) في Windows x64؛ لاستبدال رمز الوصول الأساسي للعملية الجارية برمز وصول عملية SYSTEM من أجل رفع الامتيازات (Elevation of Privilege - EoP).

إصدارات أنظمة التشغيل المدعومة

• Windows 7/Windows Server 2008 R2 Build 7601
• Windows 8/Windows Server 2012 Build 9200
• Windows 8.1/Windows Server 2012 R2 Build 9600
• Windows 10 1507/TS1 Build 10240
• Windows 10 1511/TS2 Build 10586
• Windows 10 1607/RS1/Windows Server 2016 Build 14393
• Windows 10 1703/RS2 Build 15063
• Windows 10 1709/RS3 Build 16299
• Windows 10 1803/RS4 Build 17134
• Windows 10 1809/RS5/Windows Server 2019 Build 17763
• Windows 10 1903/19H1 Build 18362
• Windows 10 1909/19H2 Build 18363
• Windows 10 2004/20H1 Build 19041
• Windows 10 2009/20H2 Build 19042
• Windows 10 2104/21H1 Build 19043
• Windows 10 2110/21H2 Build 19044

البناء والنشر

المتطلبات الأساسية لبناء هذا المشروع هي:

1. Visual Studio 2019(any edition will do fine)
2. Windows 10 SDK, version 2004
3. Windows 10 WDK, version 2004
4. Python3

تجدر الإشارة هنا إلى أنه يمكنك الاكتفاء بوجود مُجمِّع (assembler) فقط (هذا المشروع يستخدم MASM)؛ لأن هذا كل ما تحتاجه من الناحية التقنية.

بعد تثبيت ما سبق، سيكون الأمر سهلاً مثل فتح الحل (solution) باستخدام Visual Studio ثم البناء لهدف x64.

بعد البناء الناجح، يمكن العثور على الملفات الثنائية داخل مجلد Bin تحت المجلد الفرعي المناسب حسب عدد البتات (bitness).

بدلاً من ذلك، يمكنك تنزيل شيلكود مستقل عن العنوان (position independent shellcode) جاهز للنشر من Releases.

يرجى عدم محاولة نشر الحمولة على جهاز تعتمد عليه لإنجاز عملك إذا لم تكن متأكدًا من طريقة عملها.

راجع وثائق Microsoft للحصول على أي معلومات إضافية.

الاختبار

لأغراض الاختبار، أوصي بشدة باستخدام flare-kscldr لنشر شيلكود وضع النواة على VM اختبارية، ودليل CodeMachine لإعداد النظام لتطوير النواة وتصحيح الأخطاء لإعداد Hyper-V Guest VM بدعم كامل لتصحيح أخطاء النواة.

بشكل اختياري، يمكنك أيضًا التفكير في أتمتة العملية باستخدام kdbg-driver-vagrant لتشغيل VM اختبارية بسرعة مع تصحيح أخطاء كامل للنواة باستخدام Vagrant.

لقطات الشاشة

تحذيرات

كما أشار إليّ Dmytro Oleksiuk(@d_olex)، هناك بعض حالات السباق (race conditions) الواضحة في الكود تتعلق تحديدًا بما يلي:

1. المرور يدويًا على بنى nt!_EPROCESS المرتبطة معًا عبر قائمة مرتبطة بشكل مضاعف ودائري دون استخدام أي نوع من بدائيات المزامنة/آليات القفل (synchronization primitive/locking mechanism)
2. الإشارة غير الآمنة إلى كائنات العملية هذه أثناء التعامل معها

وهي حاليًا تفتقر إلى أي حماية ضد التغييرات التي قد تطرأ عليها أثناء عملنا عليها.

هل هذه مشكلة؟ نعم، حالات السباق دائمًا ما تكون مشكلة ويمكن أن تسبب جميع أنواع السلوك غير المحدد/مزعجات bugcheck.

هل سيؤثر استخدام هذه الحمولة على استقرار ثغرة الاستغلال الخاصة بي؟ ربما.

حسنًا، ما الحل؟ الحل من خطوتين.

يتضمن الجزء الأول الحصول على قفل من نوع الانتظار مثل Pushlocks - nt!PspActiveProcessLock(مؤشر pushlock) للوصول الحصري باستخدام nt!ExAcquirePushLockExclusive قبل المرور على قائمة العمليات (يجب تعطيل تسليم APC العادي للنواة مسبقًا)، وnt!ExReleasePushLockExclusive لتحرير القفل بمجرد الانتهاء من استخدام القائمة، وعند هذه النقطة يجب إعادة تمكين تسليم APC العادي للنواة.

ومع ذلك، نظرًا لأن هذا المتغير العام غير مُصدَّر من نواة nt، فإن النهج الأكثر لائقًا وأمانًا سيكون استخدام API الخاص بـ nt!ZwQuerySystemInformation مع SYSTEM_INFORMATION_CLASS == SystemProcessInformation للعثور على PID من ImageName، وnt!PsLookupProcessByProcessId للحصول على nt!_EPROCESS VA من PID.

إذا كنت مهتمًا بمعرفة كيفية قيام النواة بالأمر الأول، فأطلب منك الاطلاع على nt!PsGetNextProcess في مفكك (disassembler).

يتضمن الجزء الثاني الإشارة الآمنة إلى الكائنات باستخدام عائلة APIs الخاصة بـ nt!ObReferenceObject لزيادة عدد المراجع (reference count) على كائن العملية بحيث لا يمكن حذفه حتى ننقصه صراحةً في النهاية بعد الانتهاء من استخدامه عبر nt!ObDereferenceObject.

لاحظ أن زيادة عدد المراجع يدويًا أمر زائد عن الحاجة؛ لأن استدعاء nt!PsLookupProcessByProcessId عند نجاحه يقوم بذلك نيابةً عنا.

ومع ذلك، فإن تنفيذ هذه الإصلاحات يتطلب العثور على العنوان الأساسي لـ ntoskrnl.exe وحل الرموز (symbols) بداخله عن طريق المرور على EAT للعثور على مؤشرات الدوال باستخدام بعض خوارزميات تجزئة السلاسل النصية، وكل ذلك من شأنه أن يزيد حجم الحمولة بشكل كبير.

قد أقرر تنفيذ ذلك يومًا ما، أو ببساطة الكتابة بلغة C وإغراق مخرجات المترجم :)

شكرًا لـ Dmytro Oleksiuk(@d_olex) وPaul L.(@am0nsec) على الإشارة إلى الأخطاء واقتراح الإصلاح أيضًا.

أعمال ذات صلة

1. تطوير الاستغلال: Panic! At The Kernel - إعادة النظر في حمولات سرقة الرموز على Windows 10 x64 وتجاوز SMEP
2. البدء مع استغلال نواة Windows – الجزء 3 – سرقة رمز الوصول
3. [استغلال النواة] 2: الحمولات
4. شيلكودات نواة Windows - خلاصة شاملة
5. شيلكود نواة Windows على Windows 10 – الجزء 1
6. شيلكود نواة Windows : TokenStealer
7. رفع الامتيازات في نواة x64