dungsocool/cve-2019-20933تقرير معملي خطوة بخطوة يوضح تجاوز المصادقة في InfluxDB عبر رموز JWT المزورة (CVE-2019-20933)، بما في ذلك الاستغلال وما بعد الاستغلال وإرشادات المعالجة.
نبدأ بما يعمل في البيئة. نقوم بإدراج جميع الحاويات النشطة:
docker ps
الضحية تعرض منفذًا واحدًا فقط: 8086.
حاليًا، لا تتوفر لدي معلومات مفصلة عن الهدف. من مخرجات docker ps، يظهر أن النظام يعرض خدمة واحدة فقط للخارج على المنفذ 8086، وهي مرتبطة بالخدمة داخل الحاوية. هذا هو سطح الهجوم الأساسي الذي يجب تحليله.
بدلاً من الوصول إليه مباشرة عبر المتصفح، نستمر في تحديد بصمة الخدمة باستخدام Nmap لمعرفة الخدمة التي تعمل على المنفذ 8086:
nmap -sV -sC -p 8086 192.168.3.137
تظهر نتائج الفحص أن المنفذ 8086 هو خدمة HTTP الخاصة بـ InfluxDB OSS 1.6.6. هذه قاعدة بيانات للسلاسل الزمنية (Time-Series Database) معرّضة عبر واجهة برمجة تطبيقات HTTP، وليست تطبيق ويب تقليديًا.
InfluxDB هي قاعدة بيانات سلسلة زمنية (TSDB) مفتوحة المصدر مكتوبة بلغة Go. على عكس قواعد البيانات العلائقية RDBMS (المحسّنة للمعاملات الدقيقة) أو Elasticsearch (المحسّنة للبحث النصي)، أُنشئت InfluxDB لغرض واحد: التعامل مع أحجام كتابة ضخمة (إنتاجية كتابة عالية) والاستعلام عن البيانات على طول المحور الزمني بزمن استجابة منخفض.
بما أنه تم تحديد بصمة الخدمة على أنها InfluxDB، فإن الخطوة التالية هي الرجوع إلى كيفية تواصل InfluxDB مع العملاء. وفقًا لوثائق InfluxDB v1 الخاصة بواجهة برمجة التطبيقات HTTP، فإن المنفذ 8086 هو منفذ واجهة برمجة التطبيقات الافتراضي. تتضمن نقاط النهاية الرئيسية المهمة ما يلي:
/ping: يتحقق من الحالة التشغيلية للخادم./query: يرسل استعلامات InfluxQL لقراءة البيانات الوصفية أو البيانات./write: يكتب بيانات السلاسل الزمنية إلى قاعدة البيانات.⇒ تفكير: بعد أن يحدد Nmap الخدمة على أنها InfluxDB http admin 1.6.6، لا نستمر في اختبارها وكأنها موقع ويب قياسي. بالنسبة لتطبيقات الويب، نبحث عادةً عن المسارات أو نماذج تسجيل الدخول أو الدلائل. ومع ذلك، مع InfluxDB، يكمن سطح الهجوم داخل واجهة برمجة التطبيقات HTTP. لذلك، نحتاج إلى التحول إلى اختبار نقاط نهاية واجهة برمجة التطبيقات القياسية الخاصة بـ InfluxDB لتحديد ما إذا كانت واجهة البرمجة تتطلب مصادقة. وبالتالي، فإن اتجاه الاختبار التالي ليس الوصول إلى / عبر المتصفح، بل إرسال الطلبات مباشرةً إلى نقاط نهاية واجهة برمجة التطبيقات الخاصة بـ InfluxDB.
/pingبعد تحديد المنفذ 8086 على أنه واجهة برمجة تطبيقات InfluxDB HTTP، تحقق من نقطة نهاية /ping للتأكد من أن الخدمة تعمل:
curl -i <http://192.168.3.137:8086/ping>
استجابة 204 No Content تؤكد أن InfluxDB تعمل بشكل طبيعي. كما تؤكد الترويسات أن إصدار الخدمة هو InfluxDB OSS 1.6.6
/querycurl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"
نقطة نهاية /query لا تسمح بالاستعلامات المباشرة دون بيانات اعتماد المصادقة. هذا يؤكد أن InfluxDB مفعّل لديها المصادقة وتمنع جميع الاستعلامات المجهولة المرسلة إلى النظام.
أنتقل إلى التفكير: هل يحتوي إصدار InfluxDB 1.6.6 على أي ثغرة أمنية تسمح بتجاوز آلية المصادقة؟
بالرجوع إلى قواعد بيانات الثغرات الأمنية العامة، نجد أن إصدارات InfluxDB الأقدم من 1.7.6 تتأثر بثغرة CVE-2019-20933. هذه ثغرة تجاوز مصادقة (Authentication Bypass) داخل دالة المصادقة في InfluxDB، وترتبط بمعالجة رموز JWT بسريّة مشتركة فارغة.
بما أن الهدف يعمل بإصدار InfluxDB 1.6.6، وهو أقل من الإصدار المُصحح 1.7.6، فإن الخدمة تقع ضمن نطاق الإصدارات المتأثرة.
يمكن استنتاج ما يلي:
Service: InfluxDB OSS
Version: 1.6.6
Authentication: Enabled
CVE mapping: CVE-2019-20933
Impact: Authentication Bypass
Status: Version vulnerable
⇒ تفكير: في البداية، تعيد نقطة نهاية /query استجابة 401 Unauthorized، مما يشير إلى أن آلية المصادقة نشطة. ومع ذلك، فإن تفعيل المصادقة لا يعني أمانًا مطلقًا. عندما يتم تحديد بصمة version على أنه 1.6.6، نحتاج إلى ربطه بثغرات CVE المعروفة. تشير النتائج إلى أن هذا الإصدار يقع ضمن النطاق المتأثر بـ CVE-2019-20933، مما يعني أنه من الممكن تجاوز آلية المصادقة التي تحمي نقطة نهاية /query. بناءً على نتائج التحديد هذه، ستركز مرحلة الاستغلال على التحقق من CVE-2019-20933 من خلال توليد رمز JWT مناسب لتجاوز المصادقة وتنفيذ استعلامات على نقطة نهاية /query.
تحدث ثغرة CVE-2019-20933 في دالة authenticate داخل ملف services/httpd/handler.go الخاص بـ InfluxDB في الإصدارات الأقدم من 1.7.6.
يدعم InfluxDB المصادقة باستخدام رموز الويب JSON (JWT) لطلبات واجهة برمجة التطبيقات HTTP. عند استلام طلب يحمل الترويسة:
Authorization: Bearer <token>
سينفذ InfluxDB الخطوات التالية:
shared-secret من ملف influxdb.conf لتكون بمثابة المفتاح السري للتحقق من توقيع الرمز.username من المطالبات (claims) لتحديد المستخدم الذي ينفذ الاستعلام.في الإصدارات المتأثرة، إذا تم تفعيل مصادقة JWT ولكن لم يتم تكوين معامل shared-secret، فقد تتم معالجة القيمة السرية كسلسلة فارغة ("").
يفشل النظام في التحقق بشكل كافٍ من قوة السر الأمنية قبل التحقق من توقيع JWT. وهذا يسمح للمهاجم بإنشاء JWT مخصص، وتوقيعه بسريّة فارغة، ثم تعيين مطالبة username على حساب صالح في النظام، مثل admin إذا كان هذا الحساب موجودًا في المختبر.
عند إرسال هذا الرمز عبر ترويسة Authorization: Bearer <token>، يستخدم InfluxDB نفس السر الفارغ للتحقق من التوقيع. إذا تطابق التوقيع وكان اسم المستخدم موجودًا، فسيتم تفويض الطلب دون الحاجة إلى كلمة مرور المستخدم الفعلية.
يمكن تلخيص تدفق المعالجة على النحو التالي:
| الخطوة | المعالجة العادية | الخلل في CVE-2019-20933 |
|---|---|---|
| 1 | يرسل العميل Authorization: Bearer <token> | المهاجم ينشئ JWT بنفسه |
| 2 | يقرأ الخادم shared-secret من الإعدادات | shared-secret غير معيّن |
| 3 | يستخدم الخادم السر للتحقق من توقيع JWT | تتم معالجة السر كسلسلة فارغة "" |
| 4 | إذا كان الرمز صالحًا، استرجاع username من المطالبة | المهاجم يعيّن username=admin إذا كان المستخدم موجودًا |
| 5 | يمنح الخادم الصلاحيات بناءً على مستخدم المطالبة | يتم قبول الطلب دون الحاجة إلى كلمة مرور |
تدفق الاستغلال على المستوى المنطقي:
InfluxDB < 1.7.6
→ authentication enabled
→ empty shared-secret
→ attacker creates JWT signed with secret ""
→ sends token via Authorization: Bearer
→ server accepts the token
→ query to /query succeeds
بعد فهم آلية الثغرة CVE، من الضروري ربطها بالهدف لتجنب استخلاص الاستنتاجات بناءً على الإصدار فقط.
| الشرط | نتيجة الهدف | التقييم |
|---|---|---|
| الخدمة هي InfluxDB | يحدد Nmap الخدمة على أنها InfluxDB http admin 1.6.6 | متوفر |
| الإصدار ضمن النطاق المتأثر | 1.6.6 < 1.7.6 | متوفر |
| المصادقة مفعّلة | /query يعيد 401 Unauthorized | متوفر |
| هل يتم قبول JWT الموقّع بسريّة مشتركة فارغة؟ | يحتاج إلى تحقق | غير مؤكد |
| هل اسم المستخدم في JWT صالح؟ | يحتاج إلى تحقق/مفترض في المختبر | غير مؤكد |
في هذه اللحظة، تم تحديد CVE-2019-20933 كمرشح مناسب للغاية للهدف. ومع ذلك، لتأكيد الاستغلال العملي، يجب علينا توليد JWT موقّع بسريّة مشتركة فارغة shared secret وإرساله إلى نقطة نهاية /query.
إذا قبل الخادم هذا الرمز وسمح بتنفيذ الاستعلام، عندها فقط يمكننا أن نستنتج أن الثغرة CVE تم استغلالها بنجاح.