Vulnerabilidad crítica en Ruby on Rails (CVSS 9.8): atacantes pueden escribir archivos en servidores mediante imágenes manipuladas
Una vulnerabilidad crítica en Ruby on Rails (CVSS 9.8) permite escribir archivos en servidores mediante cargas manipuladas procesadas por ImageMagick. Conoce los sistemas afectados y cómo protegerte.
Una vulnerabilidad crítica en Ruby on Rails permite a atacantes remotos y sin autenticación escribir archivos arbitrarios en el servidor mediante la carga de imágenes especialmente diseñadas. El fallo afecta a Active Storage cuando utiliza ImageMagick para procesar archivos, y podría facilitar el robo de credenciales, el acceso a información sensible e incluso la ejecución remota de código.
La seguridad de las aplicaciones web desarrolladas con Ruby on Rails vuelve a estar bajo presión. El proyecto ha publicado una alerta de seguridad relacionada con una vulnerabilidad crítica en Active Storage, el componente encargado de gestionar los archivos adjuntos y las cargas de ficheros.
El fallo, identificado como GHSA-f3w6-w445-fwh9, tiene una puntuación de 9.8 sobre 10 en CVSS, lo que refleja su elevada criticidad.
El problema reside en la interacción entre Active Storage e ImageMagick. Bajo determinadas configuraciones, un atacante puede aprovechar la carga de una imagen manipulada para conseguir que el servidor escriba archivos fuera de las ubicaciones previstas.
El riesgo no termina en la modificación de archivos. En aplicaciones que utilizan el servicio de almacenamiento Disk de Active Storage, también podría producirse la lectura de archivos accesibles para el proceso de la aplicación, incluyendo secretos y credenciales.
¿En qué consiste la vulnerabilidad de Ruby on Rails?
Active Storage es el componente de Ruby on Rails utilizado para gestionar archivos adjuntos, imágenes, documentos y otros contenidos enviados por los usuarios.
Entre sus funcionalidades se encuentra el análisis de archivos y la generación de variantes de imágenes, operaciones que pueden apoyarse en herramientas externas como ImageMagick.
La vulnerabilidad aparece cuando Active Storage procesa una carga utilizando ImageMagick sin restringir adecuadamente los formatos o coders que pueden intervenir durante el procesamiento.
ImageMagick utiliza diferentes módulos, conocidos como coders, para interpretar los formatos de archivo. Algunos de ellos pueden ejecutar operaciones adicionales sobre archivos externos, leer contenido del sistema o escribir información en ubicaciones determinadas.
Uno de estos módulos es MSL (Magick Scripting Language), que permite ejecutar instrucciones para manipular imágenes y trabajar con archivos.
El problema es que un atacante puede preparar un archivo SVG especialmente diseñado para alcanzar el MSL coder durante el análisis automático de una carga.
Esto permite convertir una operación aparentemente inocua —subir una imagen— en una vía para ejecutar operaciones no autorizadas sobre el sistema de archivos.
No es necesario generar una miniatura para activar el problema
Uno de los aspectos más importantes de esta vulnerabilidad es que no requiere necesariamente que la aplicación genere una variante de imagen, una vista previa o que invoque manualmente el proceso de análisis.
El procesamiento puede producirse automáticamente cuando el archivo se adjunta mediante Active Storage.
Por tanto, una aplicación que permita cargar archivos a usuarios externos puede estar expuesta incluso cuando aparentemente no utiliza funcionalidades avanzadas de procesamiento de imágenes.
Identificación y clasificación de la vulnerabilidad
| Característica | Detalle |
|---|---|
| Producto afectado | Ruby on Rails |
| Componente | Active Storage |
| Identificador | GHSA-f3w6-w445-fwh9 |
| CVE | Sin identificador CVE asignado en el aviso consultado |
| Severidad | Crítica |
| Puntuación CVSS | 9.8 |
| Vector de ataque | Remoto |
| Autenticación | No requerida |
| Condición principal | Active Storage con ImageMagick |
| Técnica | Manipulación de archivos y coders de ImageMagick |
| Impacto | Escritura arbitraria de archivos y posible lectura de información sensible |
¿Qué versiones de Ruby on Rails están afectadas?
Según el aviso de seguridad del proyecto Rails, las versiones vulnerables incluyen:
- Todas las versiones de Active Storage anteriores a 8.0.5.2.
- Versiones de la rama 8.1 anteriores a 8.1.4.1.
- Las ramas anteriores a 8.0 que ya no reciben mantenimiento también pueden estar afectadas y no disponen de una actualización de seguridad específica dentro de sus ramas originales.
Las versiones corregidas son:
- Ruby on Rails 8.0.5.2
- Ruby on Rails 8.1.4.1
Se recomienda actualizar a la versión corregida correspondiente o a una versión posterior que incorpore las mismas correcciones.
Es importante recordar que actualizar únicamente el componente de aplicación no siempre es suficiente: también deben revisarse las dependencias y la configuración de ImageMagick.
¿Qué condiciones deben cumplirse para que una aplicación sea vulnerable?
No todas las instalaciones de Ruby on Rails están expuestas. Para que una aplicación se encuentre dentro del escenario vulnerable descrito por el aviso, deben coincidir tres condiciones:
1. Utilizar ImageMagick para procesar imágenes en Active Storage
La configuración relevante es:
config.active_storage.variant_processor = :mini_magickEn aplicaciones que utilizan load_defaults anterior a Rails 7.0, :mini_magick es el valor predeterminado.
En versiones configuradas con load_defaults 7.0 o posterior, el valor predeterminado es :vips.
La configuración debe comprobarse expresamente, ya que determina también qué biblioteca se utiliza para analizar las cargas.
2. La política de seguridad de ImageMagick no bloquea los coders peligrosos
La exposición depende de las restricciones aplicadas a ImageMagick.
Las políticas distribuidas por Debian y Ubuntu no bloquean necesariamente los coders implicados en este escenario.
3. Permitir cargas de archivos procedentes de usuarios no confiables
Las aplicaciones que permiten subir imágenes, documentos o archivos desde formularios públicos, áreas de clientes o plataformas colaborativas deben revisar especialmente este punto.
Impacto: ¿qué puede conseguir un atacante?
La gravedad de esta vulnerabilidad no se limita a la manipulación de imágenes.
Dependiendo de la configuración y los permisos del proceso que ejecuta Rails, las consecuencias pueden ser importantes.
1. Escritura arbitraria de archivos
Un atacante podría conseguir que ImageMagick escriba archivos en ubicaciones del servidor que no deberían estar controladas por un usuario externo.
Esto puede comprometer la integridad de la aplicación y facilitar otras etapas de un ataque.
2. Lectura de archivos sensibles
En aplicaciones que utilizan el servicio Disk de Active Storage, el aviso también contempla la posibilidad de leer archivos a los que tenga acceso el proceso de Rails.
Entre los datos que podrían quedar expuestos se encuentran:
secret_key_base.- Claves maestras de Rails.
- Credenciales almacenadas en
config/credentials.yml.enc. - Credenciales de bases de datos.
- Tokens de servicios externos.
- Credenciales de almacenamiento.
- Información de configuración interna.
3. Posible ejecución remota de código (RCE)
La exposición de archivos sensibles puede facilitar ataques posteriores.
Por ejemplo, si un atacante consigue acceder a secretos utilizados por Rails, podría aprovecharlos para intentar falsificar sesiones, comprometer la aplicación o alcanzar otros componentes de la infraestructura.
Por tanto, la lectura de archivos no debe tratarse como un impacto menor: puede convertirse en el punto de partida de una intrusión más amplia.
4. Movimiento lateral
Si las credenciales obtenidas permiten acceder a otros servicios, el incidente podría extenderse a:
- Bases de datos.
- Servicios cloud.
- Sistemas de almacenamiento.
- APIs corporativas.
- Infraestructura interna.
- Sistemas de gestión y despliegue.
La exposición de una aplicación web podría terminar convirtiéndose en un incidente de seguridad que afecte a varios sistemas de la organización.
Una segunda vulnerabilidad también corregida: GHSA-v924-7rp8-4mxh
Las mismas versiones de mantenimiento corrigen otra vulnerabilidad de Active Storage, identificada como GHSA-v924-7rp8-4mxh, con una puntuación CVSS de 8.8.
Este segundo problema está relacionado con el tratamiento de archivos temporales enviados a herramientas como ImageMagick y FFmpeg.
Active Storage utilizaba nombres temporales que conservaban la extensión original del archivo.
Esto resulta relevante porque algunas herramientas pueden seleccionar el decodificador que utilizarán basándose en la extensión cuando el contenido del archivo no permite determinar correctamente el formato.
Un atacante podría aprovechar la posibilidad de controlar el nombre y el tipo de contenido declarado para influir en el decodificador utilizado durante el procesamiento.
Por ello, las organizaciones deben abordar ambas vulnerabilidades al actualizar sus aplicaciones.
Medidas de mitigación y remediación
La prioridad debe ser actualizar Ruby on Rails. Sin embargo, también es necesario revisar la configuración de ImageMagick, los permisos del sistema y la posible exposición de secretos.
1. Actualizar Ruby on Rails
La medida principal es instalar una versión corregida:
bundle update railsComprobar posteriormente la versión instalada:
bundle exec rails --versionVerificar también las dependencias:
bundle outdatedEl objetivo es utilizar Rails 8.0.5.2 o 8.1.4.1 como mínimo, según la rama correspondiente.
En aplicaciones que utilizan MiniMagick, también es necesario disponer de mini_magick 5.1 o posterior.
Actualizar primero en un entorno de pruebas, ejecutar los tests y comprobar que el procesamiento de archivos continúa funcionando correctamente.
2. Revisar la configuración de Active Storage
Buscar la configuración del procesador de imágenes:
grep -R "variant_processor" config/Revisar especialmente:
config.active_storage.variant_processorSi se utiliza :mini_magick, debe comprobarse que la política de seguridad de ImageMagick está correctamente aplicada.
Cambiar a :vips no debe considerarse una solución automática sin analizar previamente las dependencias, la configuración y el comportamiento de la aplicación.
3. Aplicar una política de seguridad en ImageMagick
Las versiones corregidas de Rails incorporan una política específica para ImageMagick.
Esta política restringe operaciones peligrosas, entre ellas:
- El coder MSL.
- Coders capaces de leer o eliminar archivos externos a la imagen.
- Coders que permiten acceder a referencias locales o remotas.
- Coders respaldados por Ghostscript.
- El delegado
gs. - El mecanismo de indirección
@filename.
En instalaciones que no puedan actualizarse inmediatamente, puede utilizarse como referencia el archivo:
activestorage/lib/active_storage/image_magick/policy.xmlDebe incorporarse la política en la configuración de ImageMagick del servidor, por ejemplo:
/etc/ImageMagick-7/policy.xmlLa ubicación puede variar según la distribución y versión instalada.
Importante: la política del sistema y las reglas adicionales de Rails deben revisarse conjuntamente. Una regla permisiva, especialmente un comodín como pattern="*", puede permitir operaciones que se pretendían bloquear.
4. Verificar que ImageMagick está aplicando la política
En aplicaciones que utilizan MiniMagick, ejecutar:
bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'El resultado permite comprobar qué política está utilizando ImageMagick.
También es necesario revisar si la aplicación modifica el entorno de ejecución de MiniMagick mediante MiniMagick.cli_env, MiniMagick.cli_prefix o una implementación personalizada de MiniMagick::Shell.
Estas modificaciones pueden impedir que la política distribuida con Rails se aplique como se espera.
5. Restringir las cargas de archivos
Como medida adicional de defensa en profundidad:
- Limitar los formatos admitidos.
- Validar el contenido real de los archivos y no solamente su extensión.
- Establecer límites de tamaño.
- Restringir el acceso a los endpoints de carga.
- Aplicar controles de autenticación y autorización.
- Procesar archivos en entornos aislados.
- Evitar que el usuario que ejecuta Rails tenga permisos de escritura innecesarios.
- Almacenar los archivos fuera de directorios ejecutables o sensibles.
Estas medidas reducen la superficie de ataque, pero no sustituyen la actualización de seguridad.
6. Revisar GraphicsMagick
Es importante tener en cuenta que la política distribuida con Rails está diseñada para ImageMagick.
GraphicsMagick no utiliza las políticas de seguridad de ImageMagick, por lo que no recibe automáticamente esta protección.
Las organizaciones que utilizan GraphicsMagick deben aplicar controles específicos para esa herramienta y evaluar el riesgo de su configuración.
7. Revisar y rotar credenciales si existe exposición
Si la aplicación utiliza Active Storage Disk y existe sospecha de explotación, no basta con actualizar Rails.
Es necesario rotar los secretos que el proceso de la aplicación pudiera haber leído:
secret_key_base.- Master key de Rails.
- Credenciales de bases de datos.
- Tokens de APIs.
- Credenciales de servicios cloud.
- Claves de almacenamiento.
- Credenciales de terceros.
Las credenciales comprometidas deben revocarse y sustituirse. No deben conservarse como mecanismo de compatibilidad o recuperación.
Recomendaciones de seguridad para AWS y entornos cloud
En infraestructuras alojadas en AWS, es recomendable aplicar varias capas de protección.
AWS WAF: protección de los endpoints de carga
AWS WAF puede utilizarse para proteger los endpoints que reciben archivos.
Se recomienda:
- Aplicar reglas de limitación de solicitudes (rate-based rules).
- Restringir los métodos HTTP a los estrictamente necesarios.
- Aplicar controles sobre rutas de carga de archivos.
- Bloquear patrones de solicitudes anómalas.
- Utilizar reglas administradas de AWS WAF como capa adicional de protección.
- Registrar las solicitudes bloqueadas y permitidas para facilitar la investigación.
Ejemplo conceptual de una regla de protección:
Endpoint: /rails/active_storage/direct_uploads
Controles:
- Métodos HTTP permitidos.
- Rate limiting por IP.
- Límites de tamaño en la aplicación.
- Inspección de solicitudes.
- Registro de eventos.Limitación importante: AWS WAF no sustituye la validación del contenido de una imagen ni puede garantizar que un SVG o archivo manipulado no alcance un coder peligroso de ImageMagick. La corrección debe realizarse en Rails y en la política de procesamiento.
AWS S3: aislamiento del almacenamiento
Cuando sea posible, es recomendable utilizar almacenamiento externo para los archivos de Active Storage.
Buenas prácticas:
- Mantener los buckets privados.
- Aplicar S3 Block Public Access.
- Utilizar políticas IAM con privilegios mínimos.
- Separar los buckets de entrada y procesamiento.
- Evitar permisos de escritura innecesarios.
- Habilitar registros de acceso cuando corresponda.
- Utilizar cifrado en reposo.
- Configurar políticas de retención y eliminación.
Separar el almacenamiento de archivos del servidor de aplicaciones ayuda a reducir el impacto de una intrusión, aunque no elimina por sí mismo la vulnerabilidad de procesamiento.
AWS EC2 y contenedores: limitar privilegios
Para aplicaciones Rails desplegadas en EC2, ECS o Kubernetes:
- Ejecutar Rails con un usuario sin privilegios administrativos.
- Evitar ejecutar procesos de procesamiento de imágenes como root.
- Utilizar contenedores con permisos mínimos.
- Aplicar sistemas de archivos de solo lectura cuando sea viable.
- Separar los procesos de carga y procesamiento.
- Restringir las comunicaciones de salida.
- Evitar almacenar secretos directamente en imágenes de contenedor.
- Gestionar credenciales mediante AWS Secrets Manager o servicios equivalentes.
Monitorización y detección
Se recomienda integrar los registros de aplicación, sistema operativo y servicios cloud en una plataforma SIEM.
Buscar comportamientos como:
- Escrituras inesperadas en directorios de la aplicación.
- Modificaciones de archivos de configuración.
- Accesos anómalos a archivos de credenciales.
- Procesos ImageMagick con actividad inusual.
- Conexiones salientes inesperadas.
- Solicitudes repetitivas a endpoints de carga.
- Cambios no autorizados en archivos de configuración.
Una detección temprana puede reducir considerablemente el impacto de un incidente.
¿Cómo comprobar si una aplicación ha podido estar comprometida?
La publicación del parche no implica que las aplicaciones vulnerables hayan sido atacadas, pero las organizaciones deben investigar cualquier posible exposición.
Se recomienda:
- Identificar todas las aplicaciones Ruby on Rails desplegadas.
- Comprobar la configuración de Active Storage.
- Identificar las aplicaciones que utilizan MiniMagick.
- Revisar los registros de carga de archivos.
- Analizar modificaciones inesperadas en el sistema de archivos.
- Comprobar el acceso a archivos sensibles.
- Revisar las conexiones salientes de los servidores.
- Auditar el uso de credenciales y tokens.
- Rotar secretos si existe sospecha razonable de exposición.
- Documentar las acciones realizadas y conservar evidencias.
El aviso de seguridad no proporciona un procedimiento definitivo para determinar si una aplicación ya ha sido atacada. Por tanto, la investigación debe basarse en los registros disponibles y en un análisis forense del entorno.
Una carga de imagen puede convertirse en una puerta de entrada al servidor
La vulnerabilidad GHSA-f3w6-w445-fwh9 demuestra que los mecanismos aparentemente rutinarios de procesamiento de archivos pueden convertirse en un vector de ataque crítico.
El riesgo es especialmente relevante para aplicaciones Ruby on Rails que permiten cargas de archivos procedentes de usuarios externos y utilizan ImageMagick mediante Active Storage.
Con una puntuación CVSS de 9.8, la actualización debe tratarse como una prioridad de seguridad.
Las organizaciones deben actualizar Rails, revisar las políticas de ImageMagick, comprobar las dependencias de MiniMagick y evaluar la posible exposición de credenciales.
Además, es fundamental aplicar una estrategia de defensa en profundidad que combine controles de aplicación, infraestructura, almacenamiento, monitorización y gestión de secretos.
La recomendación es clara: no confiar únicamente en la validación de extensiones ni en las protecciones perimetrales. El procesamiento de archivos debe considerarse una superficie de ataque y protegerse con el mismo rigor que cualquier otro componente crítico de una aplicación web.
Fuentes y referencias técnicas
- Ruby on Rails – GHSA-f3w6-w445-fwh9 (vulnerabilidad crítica)
- Ruby on Rails – GHSA-v924-7rp8-4mxh (segunda vulnerabilidad)
- Rails – Commit de corrección para la rama 8.1
- Rails – Commit de corrección para la rama 8.0
- Rails – Guía oficial de Active Storage
- Rails – Política de mantenimiento
- The Hacker News – Noticia original