Matomo Authenticated SiteContentDetector Blind SSRF

Reporter

Name: CYBER-SEC
Kontakt: [email protected]

Zusammenfassung

Matomo ermöglicht es einem authentifizierten Site-Administrator, die main_url einer Site mit einer internen Adresse zu konfigurieren. Jeder authentifizierte Benutzer mit Ansichtsberechtigung kann später getTrackingMethodsForSite auslösen, wodurch der Server eine blinde HTTP-Anfrage an die konfigurierte URL durchführt.

Das Ziel wird nur mit hostnamenbasierten Schutzmechanismen validiert und lehnt Loopback-, RFC1918- oder Link-Local-Adressen nach der Auflösung nicht ordnungsgemäß ab. Infolgedessen kann die Anwendung missbraucht werden, um blinde serverseitige Anfragen an interne Dienste durchzuführen.

Betroffenes Produkt

Produkt: Matomo
Betroffene Version: 5.11.2 verifiziert
Komponente: SiteContentDetector / SitesManager

CWE

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

CVSS v3.1

Vektor: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Basis-Score: 5.8 Mittel

Angriffsvoraussetzungen

enable_internet_features muss aktiviert sein.
Ein authentifizierter Site-Administrator ist erforderlich, um die main_url der Site festzulegen.
Ein authentifizierter Benutzer mit Ansichtsberechtigung kann die serverseitige Anfrage auslösen.
Der Angreifer muss in der Lage sein, die blinde Anfrage über einen kontrollierten Listener oder Seitenkanal zu beobachten.

Technische Details

Das Problem betrifft den folgenden Ablauf:

Quelle:
SitesManager.updateSite speichert main_url nach grundlegender URL-Validierung.

Auslöser:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>

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

Die Implementierung lehnt interne Ziele wie die folgenden nicht ordnungsgemäß ab:

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

Redirect-Ziele sollten ebenfalls erneut validiert werden, da die hostnamenbasierte Filterung umgangen werden kann, wenn der ursprünglich erlaubte Hostname auf eine interne Adresse weiterleitet.

Proof of Concept

1. Starten Sie einen kontrollierten internen Listener

Verwenden Sie einen Listener, den Sie in einer autorisierten Laborumgebung kontrollieren:

python3 -m http.server 8088

2. Konfigurieren Sie die Matomo-Site-URL

Konfigurieren Sie als authentifizierter Site-Administrator die main_url der Site so, dass sie auf den kontrollierten internen Listener zeigt:

http://<kontrollierter-interner-listener>:8088/ssrf-test

Testen Sie nicht gegen Systeme von Drittanbietern oder Cloud-Metadaten-Endpunkte, es sei denn, Sie besitzen diese Umgebung und sind autorisiert, sie zu testen.

3. SiteContentDetector auslösen

Lösen Sie als authentifizierter Benutzer mit Ansichtsberechtigung Folgendes aus:

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

4. Beobachten Sie die blinde Anfrage

Der kontrollierte Listener empfängt eine serverseitige HTTP-Anfrage vom Matomo-Server.

Beispiel für die Listener-Ausgabe:

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

Beobachtetes Verhalten

Matomo führt eine serverseitige GET-Anfrage an die konfigurierte main_url durch, wenn getTrackingMethodsForSite ausgelöst wird.

Dies wurde mit einem internen Loopback-/internen HTTP-Listener verifiziert, der extern nicht erreichbar war, was das Blind-SSRF-Verhalten bestätigt.

Auswirkungen

Ein authentifizierter Angreifer kann dieses Verhalten für Folgendes missbrauchen:

Blinder Zugriff auf interne Dienste.
Aufklärung des internen Netzwerks.
Interaktion mit Diensten, die an Loopback- oder private Schnittstellen gebunden sind.
Anfragen an Cloud-Metadaten-Dienste in betroffenen Bereitstellungen.
Redirect-basierte Umgehungen von rein hostnamenbasierten Schutzmechanismen.

Da die SSRF blind ist, erhält der Angreifer den HTTP-Antworttext nicht direkt über Matomo. Die bloße Zustellung der Anfrage kann jedoch in internen Netzwerken und Cloud-Umgebungen dennoch sicherheitsrelevant sein.

Behebung

Empfohlene Korrekturen:

Lösen Sie den Hostnamen vor der Anfrage in IP-Adressen auf.
Lehnen Sie private, Loopback-, Link-Local-, Multicast- und anderweitig unsichere IP-Bereiche nach der DNS-Auflösung ab.
Validieren Sie jedes Redirect-Ziel erneut, bevor Sie Redirects folgen.
Bevorzugen Sie eine strenge Allowlist erlaubter ausgehender Domains anstelle von Hostnamen-Blocklists.
Wenden Sie SSRF-Schutzmechanismen konsistent an der endgültigen HTTP-Anfrage-Senke an, nicht nur bei der Konfiguration der Site-URL.
Erwägen Sie, getTrackingMethodsForSite oder den SiteContentDetector-Auslöser auf Benutzer mit höheren Berechtigungen zu beschränken.
Fügen Sie Audit-Logging für ausgehende serverseitige Anfragen hinzu, die durch die Site-Konfiguration ausgelöst werden.

Entdeckung

Verifiziert gegen das offizielle Matomo-5.11.2-Docker-Image ohne Änderung des Quellcodes.

Offenlegung

Dieses Problem wurde von CYBER-SEC gemeldet.

CVE-2026-78850

Beliebteste