mcorybillington/suitecrm-rceتحليل حول CVE-2020-28328: تنفيذ تعليمات برمجية عن بُعد عبر ملف سجل SuiteCRM مع بعض ثغرات البرمجة النصية عبر المواقع (XSS) كمكافأة إضافية
اكتشفت مؤخرًا ثغرتين في SuiteCRM توفران سلسلة هجوم تتيح لمستخدم بصلاحيات منخفضة تحقيق تنفيذ الكود على نظام التشغيل الأساسي. سلسلة الهجوم هي Cross-Site Scripting، والتي يمكن استخدامها لتنفيذ Cross-Site Request Forgery، مما يؤدي إلى تنفيذ كود عن بُعد (Remote Code Execution) عبر العبث بإعدادات التطبيق وتسميم ملف سجل. يتحقق كل ذلك عبر رفع ملف يحتوي على كود JavaScript خبيث، حيث يمكن لمستخدم بصلاحيات منخفضة خداع مستخدم بصلاحيات إدارية لتشغيله. توضح ملفات إثبات المفهوم (Proof-Of-Concept) والفيديو المرفق قيام مستخدم بصلاحيات منخفضة بتنفيذ هذا الهجوم والحصول على قشرة عكسية (reverse shell) على النظام الذي يستضيف SuiteCRM.
تم إصلاح هذا في الإصدار 7.11.17 من SuiteCRM.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
لا أوافق تمامًا على هذا التقييم لأن الاستغلال يتطلب وصولًا إداريًا، مما سيغيّر PR:L إلى PR:H ويعدّل النتيجة النهائية من 8.8 إلى 7.2.
سأقيّمها على النحو التالي: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
المرجع: https://nvd.nist.gov/vuln/detail/CVE-2020-28328
SuiteCRM الإصدار 7.11.15
توجد Cross-Site Scripting المخزنة (Stored XSS) في رفع الملفات ضمن 'Create Documents'. يمكن لمستخدم بصلاحيات منخفضة رفع ملف بأي محتوى. يمكن للمستخدم بعد ذلك فحص الرابط المقدم لتنزيل هذا المستند وتحديد موقع الملف على نظام الملفات عبر العثور على معامل id. هذه القيمة الطويلة والعشوائية هي اسم الملف داخل دليل /uploads/. يمكن للمستخدم وضع كود JavaScript تعسفي في هذا الملف ثم إرسال الرابط إلى مستخدم آخر. يمكن استخدام هذا لاختطاف جلسة مستخدم آخر و/أو تنفيذ إجراءات نيابةً عن ذلك المستخدم، كما سيظهر في فيديو إثبات المفهوم (PoC).
بعد اكتشاف إمكانية التحول إلى مسؤول عبر اختطاف الجلسة باستخدام Cross-Site Scripting، اكتشفت بعد ذلك أنني أستطيع التحكم في خصائص النظام ضمن 'Admin → System Settings'، وتحديدًا خاصية ملف السجل. كانت امتدادات ملفات السجل محظورة بشكل جيد، لكنني تمكنت من استخدام BurpSuite لتحديث قيمة 'Log File Name' إلى أي قيمة تعسفية، بما في ذلك امتدادات .php. قمت بذلك عن طريق إرسال طلب دون تغيير أي شيء والتقاط طلب POST الذي يقوم فعليًا بتحديث القيم. غيّرت اسم الملف عبر معامل logger_file_name إلى shell.php واكتفيت بجعل حقل 'Extension' فارغًا. أدى ذلك إلى إنشاء ملف php يمكنني الوصول إليه من المتصفح في جذر الويب (webroot)، لكنني كنت بحاجة إلى بعض كود php داخل الملف لتنفيذه.
بعد ذلك، فحصت المخرجات في الملف ولاحظت أنني أستطيع التحكم في الإدخال إلى الملف عبر خصائص المستخدم إذا ما قمت بتحديث مستخدم (مثل الاسم الأول أو اسم العائلة)، وكان التسجيل (logging) مضبوطًا على info (وهو ما أعتقد أنه الإعداد الافتراضي...). لذا، التقطت طلبًا في Burp وأدخلت بعض كود php <?php $id =`id`; echo $id; ?> في حقل last_name في النموذج. نتج عن ذلك إخراج أمر id على Linux في سياق مستخدم خادم الويب، www-data. الأحرف الوحيدة التي تمكنت من ملاحظة أنها مُهرّبة (escaped) بناءً على ملف السجل هي علامات الاقتباس المفردة، وعلامات الاقتباس المزدوجة، والخطوط المائلة العكسية. يمكنك التحقق من ذلك عبر تنفيذ tail على ملف سجل sql في الواجهة الخلفية.
تمكنت من تنفيذ كل هذا كمستخدم مسؤول لأنني تمكنت من الحصول على ملفات تعريف ارتباط الجلسة (session cookies)، ولكن للحصول على سلسلة فعالة، كنت بحاجة إلى تنفيذ ذلك عبر JavaScript في سياق المستخدم المسؤول. تمكنت من كتابة سكربت لهذا الغرض باستخدام بضعة طلبات fetch لتنفيذ كل من طلبات POST هذه. قام الطلب الأول بتحديث خصائص النظام، وقام الثاني بتحديث حقل 'Last Name' للمستخدم المسؤول، بينما نفّذ الأخير طلب GET على ملف السجل المُنشأ حديثًا والذي يحتوي على كود php خبيث. كان كود php الخبيث ينفذ طلب curl ضد جهازي، ويسحب قشرة عكسية bash ثم يمرر مخرجات طلب curl مباشرة إلى bash، لتنفيذ الكود. ثم قمت برفع هذا باستخدام نفس الأسلوب الذي ناقشته في قسم XSS وأعدت زيارة الرابط الجديد كمستخدم مسؤول. مع خادم ويب يستضيف ملف bash الخاص بي ومستمع netcat قيد التشغيل، تمكنت من الحصول على قشرة عكسية.
تأكد من تعيين AllowOveride All في Apache. لا يمتلك nginx هذا الإعداد ولم أختبره على nginx.
قم بالتحديث إلى أحدث إصدار من SuiteCRM، أو على الأقل الإصدار 7.11.17.
هذا هو الإصلاح المحدد. Commit 1618af16eaa494c4551bac961e5ac8fc3d87ab8c
كانت SuiteCRM سريعة الاستجابة طوال عملية الإبلاغ. اعترفوا بثغرة RCE، والتي تم إصلاحها. كانت XSS ناتجة عن إعدادات خادم الويب، لذا لم يعترفوا بها كثغرة أمنية. ومع ذلك، أشاروا إلى أنهم سيحدّثون الوثائق في ضوء ذلك.
06 AUG 2020 -> تم الإبلاغ عن الثغرتين إلى [email protected]
07 AUG 2020 <- أكدت SuiteCRM استلام التقرير وأحالت المشكلة إلى فريق الأمان الداخلي
21 AUG 2020 -> تواصلت مع [email protected] لمتابعة الأمر
25 AUG 2020 <- ردت SuiteCRM بشأن إعدادات خادم الويب/XSS
26 AUG 2020 -> رددت للإشارة إلى أن اقتراح AllowOveride All يخفف من ثغرة XSS
16 SEP 2020 -> تواصلت مع [email protected] لمتابعة الأمر
17 SEP 2020 <- ردت SuiteCRM لتأكيد المشكلة كمشكلة جزئية
29 OCT 2020 تم إصدار التحديث
03 NOV 2020 -> تواصلت مع [email protected] للتأكد من عدم الحاجة إلى أي شيء آخر من جهتهم قبل نشر التقرير
05 NOV 2020 <- ردت SuiteCRM
لقد أصدرنا الآن تصحيحًا لهذه المشكلة وهو في المجال العام، ولا توجد مشكلة من منظورنا في قيامك بكتابة منشور مدونة حول الثغرات.
05 NOV 2020 -> تم طلب CVE من قبلي
06 NOV 2020 <- تم إصدار CVE-2020-28328
كان التعامل معهم سهلًا للغاية، وأخطط بالتأكيد لمواصلة البحث عن الثغرات في هذا البرنامج والإبلاغ عنها!
