Matomo SiteContentDetector المُصادق عليه - SSRF أعمى

المُبلِّغ

الاسم: CYBER-SEC
جهة الاتصال: [email protected]

الملخص

يتيح Matomo لمسؤول الموقع المُصادق عليه ضبط main_url للموقع بعنوان داخلي. يمكن لأي مستخدم مُصادق عليه يملك صلاحية العرض لاحقًا تشغيل getTrackingMethodsForSite، مما يجعل الخادم ينفذ طلب HTTP أعمى إلى العنوان المُهيأ.

لا يتم التحقق من الوجهة إلا عبر حمايات قائمة على اسم المضيف، ولا يتم رفض عناوين loopback أو RFC1918 أو link-local بشكل صحيح بعد التحليل. ونتيجة لذلك، يمكن إساءة استخدام التطبيق لتنفيذ طلبات خادم أعمى إلى الخدمات الداخلية.

المنتج المتأثر

المنتج: Matomo
الإصدار المتأثر: 5.11.2 تم التحقق منه
المكوّن: SiteContentDetector / SitesManager

CWE

• CWE-918: تزوير طلب من جانب الخادم (SSRF)

CVSS v3.1

المتجه: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
النتيجة الأساسية: 5.8 متوسط

متطلبات الهجوم

• يجب تفعيل enable_internet_features.
• يلزم مسؤول موقع مُصادق عليه لضبط main_url للموقع.
• يمكن لمستخدم مُصادق عليه يملك صلاحية العرض تشغيل الطلب من جانب الخادم.
• يجب أن يكون المهاجم قادرًا على ملاحظة الطلب الأعمى عبر مستمع مُتحكم به أو قناة جانبية.

التفاصيل التقنية

تتعلق المشكلة بالتدفق التالي:

المصدر:
SitesManager.updateSite يخزن main_url بعد التحقق الأساسي من عنوان URL.

المُشغِّل:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>

المصب:
SiteContentDetector::requestSiteResponse()
  -> Http::sendHttpRequestBy()

لا يرفض التنفيذ الوجهات الداخلية بشكل صحيح مثل:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
::1
fc00::/7
fe80::/10

يجب أيضًا إعادة التحقق من أهداف إعادة التوجيه، لأن التصفية القائمة على اسم المضيف يمكن تجاوزها إذا أعاد اسم المضيف المسموح به التوجيه إلى عنوان داخلي.

إثبات المفهوم

1. تشغيل مستمع داخلي مُتحكم به

استخدم مستمعًا تتحكم فيه في بيئة مختبرية مصرح بها:

python3 -m http.server 8088

2. ضبط عنوان URL لموقع Matomo

بصفتك مسؤول موقع مُصادق عليه، اضبط main_url للموقع ليشير إلى المستمع الداخلي المُتحكم به:

http://<controlled-internal-listener>:8088/ssrf-test

لا تختبر ضد أنظمة طرف ثالث أو نقاط نهاية بيانات تعريف السحابة إلا إذا كنت تملك تلك البيئة ومصرحًا لك باختبارها.

3. تشغيل SiteContentDetector

بصفتك مستخدمًا مُصادقًا عليه يملك صلاحية العرض، شغّل:

GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1

4. ملاحظة الطلب الأعمى

يتلقى المستمع المُتحكم به طلب HTTP من جانب الخادم من خادم Matomo.

مثال على مخرجات المستمع:

GET /ssrf-test HTTP/1.1
Host: <controlled-internal-listener>:8088
User-Agent: Matomo

السلوك الملاحَظ

ينفذ Matomo طلب GET من جانب الخادم إلى main_url المُهيأ عند تشغيل getTrackingMethodsForSite.

تم التحقق من ذلك باستخدام مستمع HTTP داخلي/loopback لم يكن قابلاً للوصول خارجيًا، مما يؤكد سلوك SSRF الأعمى.

التأثير

يمكن للمهاجم المُصادق عليه إساءة استخدام هذا السلوك من أجل:

• الوصول الأعمى إلى الخدمات الداخلية.
• استطلاع الشبكة الداخلية.
• التفاعل مع الخدمات المرتبطة بواجهات loopback أو خاصة.
• طلبات إلى خدمات بيانات تعريف السحابة في النشرات المتأثرة.
• تجاوزات قائمة على إعادة التوجيه للحمايات القائمة على اسم المضيف فقط.

نظرًا لأن SSRF أعمى، لا يتلقى المهاجم نص استجابة HTTP مباشرة عبر Matomo. ومع ذلك، فإن تسليم الطلب وحده قد يكون ذا صلة أمنية في الشبكات الداخلية وبيئات السحابة.

المعالجة

الإصلاحات الموصى بها:

1. تحليل اسم المضيف إلى عناوين IP قبل إجراء الطلب.

2. رفض نطاقات IP الخاصة وloopback وlink-local والبث المتعدد وغير الآمنة بعد تحليل DNS.

3. إعادة التحقق من كل هدف إعادة توجيه قبل متابعة عمليات إعادة التوجيه.

4. تفضيل قائمة سماح صارمة للنطاقات الصادرة المسموح بها بدلاً من قوائم حظر أسماء المضيفين.

5. تطبيق حمايات SSRF بشكل متسق عند المصب النهائي لطلب HTTP، وليس فقط أثناء ضبط عنوان URL للموقع.

6. النظر في تقييد getTrackingMethodsForSite أو مشغِّل SiteContentDetector للمستخدمين ذوي الصلاحيات الأعلى.

7. إضافة تسجيل تدقيق للطلبات الصادرة من جانب الخادم التي تُشغَّل بواسطة ضبط الموقع.

الاكتشاف

تم التحقق منه ضد صورة Docker الرسمية لـ Matomo 5.11.2 دون تعديل الكود المصدري.

الإفصاح

تم الإبلاغ عن هذه المشكلة بواسطة CYBER-SEC.

المراجع

• https://github.com/matomo-org/matomo
• https://matomo.org/
• https://cwe.mitre.org/data/definitions/918.html