إثبات مفهوم الكشف عن معلومات المراقب المخفي في Kener

يحتوي هذا المستودع على إثبات مفهوم صغير بلغة Python لاختبار مشكلة الكشف عن المعلومات (CWE-200) في نقاط نهاية المراقب العامة الخاصة بـ Kener.

إصدارات Kener المتأثرة هي من 4.0.0 حتى 4.1.5، وتم إصلاحها في 4.1.6

https://www.rapid7.com/db/vulnerabilities/cve-2026-105030/

ترتبط المشكلة بعمليات البحث عن المراقبين المعتمدة على الوسوم (tags) التي يمكن أن تكشف عن مراقبين مخفيين أو غير نشطين عندما لا يتم تصفية الاستعلام بشكل صحيح.

هذا الإثبات مخصص لـ:

• بيئات التطوير المحلية
• اختبارات الأمان المصرح بها
• التحقق من التصحيح/الإصلاح في بيئة مُتحكَّم بها

لا تستخدم هذا الإثبات ضد أهداف غير مصرح بها

النطاق

يوضح هذا الإثبات أن المراقب المخفي أو غير النشط قد لا يزال يتم إرجاعه بواسطة نقاط النهاية العامة عندما لا يفرض البحث تصفية مثل:

• status = ACTIVE
• is_hidden = NO

السلوك المُصلَّح هو أن هذه النقاط يجب أن تُرجع 404 / لا تطابق للمراقبين المخفيين أو غير النشطين.

المتطلبات الأساسية

• Python 3.9+
• حزمة requests
• نسخة محلية أو اختبارية من Kener
• الوصول إلى قاعدة البيانات لإنشاء مراقب اختباري

تثبيت التبعيات:

python3 -m pip install requests

البدء السريع

1. شغّل تطبيق Kener محليًا
2. أنشئ مراقبًا اختباريًا مخفيًا وغير نشط
3. شغّل سكربت الإثبات
4. قارن السلوك مع الإصدار المُصلَّح

إنشاء مراقب اختباري

إذا كان لديك وصول إلى قاعدة البيانات، أنشئ مراقبًا لا يجب أن يكون مرئيًا للعامة.

لـ Postgres:

INSERT INTO monitors (
  tag, name, description, status, is_hidden,
  category_name, monitor_type, cron, default_status,
  created_at, updated_at
) VALUES (
  'internal-secret-monitor',
  'Internal Secret Monitor',
  'Hidden/inactive monitor used for PoC',
  'INACTIVE',
  'YES',
  'Home',
  'HTTP',
  '* * * * *',
  'UP',
  NOW(),
  NOW()
);

يمكنك أيضًا استخدام اسم وسم مختلف إذا لزم الأمر.

تأكد من أن السجل:

• status = 'INACTIVE' أو غير نشط بأي شكل آخر
• is_hidden = 'YES'

الآن شغّل سكربت الإثبات.

الإصدار القابل للاستغلال

إذا كان التطبيق قابلًا للاستغلال، فقد تُرجع نقطة نهاية واحدة أو أكثر:

• HTTP 200
• JSON أو HTML يشير إلى وجود مراقب
• بيانات وصفية للمراقب مثل الاسم، وقت التشغيل، زمن الاستجابة، الحالة، الطوابع الزمنية

يشير هذا إلى أن المراقب المخفي/غير النشط يتم كشفه عبر واجهة برمجة تطبيقات عامة.

الإصدار المُصلَّح

مع التصفية الصحيحة، يجب أن تكون الاستجابة بدلًا من ذلك:

• HTTP 404
• أو نتيجة فارغة
• أو رسالة عامة "Monitor not found"

هذا هو السلوك المتوقع بعد الإصلاح:

const monitors = await db.getMonitors({
  tag,
  status: GC.ACTIVE,
  is_hidden: GC.NO,
});

لماذا هذا مهم

المشكلة ليست مجرد سرية الوسم. المشكلة هي أن نقطة النهاية العامة يجب ألا تكشف أبدًا عن بيانات مراقب مخفي أو غير نشط. إذا عرف المهاجم وسم مراقب بأي وسيلة، فقد يتمكن من الوصول إلى:

• تفاصيل وقت التشغيل
• مخططات زمن الاستجابة
• نوافذ الصيانة
• سجل الحوادث
• البيانات الوصفية التشغيلية

لا يزال على المهاجم إيجاد الوسم بطريقة ما، عن طريق التخمين، أو القوة الغاشمة، أو وسائل أخرى.

استكشاف الأخطاء وإصلاحها

نقطة النهاية تُرجع 404 عندما يجب أن تُرجع 200

تحقق من أن:

• المراقب موجود
• الوسم مطابق تمامًا
• المراقب مخفي/غير نشط كما هو متوقع

لا استجابة / رفض الاتصال

تأكد من أن التطبيق يعمل محليًا وأن المنفذ مطابق:

BASE_URL=http://localhost:3000

التطبيق لديه HTTPS مُفعَّل

استخدم عنوان URL الصحيح، على سبيل المثال:

BASE_URL=https://localhost:3000

الاستخدام القانوني والأخلاقي

استخدم هذا الإثبات فقط:

• على نسختك الاختبارية الخاصة
• في بيئة تطوير محلية
• على الأنظمة المصرح لك صراحةً باختبارها

لا تشغّل هذا ضد أنظمة خارجية أو تابعة لطرف ثالث دون إذن.

الملخص

يتحقق هذا الإثبات مما إذا كان وسم مراقب مخفي أو غير نشط لا يزال يمكن الوصول إليه عبر نقاط نهاية واجهة برمجة تطبيقات Kener العامة.

• السلوك القابل للاستغلال: واجهة برمجة التطبيقات العامة تكشف بيانات مراقب مخفي/غير نشط
• السلوك المُصلَّح: يتم إرجاع المراقبين النشطين غير المخفيين فقط
• الهدف: التحقق من التصحيح الأمني في بيئة مُتحكَّم بها