nextcloud-webhook-tokenneeded

Nextcloud Server 35.0.0 - Nextcloud GmbH

تقوم الدالة WebhooksController::create() بتصفير tokenNeeded ما لم يكن المستدعي مسؤولاً كاملاً على مستوى المثيل. أما update() فلا تفعل ذلك. يمكن لمسؤول إعدادات Webhooks المفوَّض (غير الموجود في admin) تخزين tokenNeeded.user_ids: ["admin"] على webhook موجود، ثم الحصول على كلمة مرور تطبيق PERMANENT_TOKEN غير محدودة النطاق صالحة لمدة ساعة لذلك الـ uid عند إطلاق الحدث.

يمكن لجهة فاعلة سيئة لم يُؤتمن سوى على إدارة الـ webhooks أن تسجّل الدخول باسم admin (أو أي مستخدم تسمّيه) لمدة ساعة، وتتجاوز المصادقة الثنائية (2FA)، وتقرأ ملفات ذلك الشخص أو تكتب فوقها.


المعرّف	لا يوجد CVE بعد
CWE	CWE-863, CWE-269
CVSS	عالٍ: 8.8 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
المنتج	Nextcloud Server
المتأثر	35.0.0 (`da02f41`) الإصدار الرسمي `nextcloud:35.0.0-apache`
المصادقة	مسؤول إعدادات Webhooks المفوَّض (`IDelegatedSettings`)
الترخيص	GNU Affero GPL v3.0
المختبر	`127.0.0.1` فقط

ما يمكن للمهاجم فعله

لقد أوكلت إلى شخص ما مهمة إعدادات Webhooks. وهو ليس في مجموعة admin. ومع ذلك يسمح له Nextcloud بتعديل webhook موجود بحيث يقوم الخادم، عند الحدث المطابق التالي، بإرسال تسجيل دخول صالح لمدة ساعة إلى بريده لأي uid يدرجه، بما في ذلك admin.

وبذلك التسجيل يمكنه:

فتح جميع ملفات ذلك الشخص (وليس فقط ما كان من المفترض أن يراه الـ webhook)
تنزيل تلك الملفات والكتابة فوقها
استخدام Files / WebDAV بصفة ذلك الشخص
تجاوز المصادقة الثنائية (2FA) (فهذه كلمة مرور تطبيق، وليست مطالبة بكلمة مرور)

لا يحتاج إلى shell PHP على المضيف. ولا يحتاج إلى أن يكون مسؤولاً كاملاً على مستوى المثيل. أما غريب على الإنترنت بلا حساب فلا يستطيع فعل ذلك. الثغرة تكمن في الموظف الذي وثقت به بالفعل لإدارة الـ webhooks، وهو ينتحل شخصية من لم تثق بهم.

كيف اكتشفتها

WebhooksController موسومة بـ #[AuthorizedAdminSetting(settings: Admin::class)]. وAdmin تطبّق IDelegatedSettings. وهكذا يسلّم Nextcloud لوحة إعدادات إلى مجموعة ليست admin.

يطلب tokenNeeded من الخادم إرفاق رموز مصادقة لـ uids محددة عند إطلاق الـ webhook. وتُصدر TokenService::createEphemeralToken رمز IToken::PERMANENT_TOKEN مع password = null. كلمة مرور تطبيق. والمصادقة الثنائية قد تجاوزتها بالفعل.

قيّد PR #60543 عملية الإنشاء: ما لم تكن مسؤولاً كاملاً على مستوى المثيل، يُصفَّر tokenNeeded. أنشأت webhook بصفة المستخدم المفوَّض hooker مع tokenNeeded.user_ids: ["admin"]. وكان tokenNeeded المخزَّن []. فالإنشاء مقيَّد. ولهذه اللحظة يبدو الأمر كأنه تصحيح مكتمل.

ثم أرسلت نفس الجسم عبر POST إلى /webhooks/{id}. وكان user_ids المخزَّن ['admin']. فـ update() لم تنسخ شرط if قط.

أرسلت ملفاً عبر PUT بصفة hooker ليُطلق NodeCreatedEvent. يشغّل Cron الدالة WebhookCall. ويحتوي JSON الملتقِط على authentication.user_ids.admin.token. وأعاد طلب GET بحمل Bearer لملف الشاهد الخاص بالمسؤول 200، مع X-User-Id: admin.

طرق يموت بها هذا دون أن تعلّمك شيئاً: update يعيد 403 (وحدة التحكم تطابق الإنشاء بالفعل)؛ الإنشاء يصدر الرموز بالفعل (#60543 غير موجود في البناء)؛ authentication فارغة في الملتقِط (لم يصدر cron الرمز)؛ مسار ترويسة ExApp (مستخدم المختبر هو المفوَّض hooker).

المختبر

cd lab
./run.sh

استهدف فقط http://127.0.0.1:18320 (Nextcloud) و :18321 (catcher).

SUCCESS NEXTCLOUD-WEBHOOK-TOKENNEEDED who=delegated-webhook-admin uid=admin NEXTCLOUD-WEBHOOK-TOKENNEEDED-WITNESS

الإصلاح

انسخ إجراء تصفير isAdmin الخاص بإنشاء إلى update(). وإلى أن يتم شحن ذلك، لا تفوّض إعدادات Webhooks إلى مجموعات غير إدارية.

المراجع

github.com/nextcloud/server وسم v35.0.0 (da02f41)
إصلاح قريب خاص بالإنشاء فقط: nextcloud/server#60543
Abraxas Labs: abraxaslabs.tech · github.com/abraxas · @abraxas_null

الترخيص

GNU Affero GPL v3.0. راجع LICENSE. مختبر loopback فقط. دون أي ضمان.

الأكثر شعبية

nextcloud-webhook-tokenneeded

nextcloud-webhook-tokenneeded

ما يمكن للمهاجم فعله

كيف اكتشفتها

المختبر

الإصلاح

المراجع

الترخيص