CVE-2024-37010

استغلال الثغرة CVE-2024-37010: الوصول إلى التخزين الخارجي للمستخدمين الآخرين والحركة الجانبية:

https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/

https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage

مقدمة

يحول Owncloud الخادم إلى سحابة لتخزين الملفات، مثل Google Drive. وهذا يتيح للشركات، على سبيل المثال، توفير سحابة للموظفين دون أن يتم إدارتها بواسطة طرف ثالث.

إذا قام المسؤولون بتكوينه بهذه الطريقة، يمكن للمستخدمين أيضًا توصيل وحدات تخزين خارجية، مثل السحب الأخرى أو FTP أو Google Drive، لتجميع الملفات في سحابة واحدة وبالتالي تسهيل الحياة على المستخدمين.

بمجرد إنشاء التخزين الخارجي الخاص بنا، يمكننا تحديث هذا النموذج لتغيير حقل "اسم المجلد" على سبيل المثال. عند تحديث النموذج، يتم إرسال طلب مع النموذج بأكمله بصيغة JSON. في هذا النموذج، حقل "المعرف" (ID)، وهو عدد صحيح، هو معرف التخزين الخارجي الخاص بنا، والذي يولده الخادم عند إنشاء التخزين.

2. IDOR IDOR

لنتخيل أن مستخدمًا آخر على Owncloud، مثل المسؤول، لديه أيضًا تخزين خارجي، بمعرف "18".

الآن، لنقم بإعادة تشغيل طلب تحديث النموذج كمستخدم "normal_user"، بدون أي صلاحيات خاصة، ولكن نغير المعرف إلى 18، وهو التخزين الخارجي الخاص بالمسؤول.

1. أدخل معرف تخزين المسؤول
2. قم بتعيين اسم تخزين عشوائي "storage_pwned".
3. للتأكد، سنحدد أيضًا مضيفًا عشوائيًا، في هذه الحالة هو Burp collaborator. ملاحظة مهمة: تغيير المضيف ليس إجباريًا. تغيير المضيف يعني كسر تكوين التخزين، وبالتالي لن يتمكن خادم Owncloud من استرداد الملفات من التخزين الأصلي.

بمجرد إرسال الطلب، يواجه الخادم خطأ 404 (4) ويخبرنا أنه لم يجد أي تخزين بالمعرف الذي حددناه (5).

ومع ذلك، عندما نتصل بحساب المسؤول، هذا ما نراه:

تم تحديث تخزين المسؤول.

1. تم تغيير اسم التخزين إلى "storage_pwned".
2. تم استبدال المضيف بعنوان collaborator.
3. والأهم من ذلك: تمت إضافة المستخدم "normal_user" إلى قائمة المستخدمين المصرح لهم بالوصول إلى التخزين.

إذا قمنا بتسجيل الدخول مرة أخرى باسم "normal_user"، يمكننا أن نرى أن لدينا الآن إمكانية الوصول إلى "storage_pwned"، وهو تخزين المسؤول.

تمكن المستخدم أ من تحديث تخزين المستخدم ب واستعادة حقوق الوصول إليه. نذكر أن المستخدم أ يجب ألا يعدل المضيف أثناء طلب التحديث، حتى لا يكسر تكوين المستخدم ب، وبالتالي يتمكن من الوصول إلى ملفات الأخير.

هذا هو الكود المستخدم لتحديث التخزين الخارجي.

أولاً، يمكننا أن نرى أنه لا يوجد التحقق من حقوق المستخدم الذي أرسل الطلب. لا يتحقق الكود من أن التخزين ينتمي إلى المستخدم الذي يقوم بالطلب. وهذا يفسر كيف تمكن "normal_user" من تحديث تخزين المسؤول.

ثانيًا، يمكننا أن نرى أنه في كل تحديث، يضيف الكود المستخدم الذي قام بالطلب للتو إلى قائمة المستخدمين المصرح لهم بالاتصال بالتخزين، مما يفسر كيف حصل "normal_user" بطريقة سحرية على إذن الوصول إلى تخزين المسؤول بعد التحديث.

خلاصة

في هذا المثال، رأينا كيف يمكن لمستخدم واحد الحصول على وصول كامل إلى التخزين الخارجي لمستخدم آخر وبالتالي الوصول إلى ملفاته الشخصية. هذا بالفعل يجعلها ثغرة حرجة إلى حد ما.

3. أبعد من ذلك...

في هذه المرحلة، كما ترون، هذه IDOR (مرجع كائن مباشر غير آمن) هي بالفعل ثغرة كبيرة. لكن دعنا نحاول الاستمرار في استغلالها لزيادة الأثر الذي يمكن أن تحدثه.

للقيام بذلك، دعنا نفهم عملية المصادقة التي يقوم بها خادم Owncloud للتخزين الخارجي لاسترداد الملفات. بالنسبة لأنظمة المصادقة الأساسية التي تستخدم زوج اسم مستخدم/كلمة مرور بسيط، سيقوم خادم السحابة ببساطة

الآن، لنتخيل أن مهاجمًا تمكن من تحديث هذا التكوين عن طريق تغيير المضيف إلى عنوان يتحكم به. هذا يعني أن خادم Owncloud سيرسل الآن بيانات الاعتماد إلى هذا العنوان الجديد، الذي يتحكم به المهاجم.

هذا بالضبط ما يمكننا فعله بفضل ثغرتنا.

عندما نعيد تشغيل طلب التحديث مع تحديد معرف تخزين مستخدم آخر، كل ما علينا فعله هو تغيير المضيف عن طريق تحديد، على سبيل المثال، Burp collaborator الخاص بنا.

بهذه الطريقة، عندما يعيد المستخدم الاتصال، يحاول خادم Owncloud المصادقة مع collaborator الخاص بنا عن طريق إرسال بيانات اعتماد المستخدم إليه.

بطريقة سحرية، يتلقى collaborator طلب المصادقة من خادم Owncloud مع بيانات الاعتماد المشفرة بـ Base64.

وبذلك نكون قد استرجعنا بيانات اعتماد النص الصريح من التخزين الخارجي للمسؤول.

إضافة صغيرة...

بالنسبة للمصادقة على التخزين الخارجي، يمكنك استخدام بيانات اعتماد Owncloud الخاصة بك لتسجيل الدخول، إذا كنت تستخدم نفس كلمة المرور مثلاً. عند طلب تحديث التخزين الخارجي، يمكنك تحديد "password::sessioncredentials" في حقل "authMechanism".

سيقوم خادم Owncloud بعد ذلك بحفظ بيانات اعتمادنا بنص واضح في المرة التالية التي نتصل بها، ونقلها إلى جهاز التخزين الخارجي الخاص بنا للمصادقة.

لذا يمكنك رؤية ما سيأتي...

هذا يعني أن المهاجم يمكنه أيضًا تفعيل هذه الآلية لتخزين خارجي لمستخدم آخر وبالتالي نقل بيانات اعتماد جلسة Owncloud الخاصة بالضحية بنص واضح إلى مضيف يتحكم به، كما فعلنا للتو.

4. ملخص المخاطر

لذا تسمح CVE-2024-37010 لمهاجم لديه حساب على خادم Owncloud بما يلي:

• الحصول على وصول للقراءة/الكتابة إلى الملفات في التخزين الخارجي للمستخدمين الآخرين.
• الحصول على معرفات نصية واضحة لأجهزة التخزين الخارجية المتصلة.
  • الانتقال إلى التخزين الخارجي.
• الحصول على بيانات اعتماد حساب Owncloud غير المشفرة للمستخدمين الذين لديهم تخزين خارجي.
  • الاستيلاء على الحساب ورفع الصلاحيات.

التسلسل الزمني

• 03/11/2024 - اكتشاف الثغرة
• 12/03/2024 - إرسال التقرير إلى Owncloud
• 09/09/2024 - الإعلان العام و CVE من Owncloud