الأسوأ على الإطلاق —
مع توفر رمز PoC وعمليات فحص الإنترنت النشطة، تعد السرعة أمرًا جوهريًا.
حذر باحثون أمنيون من إمكانية استغلال ثغرة أمنية خطيرة في لغة برمجة PHP لتنفيذ تعليمات برمجية ضارة على أجهزة Windows، وحثوا المتضررين على اتخاذ الإجراءات اللازمة قبل بدء عطلة نهاية الأسبوع.
وفي غضون 24 ساعة من نشر الثغرة الأمنية والتصحيح المصاحب لها، اكتشف باحثون من منظمة Shadowserver الأمنية غير الربحية ذكرت تم تصميم عمليات فحص الإنترنت لتحديد الخوادم المعرضة للهجمات. هذا – إلى جانب (1) سهولة الاستغلال، (2) توفر كود هجوم إثبات المفهوم، (3) خطورة تنفيذ التعليمات البرمجية عن بعد على الأجهزة المعرضة للخطر، و(4) الاستخدام على نطاق واسع. XAMPP كون النظام الأساسي عرضة للخطر بشكل افتراضي – دفع ممارسي الأمن إلى حث المسؤولين على التحقق لمعرفة ما إذا كانت خوادم PHP الخاصة بهم قد تأثرت قبل بدء عطلة نهاية الأسبوع.
عندما لا يكون “الأفضل مناسبًا”.
“ثغرة سيئة مع استغلال بسيط للغاية – مثالية بعد ظهر يوم الجمعة”، هذا ما قاله باحثون من شركة WatchTowr الأمنية كتب.
CVE-2024-4577، أثناء تعقب الثغرة الأمنية، تنبع من أخطاء في الطريقة التي تقوم بها PHP بتحويل أحرف Unicode إلى ASCII. أ ميزة يتيح نظام التشغيل Windows المعروف باسم Best Fit للمهاجمين استخدام تقنية تُعرف باسم حقن الحجة لتمرير المدخلات المقدمة من المستخدم إلى الأوامر التي ينفذها أحد التطبيقات، في هذه الحالة، PHP. تسمح عمليات الاستغلال للمهاجمين بالتجاوز CVE-2012-1823، تم تصحيح ثغرة أمنية خطيرة في تنفيذ التعليمات البرمجية في PHP في عام 2012.
“أثناء تنفيذ PHP، لم يلاحظ الفريق ميزة Best-Fit لتحويل التشفير داخل نظام التشغيل Windows،” هذا ما قاله باحثون من Devcore، شركة الأمان التي اكتشفت CVE-2024-4577، كتب. “تسمح هذه الرقابة للمهاجمين غير المصادقين بتجاوز الحماية السابقة لـ CVE-2012-1823 من خلال تسلسلات أحرف محددة. يمكن تنفيذ التعليمات البرمجية التعسفية على خوادم PHP البعيدة من خلال هجوم حقن الوسيطات.
يؤثر CVE-2024-4577 على PHP فقط عند تشغيله في الوضع المعروف باسم CGI، حيث يقوم خادم الويب بتحليل طلبات HTTP وتمريرها إلى برنامج PHP النصي للمعالجة. حتى عندما لا يتم ضبط PHP على وضع CGI، قد تظل الثغرة الأمنية قابلة للاستغلال عندما تكون ملفات PHP التنفيذية مثل php.exe وphp-cgi.exe موجودة في أدلة يمكن الوصول إليها بواسطة خادم الويب. يتم تعيين هذا التكوين افتراضيًا في XAMPP لنظام التشغيل Windows، مما يجعل النظام الأساسي عرضة للخطر ما لم يتم تعديله.
لاحظت WatchTowr أن أحد الأمثلة يحدث عندما يتم تحليل الاستعلامات وإرسالها عبر سطر الأوامر. النتيجة: طلب غير ضار مثل http://host/cgi.php?foo=bar
يمكن تحويلها إلى php.exe cgi.php foo=bar
، وهو الأمر الذي سيتم تنفيذه بواسطة محرك PHP الرئيسي.
لا مفر
مثل العديد من اللغات الأخرى، تقوم PHP بتحويل أنواع معينة من مدخلات المستخدم لمنع تفسيرها على أنها أمر للتنفيذ. هذه عملية تعرف بالهروب. على سبيل المثال، في HTML، غالبًا ما يتم تجاوز الأحرف <و> عن طريق تحويلها إلى مكافئاتها ذات القيمة السداسية الموحدة <و> لمنع تفسيرها على أنها علامات HTML بواسطة المتصفح.
يوضح باحثو WatchTowr كيف يفشل Best Fit في الهروب من الأحرف مثل الواصلة الناعمة (بقيمة unicode 0xAD) ويقوم بدلاً من ذلك بتحويلها إلى واصلة عادية غير قابلة للإلغاء (0x2D)، وهي حرف يلعب دورًا أساسيًا في العديد من تراكيب التعليمات البرمجية.
ومضى الباحثون في التوضيح:
اتضح أنه، كجزء من معالجة يونيكود، ستطبق PHP ما يعرف بتعيين “الأفضل ملاءمة”، ومن المفيد أن تفترض أنه عندما يقوم المستخدم بإدخال واصلة ناعمة، فإنه في الواقع ينوي كتابة حقيقي الواصلة، وتفسيرها على هذا النحو. هنا تكمن ثغرتنا – إذا زودنا معالج CGI بواصلة ناعمة (0xAD)، فلن يشعر معالج CGI بالحاجة إلى الهروب منه، وسيمرره إلى PHP. PHP، ومع ذلك، سوف يفسرها كما لو كانت ملف حقيقي واصلة، والتي تسمح للمهاجم بتسلل وسيطات سطر الأوامر الإضافية، والتي تبدأ بالواصلات، إلى عملية PHP.
يشبه هذا بشكل ملحوظ خطأ PHP أقدم (عندما يكون في وضع CGI)، CVE-2012-1823، ولذا يمكننا استعارة بعض تقنيات الاستغلال التي تم تطويرها لهذا الخطأ الأقدم وتكييفها لتعمل مع خطأنا الجديد. مفيدة الكتابة تنصح أنه لترجمة إدخالنا إلى RCE، يجب أن نهدف إلى إدخال الحجج التالية:
-d allow_url_include=1 -d auto_prepend_file=php://input
سيؤدي هذا إلى قبول الإدخال من نص طلب HTTP الخاص بنا، ومعالجته باستخدام PHP. واضح بما فيه الكفاية – دعونا نجرب نسخة من هذا مجهزة بـ 0xAD “الواصلة الناعمة” الخاصة بنا بدلاً من الواصلة المعتادة. ربما يكفي التسلل عبر الهروب؟
POST /test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1Host: {{host}}User-Agent: curl/8.3.0Accept: */*Content-Length: 23Content-Type: application/x-www-form-urlencodedConnection: keep-alive
يا فرحة – لقد تمت مكافأتنا بـ
phpinfo
الصفحة، تبين لنا أننا حققنا بالفعل RCE.
تم اكتشاف الثغرة الأمنية بواسطة باحث Devcore Orange Tsai، الذي قال: “الخطأ بسيط للغاية، ولكن هذا أيضًا ما يجعله مثيرًا للاهتمام.”
قالت كتابة Devcore أن الباحثين أكدوا أن XAMPP معرض للخطر عندما يتم تكوين Windows لاستخدام اللغات الصينية التقليدية أو الصينية المبسطة أو اليابانية. في Windows، اللغة هي مجموعة من معلومات تفضيلات المستخدم المتعلقة بلغة المستخدم و/أو البيئة و/أو الأعراف الثقافية. لم يختبر الباحثون مواقع أخرى وحثوا الأشخاص الذين يستخدمونها على إجراء تقييم شامل للأصول لاختبار سيناريوهات الاستخدام الخاصة بهم.
يؤثر CVE-2024-4577 على كافة إصدارات PHP التي تعمل على جهاز يعمل بنظام Windows. يتضمن ذلك فروع الإصدار 8.3 قبل 8.3.8، و8.2 قبل 8.2.20، و8.1 قبل 8.1.29.
تعتبر فروع الإصدارات 8.0 و7 و5 عرضة للخطر أيضًا، ولكن بما أنها لم تعد مدعومة، سيتعين على المسؤولين اتباع نصائح التخفيف نظرًا لعدم توفر التصحيحات. أحد الخيارات هو تطبيق ما يعرف بقواعد إعادة الكتابة مثل:
RewriteEngine OnRewriteCond %{QUERY_STRING} ^%ad [NC]RewriteRule .? - [F,L]
ويحذر الباحثون من أن هذه القواعد قد تم اختبارها فقط في المناطق الثلاث التي أكدوا أنها معرضة للخطر.
لم يكن XAMPP لنظام التشغيل Windows قد أصدر إصلاحًا حتى وقت نشر هذا المنشور. بالنسبة للمسؤولين الذين لا يحتاجون إلى PHP CGI، يمكنهم إيقاف تشغيله باستخدام تكوين خادم Apache HTTP التالي:
C:/xampp/Apache/conf/extra/httpd-xampp.conf
تحديد الخطوط المقابلة:
ScriptAlias /php-cgi/ "C:/xampp/php/"
والتعليق عليه:
# ScriptAlias /php-cgi/ "C:/xampp/php/"
يتوفر تحليل إضافي للثغرة الأمنية هنا.