إذا قمت بتشغيل موقع WordPress وكنت تستخدم ملف Elementor مجموعة أدوات إنشاء مواقع الويب ، فقد تكون عرضة لخطر حدوث فجوة أمنية تجمع بين تسرب البيانات وتنفيذ التعليمات البرمجية عن بُعد.
هذا إذا كنت تستخدم مكونًا إضافيًا يسمى الإضافات الأساسية للعنصر، وهي أداة شائعة لإضافة ميزات مرئية مثل المخططات الزمنية ومعارض الصور ونماذج التجارة الإلكترونية وقوائم الأسعار.
باحث تهديد مستقل يدعى واي يان ميو ثيت اكتشف مؤخرا ما يعرف ب تضمين الملف الضعف في المنتج.
مكنت هذه الثغرة الأمنية المهاجمين من خداع المكون الإضافي للوصول إلى ملف من جانب الخادم وإدراجه ...
... باستخدام اسم ملف تم توفيره في طلب الويب الوارد.
ببساطة ، يمكن للزائر الضار أن يخدع خادمًا غير مصحح لتقديم ملف ليس من المفترض أن يقوم به ، مثل قاعدة بيانات اسم المستخدم الخاص بالخادم ، أو إجبار الخادم على تشغيل برنامج نصي لا ينبغي أن يخدع ، وبالتالي إنشاء تنفيذ التعليمات البرمجية عن بُعد (RCE) ) الفجوة.
كما تعلم بشكل استباقي ، عادةً ما يتم إساءة استخدام أخطاء RCE لخادم الويب لزرع برامج ضارة تسمح للمهاجمين بفعل شيء ما يضر بك على الفور ، وغالبًا ما يكون مكلفًا.
تتضمن الأمثلة النموذجية لكيفية استغلال المجرمين الإلكترونيين أخطاء RCE ما يلي:
- فتح الباب الخلفي، حتى يتمكنوا من بيع الوصول إلى الخادم الخاص بك إلى محتالين آخرين.
- إطلاق مشغل التشفير لسرقة الكهرباء أو الخدمات السحابية لتوليد الأموال لأنفسهم.
- إعداد أدوات مراقبة الشبكة للتطفل على بياناتك أو بيانات عملائك وسرقتها.
يشمل جانب الخادم
محتويات ملف خادم الويب ، يشار إليها غالبًا في المصطلحات باسم يشمل جانب الخادم، تُستخدم في برامج محتوى موقع الويب الديناميكي مثل WordPress بحيث لا تحتاج إلى تخزين HTML مُنشأ مسبقًا لكل صفحة على موقع الويب الخاص بك.
على سبيل المثال ، إذا كان موقع الويب الخاص بك يحتوي على صفحة مرتبة مثل هذا ...
... فإن النص المميز باللون الأزرق أعلاه فقط - المحتوى الأساسي الذي من المفترض أن يراه القارئ - يكون فريدًا في الصفحة:
إذا كان لديك موقع ويب ثابت تمامًا ومعروض مسبقًا وتريد تغيير إعدادات النمط أو تغيير صياغة الرأس والتذييل ، فستحتاج إلى تعديل أو إعادة إنشاء كل صفحة ويب على الموقع ، حتى تلك التي قد تنتهي حتى لا يتم زيارته أبدًا.
ولكن باستخدام أداة إنشاء مواقع الويب التي تسمح بالتضمينات من جانب الخادم ، قد تتمكن من إعادة كتابة صفحتك شيئًا كالتالي:
الفكرة هي أن الخادم سيقرأ في المحدد #include الملفات في وقت التشغيل وإضافتها إلى صفحة HTML التي يتم تقديمها فعليًا ، وبالتالي إنشاء صفحة الويب تلقائيًا عند الحاجة ، باستخدام أحدث إصدارات الأنماط وملفات الرأس والتذييل.
في كثير من الأحيان ، ستحتاج إلى تخصيص بعض جوانب الملفات التي تقوم بتضمينها ، مثل تكييف النمط ليناسب المستخدمين لديك ، على سبيل المثال استنادًا إلى ملف تعريف الارتباط الذي يوفره متصفحهم عند زيارتهم.
قد يتيح لك نظام التضمين من جانب الخادم لديك "تعديل" أسماء الملفات المضمنة ، على سبيل المثال مثل هذا:
إذا كنت تتساءل لماذا اخترنا "الشخصيات السحرية" ${...} في نظام البرمجة النصية من جانب الخادم المخترع أعلاه ، إنها إشارة إلى سيئ السمعة ضعف Log4Shell، حيث تم استخدام هذه الأحرف مع بيانات غير موثوق بها يوفرها المستخدم لخداع نظام البرمجة Log4j Java لتشغيل أوامر غير مرغوب فيها.
لا يمكن الوثوق في المدخلات غير الموثوق بها
يمكنك أن ترى المشكلة الواضحة هنا ، وهي أنه إذا كانت السلسلة النصية الخاصة ${cookie:usr_theme} أعمى مقتطفات من النص في usr_theme ملف تعريف الارتباط الذي يوفره المستخدم ، ويستخدمه لإنشاء اسم ملف ، فلا يوجد ما يمنع المستخدم الضار من طلب سمة تسمى ، على سبيل المثال ، ../../../../etc/passwd.
هذا من شأنه أن يخدع الخادم في # تضمين الملف content/theme/../../../../etc/passwd، والتي لن تقرأ في ملف من content/theme/ الدليل ، لكنه سينتقل لأعلى وصولاً إلى الدليل الجذر ، ثم ينزل مرة أخرى لأسفل إلى ملف /etc/ الدليل إلى محتويات ملف passwd الملف بدلا من ذلك.
حتى إذا لم يتم عرض ملف HTML الناتج بشكل صحيح بسبب المحتوى غير المتوقع في ملف يتم عرض قسم من الملف ، فسيظل الزائر يحصل على نسخة من ملف passwd ملف ، وبالتالي قائمة بجميع الحسابات وأسماء المستخدمين على الخادم الخاص بك.
والأسوأ من ذلك ، أن العديد من خوادم الويب وأنظمة إدارة المحتوى تتعامل مع بعض أسماء الملفات خاصة عند تضمينها.
Microsoft IIS ، على سبيل المثال ، يأخذ بعين الاعتبار الملفات ذات الامتداد .aspx خاص؛ العديد من خدمات الويب المستندة إلى Linux تفعل شيئًا مشابهًا إذا انتهى الملف بـ .php.
بدلاً من تضمين المحتويات الأولية للملف ، سيقوم النظام بتشغيل الملف كبرنامج (مكتوب ، على سبيل المثال ، في Visual Basic على خوادم Windows وفي PHP على خوادم Linux) ، ويتضمن الإخراج من البرنامج بدلاً من ذلك.
يؤدي ذلك إلى تسهيل إنشاء محتوى مثل الصفحات المخصصة ونتائج البحث لمرة واحدة عند الطلب ، لأن الكود المطلوب لإنشاء المحتوى مضمّن في مكان منطقي في شجرة الدليل التي تمثل بنية موقع الويب.
بالطبع ، هذا يعني أيضًا أن ملف #include التوجيه ، مثل التوجيه المستند إلى السمة الذي تصورناه أعلاه لسرقة ملف كلمة المرور ، يمكن استخدامه لتنفيذ التعليمات البرمجية عن بُعد وكذلك تسرب البيانات.
على سبيل المثال ، تخيل أننا استبدلنا "ملف تعريف الارتباط" أعلاه بنص مثل ../../scripts/listusers.php، لأننا علمنا أو يمكننا تخمين أن الخادم المستخدم يحتوي على برنامج PHP لأداة مساعدة بهذا الاسم لسرد جميع عمليات تسجيل الدخول إلى موقع الويب.
سنكون قادرين بعد ذلك على خداع الخادم لتشغيل هذا البرنامج النصي ، حتى لو لم يكن الغرض منه مطلقًا تشغيله من داخل صفحات الويب ، ولم يكن من المفترض أن يكون الوصول إليه متاحًا للأجانب على الإطلاق.
والأسوأ من ذلك ، قد نجد أنه يمكننا استخدام ../.. ("التحرك لأعلى في شجرة الدليل") لتنفيذ ملف نصي يسمى ، على سبيل المثال ، ../../uploads/pending/img000067.php.
عادة ، لن يكون هناك مثل هذا الملف و #include من الواضح أن هذا سيفشل ، ولكن إذا علمنا (أو اشتبهنا) في أن الخادم لديه ملف uploads/pending/ الدليل حيث تم تخزين العناصر التي يساهم بها المستخدم مثل التعليقات والصور ومقاطع الفيديو وما إلى ذلك مؤقتًا حتى يقرر المشرف ما إذا كان سيوافق عليها ...
... وإذا تمكنا من تحميل ملف "معلق" باستخدام اسم يمكننا توقعه لاحقًا ، فلن يكون لدينا فقط فجوة في تنفيذ التعليمات البرمجية عن بُعد ، بل سيكون لدينا تعسفي تماما ثقب تنفيذ التعليمات البرمجية عن بعد.
يمكننا أولاً تحميل برنامج نصي محتال ، بحيث يظهر الملف مؤقتًا في ملف uploads/pending/ الدليل ، وبعد ذلك مباشرة خداع الخادم لتنفيذه عن طريق تعيين ملف تعريف ارتباط خاص لبدء الهجوم.
للأسف، الإضافات الأساسية للعنصر تضمن المكون الإضافي خطأ من هذا النوع ، استنادًا إلى كود PHP الذي أنشأ اسم ملف للتضمين من جانب الخادم مثل هذا:
$sentbyuser = $_REQUEST['userinfo']; # ... $filetoinclude = sprintf( '%s/Template/%s/%s', $systemfilepath, $sentbyuser['name'], $sentbyuser['file_name'] # ... # ... no safety checks done on constructed filename # ... include $filetoinclude
هذا رمز غير مقبول تمامًا ، لأنه يبني المتغير $filetoinclude، ثم تضمينه ، دون إجراء أي فحوصات بحثًا عن شخصيات خطيرة مثل ../ التسلسل في المتغيرات غير الموثوق بها $sentbyuser['name'] و $sentbyuser['file_name'].
تم إخبار مبتكري المكون الإضافي بالثقب بواسطة مكتشف الأخطاء الأصلي Wai Yan Myo Thet ؛ لسوء الحظ ، كانت محاولتهم الأولى لفحص الأمان وتعقيم اسم الملف غير كافية لإبعاد المهاجمين المصممين.
متابَع مزيد من الحث من شركة Patchstack للأمان في WordPress ، تم تحديث المكون الإضافي مرتين أخريين في تتابع سريع لدرء الهجمات التي تسببها بيانات المستخدم الضارة الواردة.
وفقًا لـ Patchstack ، لا يتم استخدام رمز عربات التي تجرها الدواب إلا إذا تم تمكين بعض أدوات الويب المرتبطة بالمعرض ، بحيث لا يتم إصلاحها كلها الإضافات الأساسية للعنصر المواقع عرضة للخطر. ومع ذلك ، فإننا نوصي بالتصحيح على الفور على أي حال ، بدلاً من ترك فجوة RCE سهلة الاستخدام والتي يمكن أن تظهر في أي وقت بناءً على تغيير تكوين الخادم الذي كان لولا ذلك غير مثير للجدل.
ماذا ستفعلين.. إذًا؟
- في حالة الإضافات الأساسية للعنصر المستخدمين. تحقق من أن لديك نسخة 5.0.6 [صدر في اليوم الذي كتب فيه هذا المقال] أو بعد ذلك. تم اكتشاف الخطأ في الإصدار 5.0.3 ، ولكن تم استبدال التصحيح 5.0.4 بسرعة بواسطة التحديث المحدث 5.0.5 ، والذي تم استبداله بـ Quickl بدوره بواسطة 5.0.6.
- لمطوري الويب. لا يجب أن نقول هذا كثيرًا كما نفعل (أو ربما على الإطلاق) في عام 2022 ، لكننا سنقول ذلك على أي حال: تحقق من صحة المدخلات الخاصة بك.
لا تتحقق فقط من الإدخال البرمجي عندما تعرف على وجه اليقين أنه جاء من مصدر غير موثوق به مثل طلب HTTP.
حتى إذا كنت تعتقد أنه يمكنك الوثوق في العملية الأولية أو المستخدم الذي قدم إدخالاتك ، فتحقق من ذلك على أي حال ، في حالة احتواء هذه العملية الموثوقة نفسها على خطأ ، أو الاعتماد بطريقة ما على محتوى ملوث بدأ بشكل أكبر في سلسلة توريد البيانات.
