SSRF aveugle via SiteContentDetector authentifié dans Matomo

Rapporteur

Nom : CYBER-SEC
Contact : [email protected]

Résumé

Matomo permet à un administrateur de site authentifié de configurer le main_url d'un site avec une adresse interne. Tout utilisateur authentifié disposant d'un accès en lecture peut ensuite déclencher getTrackingMethodsForSite, ce qui amène le serveur à effectuer une requête HTTP aveugle vers l'URL configurée.

La destination n'est validée qu'avec des protections basées sur le nom d'hôte et ne rejette pas correctement les adresses de bouclage, RFC1918 ou link-local après résolution. Par conséquent, l'application peut être abusée pour effectuer des requêtes serveur aveugles vers des services internes.

Produit concerné

Produit : Matomo
Version concernée : 5.11.2 vérifiée
Composant : SiteContentDetector / SitesManager

CWE

CWE-918 : Server-Side Request Forgery (SSRF)

CVSS v3.1

Vecteur : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Score de base : 5,8 Moyen

Conditions d'attaque

enable_internet_features doit être activé.
Un administrateur de site authentifié est requis pour définir le main_url du site.
Un utilisateur authentifié disposant d'une permission de lecture peut déclencher la requête côté serveur.
L'attaquant doit pouvoir observer la requête aveugle via un écouteur contrôlé ou un canal secondaire.

Détails techniques

Le problème implique le flux suivant :

Source :
SitesManager.updateSite stocke main_url après une validation URL de base.

Déclencheur :
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>

Puits :
SiteContentDetector::requestSiteResponse()
  -> Http::sendHttpRequestBy()

L'implémentation ne rejette pas correctement les destinations internes telles que :

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

Les cibles de redirection doivent également être revalidées, car le filtrage basé sur le nom d'hôte peut être contourné si le nom d'hôte initial autorisé redirige vers une adresse interne.

Preuve de concept

1. Démarrer un écouteur interne contrôlé

Utilisez un écouteur que vous contrôlez dans un environnement de laboratoire autorisé :

python3 -m http.server 8088

2. Configurer l'URL du site Matomo

En tant qu'administrateur de site authentifié, configurez le main_url du site pour qu'il pointe vers l'écouteur interne contrôlé :

http://<écouteur-interne-contrôlé>:8088/ssrf-test

Ne testez pas contre des systèmes tiers ou des points de terminaison de métadonnées cloud, sauf si vous possédez cet environnement et êtes autorisé à le tester.

3. Déclencher SiteContentDetector

En tant qu'utilisateur authentifié disposant d'une permission de lecture, déclenchez :

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

4. Observer la requête aveugle

L'écouteur contrôlé reçoit une requête HTTP côté serveur provenant du serveur Matomo.

Exemple de sortie de l'écouteur :

GET /ssrf-test HTTP/1.1
Host: <écouteur-interne-contrôlé>:8088
User-Agent: Matomo

Comportement observé

Matomo effectue une requête GET côté serveur vers le main_url configuré lorsque getTrackingMethodsForSite est déclenché.

Cela a été vérifié à l'aide d'un écouteur HTTP interne de bouclage/interne non accessible depuis l'extérieur, confirmant le comportement de SSRF aveugle.

Impact

Un attaquant authentifié peut abuser de ce comportement pour :

Un accès aveugle aux services internes.
La reconnaissance du réseau interne.
L'interaction avec des services liés à des interfaces de bouclage ou privées.
Des requêtes vers des services de métadonnées cloud dans les déploiements concernés.
Des contournements basés sur les redirections des protections limitées au nom d'hôte.

Étant donné que la SSRF est aveugle, l'attaquant ne reçoit pas directement le corps de la réponse HTTP via Matomo. Cependant, la simple livraison de la requête peut déjà être pertinente en matière de sécurité dans les réseaux internes et les environnements cloud.

Remédiation

Correctifs recommandés :

Résoudre le nom d'hôte en adresses IP avant d'effectuer la requête.
Rejeter les plages IP privées, de bouclage, link-local, multicast et autres plages non sûres après la résolution DNS.
Revalider chaque cible de redirection avant de suivre les redirections.
Privilégier une liste blanche stricte de domaines sortants autorisés plutôt que des listes noires de noms d'hôtes.
Appliquer les protections SSRF de manière cohérente au niveau du puits final de requête HTTP, et pas uniquement lors de la configuration de l'URL du site.
Envisager de restreindre getTrackingMethodsForSite ou le déclencheur SiteContentDetector aux utilisateurs disposant de privilèges plus élevés.
Ajouter une journalisation d'audit pour les requêtes serveur sortantes déclenchées par la configuration du site.

Découverte

Vérifié contre l'image Docker officielle Matomo 5.11.2 sans modifier le code source.

Divulgation

Ce problème a été signalé par CYBER-SEC.

CVE-2026-78850

Populaires