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

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

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

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

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

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

• بيئات التطوير المحلية
• اختبارات الأمان المصرح بها
• التحقق من التصحيح/الإصلاح في بيئة خاضعة للرقابة

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

النطاق

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

• status = ACTIVE
• is_hidden = NO

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

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

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

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

python3 -m pip install requests

البدء السريع

1. شغّل تطبيق Kener محليًا
2. أنشئ مراقبًا تجريبيًا مخفيًا وغير نشط
3. شغّل سكربت PoC
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'

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

البناء المصاب بالثغرة

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

• 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

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

استخدم هذا PoC فقط:

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

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

الملخص

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

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