
Prueba de concepto que demuestra un SSRF ciego autenticado en SiteContentDetector de Matomo, que permite el reconocimiento de la red interna y el envío de solicitudes a servicios internos mediante URLs de sitio manipuladas.
Nombre: CYBER-SEC
Contacto: [email protected]
Matomo permite que un administrador de sitio autenticado configure el main_url de un sitio con una dirección interna. Cualquier usuario autenticado con acceso de vista puede activar posteriormente getTrackingMethodsForSite, lo que provoca que el servidor realice una solicitud HTTP ciega a la URL configurada.
El destino solo se valida con protecciones basadas en nombres de host y no rechaza adecuadamente las direcciones loopback, RFC1918 o link-local después de la resolución. Como resultado, la aplicación puede ser explotada para realizar solicitudes ciegas del lado del servidor a servicios internos.
Producto: Matomo
Versión afectada: 5.11.2 verificada
Componente: SiteContentDetector / SitesManager
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Puntuación base: 5.8 Media
enable_internet_features debe estar habilitado.main_url del sitio.El problema involucra el siguiente flujo:
Fuente:
SitesManager.updateSite almacena main_url después de una validación básica de URL.
Activación:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>
Sumidero:
SiteContentDetector::requestSiteResponse()
-> Http::sendHttpRequestBy()
La implementación no rechaza adecuadamente destinos internos como:
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
Los destinos de redirección también deben ser revalidados, porque el filtrado basado en nombres de host puede ser evadido si el nombre de host permitido inicial redirige a una dirección interna.
Use un listener que usted controle en un entorno de laboratorio autorizado:
python3 -m http.server 8088
Como administrador de sitio autenticado, configure el main_url del sitio para que apunte al listener interno controlado:
http://<listener-interno-controlado>:8088/ssrf-test
No pruebe contra sistemas de terceros ni endpoints de metadatos en la nube a menos que usted sea el propietario y esté autorizado para probar ese entorno.
Como usuario autenticado con permiso de vista, active:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1
El listener controlado recibe una solicitud HTTP del lado del servidor desde el servidor de Matomo.
Ejemplo de salida del listener:
GET /ssrf-test HTTP/1.1
Host: <listener-interno-controlado>:8088
User-Agent: Matomo
Matomo realiza una solicitud GET del lado del servidor al main_url configurado cuando se activa getTrackingMethodsForSite.
Esto se verificó usando un listener HTTP interno de loopback que no era accesible externamente, confirmando el comportamiento de SSRF ciego.
Un atacante autenticado puede abusar de este comportamiento para:
Debido a que el SSRF es ciego, el atacante no recibe directamente el cuerpo de la respuesta HTTP a través de Matomo. Sin embargo, la entrega de la solicitud por sí sola puede ser relevante para la seguridad en redes internas y entornos de nube.
Correcciones recomendadas:
Resuelva el nombre de host a direcciones IP antes de realizar la solicitud.
Rechace rangos de IP privados, loopback, link-local, multicast y otros rangos inseguros después de la resolución DNS.
Revalide cada destino de redirección antes de seguir las redirecciones.
Prefiera una lista blanca estricta de dominios de salida permitidos en lugar de listas negras de nombres de host.
Aplique protecciones SSRF de manera consistente en el sumidero final de la solicitud HTTP, no solo durante la configuración de la URL del sitio.
Considere restringir getTrackingMethodsForSite o la activación de SiteContentDetector a usuarios con mayores privilegios.
Agregue registro de auditoría para solicitudes salientes del lado del servidor activadas por la configuración del sitio.
Verificado contra la imagen oficial de Docker de Matomo 5.11.2 sin modificar el código fuente.
Este problema fue reportado por CYBER-SEC.