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 (أو أي مستخدم تسميه) لمدة ساعة، وتجاوز المصادقة الثنائية، وقراءة أو الكتابة فوق ملفات ذلك الشخص.


ID	لا يوجد CVE بعد
CWE	CWE-863, CWE-269
CVSS	High: 8.8 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
Product	Nextcloud Server
Affected	35.0.0 (`da02f41`) official `nextcloud:35.0.0-apache`
Auth	مسؤول إعدادات Webhooks المفوَّض (`IDelegatedSettings`)
License	GNU Affero GPL v3.0
Lab	`127.0.0.1` فقط

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

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

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

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

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

كيف وجدتها

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

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

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

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

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

طرق تفشل بها هذه دون أن تعلّمك شيئاً: update 403 (المتحكم يطابق create بالفعل)؛ create يصدر الرموز بالفعل (#60543 ليس على البناء)؛ authentication فارغ في الـ catcher (لم يصدر 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 الخاص بـ create إلى update(). حتى يتم إصدار ذلك، لا تفوّض إعدادات Webhooks إلى مجموعات غير مسؤولة.

المراجع

github.com/nextcloud/server tag v35.0.0 (da02f41)
إصلاح create-only القريب: 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

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

كيف وجدتها

المختبر

الإصلاح

المراجع

الترخيص