Reports
MEDIA[SSRF]#3383079

SSRF en Rocket.Chat: las vistas previas oEmbed seguían redirecciones hacia la red interna sin validarlas

Rocket.Chat 7.10.1 filtraba las IP internas en la URL publicada, pero no en el destino de sus redirecciones. Con un enlace acortado, el servidor pedía recursos internos y mostraba parte de la respuesta en la vista previa.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Rocket.Chat genera automáticamente una vista previa (función oEmbed, activa por defecto) cada vez que alguien publica una URL válida en un canal o en un mensaje directo. Para hacerlo, el propio servidor descarga la página y, si recibe una redirección, la sigue hasta el destino final.

En la versión 7.10.1 el servidor sí comprobaba la URL publicada: si apuntaba a una dirección local o interna, no la descargaba. El fallo estaba en que esa comprobación solo se hacía sobre la primera URL. Los destinos de las redirecciones no pasaban por el mismo filtro, así que bastaba con una URL externa "limpia" que redirigiera a una dirección interna para saltarse la protección. Es una falsificación de peticiones del lado del servidor (SSRF).

Pasos de reproducción

El investigador montó un entorno de prueba con un servidor httpbin en la misma red local que Rocket.Chat, en 192.168.100.9:8080. El atacante no puede llegar a esa máquina directamente.

  1. Publicar en un canal http://example.com. Es una URL pública y válida, así que aparece la vista previa con normalidad.
  2. Publicar directamente la dirección interna:

`` http://192.168.100.9:8080 ``

La protección contra SSRF funciona y no se genera vista previa.

  1. Crear con un acortador (en la prueba, https://tinyurl.com/) un enlace que redirija a http://192.168.100.9:8080. En la prueba quedó así:

`` https://tinyurl.com/bdhdhmrn ``

  1. Publicar ese enlace acortado en cualquier canal o mensaje directo.
  2. El servidor de Rocket.Chat valida la URL de tinyurl (externa, así que la acepta), sigue la redirección sin volver a comprobar el destino y hace una petición GET a http://192.168.100.9:8080. La vista previa del mensaje muestra parte del contenido de la página interna de httpbin.

El investigador grabó estas tres pruebas en un vídeo de prueba de concepto adjunto al reporte.

Impacto

  • Cualquier usuario que pueda escribir en un canal o mandar un mensaje directo consigue que el servidor haga peticiones a máquinas de la red interna a las que él no tiene acceso.
  • No es una SSRF "ciega": la vista previa devuelve al atacante fragmentos de la respuesta de esos servicios internos, lo que permite filtrar información.
  • Repitiendo la técnica con distintas IP y puertos se puede explorar la red interna.
  • Según el investigador, en despliegues en la nube la misma técnica podría alcanzar servicios de metadatos como el IMDS de AWS y exponer datos sensibles o credenciales.

El reporte tiene severidad media.

Remediación

El investigador recomienda aplicar las mismas comprobaciones (direcciones locales e internas, etc.) no solo a la URL publicada, sino también a cada URL de destino de las redirecciones que siga la función oEmbed. El reporte figura como resuelto, aunque no detalla qué cambio aplicó Rocket.Chat ni en qué versión se corrigió.