bttea/cve-2024-4577-rce-pocCVE-2024-4577 RCE PoC
أثناء تنفيذ PHP، لم يلاحظ الفريق ميزة Best-Fit لتحويل الترميز داخل نظام التشغيل Windows. يسمح هذا الإغفال للمهاجمين غير الموثَّقين بتجاوز الحماية السابقة لـ CVE-2012-1823 عبر تسلسلات أحرف محددة. يمكن تنفيذ أكواد عشوائية على خوادم PHP البعيدة من خلال هجوم حقن الوسائط.
هذا الدليل (PoC) مخصص لأغراض التعلم والبحث فقط. لا تستخدمه في أنشطة غير قانونية؛ أنت وحدك المسؤول عن أي عواقب قانونية.
تم اكتشاف هذه الثغرة من قبل Orange Tsai (@orange_8361) من DEVCORE (@d3vc0r3). تأكد من متابعة أبحاثه المتميزة، كان دورنا فقط إعادة إنشاء وتطوير الاستغلال لهذه المشكلة.
لماذا من الضروري إعادة كتابة سكريبت الاستغلال بينما توجد بالفعل العديد من أدوات الإثبات (PoCs) المتاحة للجميع على الإنترنت؟
نظرًا لأن العديد من أدوات الإثبات المتاحة للجميع مبنية على نفس الاستغلال الأصلي، فقد استخدم العديد من البائعين هذه الأدوات كمراجع وقاموا بحظر كلمات مفتاحية معينة لمنع استغلالها. ومع ذلك، غالبًا ما يغفلون عن حظر جميع نواقل الاستغلال المحتملة. لمعالجة هذا، يتضمن السكريت آلية بسيطة لتوليد معاملات عشوائية، بالإضافة إلى طرق مختلفة للانتقال من Local File Inclusion (LFI) إلى تنفيذ الأوامر عن بعد (RCE)، لتعزيز معدل نجاح حقن PHP-CGI المؤدي إلى RCE.
أثناء اختبار كنت أحاول فيه إعادة إنتاج ثغرة بيئية، اكتشفت أن أداة الإثبات التي أمتلكها كانت تؤدي باستمرار إلى خطأ HTTP 500، بغض النظر عن التعديلات. وبما أنني كنت أعمل في بيئة قابلة للاستغلال، بدأت بالتحقيق في سبب الخطأ. ثم تذكرت مقالة لشركة Devcore التي ذكرت أنه، في بعض سيناريوهات الاستغلال، يعيد الخادم خطأ HTTP 500، على الرغم من أن استغلال RCE كان ناجحًا بالفعل. وبناءً على ذلك، قررت اختبار ما إذا كان بإمكاني تشغيل calc.exe محليًا، ولدهشتي، نجح الأمر — لقد كان RCE أعمى (Blind RCE)!
ومع ذلك، عندما راجعت سجل أخطاء Apache، وجدت خطأ يشير إلى allow_url_include، على الرغم من أن الهجوم تم تنفيذه بنجاح (وما زلت لا أفهم السبب الجذري تمامًا؛ إذا كانت لديك رؤى، يرجى الاتصال بي). دفعني هذا إلى إنشاء أداة استغلال تتضمن خيارًا لاختبار RCE الأعمى أيضًا😊.
إذا كان هدفك هو إصدار نظام تشغيل أقدم من Windows 7، فلا يزال بإمكانك الترقية إلى RCE مرئي أو قشرة عكسية (reverse shell) من خلال طرق أخرى. ومع ذلك، فإن هذه التقنيات خارج نطاق هذه المقالة، لذلك لن ندخل في التفاصيل. كمختبر اختراق أو متخصص في الفريق الأحمر، يجب أن تكون قادرًا على إيجاد حلول بديلة بسرعة إلى حد ما، والتي يمكن أن تكون عملية ممتعة😉.
تم التحديث في 15 نوفمبر 2024
بسبب متطلبات العمل، واصلت تحسين السكريبت ليجعله متوافقًا قدر الإمكان مع جميع البيئات ويزيد من فرص تحقيق RCE. كان هذا الجهد مدفوعًا بحقيقة أن بعض الأهداف لم تتمكن من تنفيذ PHP بنجاح باستخدام العديد من أدوات الإثبات العامة. في النهاية، قمت بحل هذه المشكلة بشكل غير متوقع، وتمكنت من التغلب على جميع حالات الخطأ 500 تقريبًا وعرض نتائج تنفيذ PHP بنجاح. نتيجة لذلك، لم يعد RCE الأعمى يبدو بالغ الأهمية. 😧
شروط الاستغلال
php-cgi.exe.تحتاج إلى تثبيت التبعيات:
$ python3 -m pip install requestsقم بتشغيل السكريبت مباشرة للحصول على تعليمات الاستخدام. يمكنك تشغيل الأمر أدناه للتحقق مما إذا كان الهدف قابلًا للاستغلال.
$ python3 CVE-2024-4577.py <target> <php shell>
إذا كان الاستغلال موجودًا على الهدف، يمكنك حفظ نتائج تنفيذ PHP محليًا، وهو مفيد لمن يحتاج إلى عرض phpinfo.
$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html
عندما يكون الهدف عرضة لـ RCE أعمى، سيحاول السكريبت الاستماع على منفذ محلي وسيؤدي إلى تشغيل PHP على الخادم الهدف، وإرسال طلب للتحقق من وجود الاستغلال. عند استلام الطلب، فهذا يشير إلى أن الخادم الهدف قد نفذ الأمر بنجاح.
