[28/03/2023] MLflow, un marco de código abierto utilizado por muchas organizaciones para gestionar sus pruebas de aprendizaje automático y registrar los resultados, recibió un parche para una vulnerabilidad crítica que podría permitir a los atacantes extraer información confidencial de los servidores, como claves SSH y credenciales de AWS. Los ataques se pueden ejecutar de forma remota sin autenticación porque MLflow no implementa la autenticación de forma predeterminada y un número creciente de implementaciones de MLflow están directamente expuestas a Internet.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
"Básicamente, cada organización que utiliza esta herramienta está en riesgo de perder sus modelos de IA, tener un servidor interno comprometido y tener su cuenta de AWS comprometida", sostuvo Dan McInerney, ingeniero de seguridad senior de la startup de ciberseguridad Protect AI, a CSO. "Es bastante brutal".
McInerney encontró la vulnerabilidad y la comunicó al proyecto MLflow en privado. Se corrigió en la versión 2.2.1 del framework que se publicó hace tres semanas, pero las notas de la versión no mencionan ninguna corrección de seguridad.
Inclusión de archivos locales y remotos mediante path traversal
MLflow está escrito en Python y está diseñado para automatizar flujos de trabajo de aprendizaje automático. Tiene múltiples componentes que permiten a los usuarios desplegar modelos de varias bibliotecas de ML; gestionar su ciclo de vida, incluyendo el versionado de modelos, transiciones de etapas y anotaciones; realizar un seguimiento de los experimentos para registrar y comparar parámetros y resultados; e incluso empaquetar código ML de forma reproducible para compartirlo con otros científicos de datos. MLflow puede controlarse mediante una API REST y una interfaz de línea de comandos.
Todas estas capacidades hacen del marco una herramienta valiosa para cualquier organización que experimente con el aprendizaje automático. Los análisis realizados con el motor de búsqueda Shodan refuerzan esta afirmación, ya que muestran un aumento constante de las instancias de MLflow expuestas públicamente en los últimos dos años, con un recuento actual de más de 800 instancias. Sin embargo, es seguro suponer que existen muchas más implementaciones de MLflow dentro de redes internas y que podrían ser accesibles para los atacantes que consigan acceder a esas redes.
Nos hemos puesto en contacto con varias empresas de Fortune 500 y todas nos han confirmado que utilizan MLflow internamente para su flujo de trabajo de ingeniería de IA", explicó McInerney.
La vulnerabilidad descubierta por McInerney se registra como CVE-2023-1177 y tiene una calificación de 10 (crítica) en la escala CVSS. La describe como inclusión de archivos local y remota (LFI/RFI) a través de la API, en la que un atacante remoto y no autenticado puede enviar solicitudes específicamente diseñadas al punto final de la API que obligarían a MLflow a exponer el contenido de cualquier archivo legible en el servidor.
Por ejemplo, el atacante puede incluir JSON como parte de la solicitud en la que modifica el parámetro de origen para que sea cualquier archivo que desee en el servidor y la aplicación lo devolverá. Uno de estos archivos puede ser las claves ssh, que normalmente se almacenan en el directorio .ssh dentro del directorio home del usuario local. Sin embargo, conocer de antemano el directorio personal del usuario no es un requisito previo para el exploit porque el atacante puede leer primero el archivo /etc/passwd, que está disponible en todos los sistemas Linux y que enumera todos los usuarios disponibles y sus directorios personales. Ninguno de los otros parámetros enviados como parte de la petición maliciosa necesita existir y pueden ser arbitrarios.
Lo que empeora la vulnerabilidad es que la mayoría de las organizaciones configuran sus instancias de MLflow para utilizar Amazon AWS S3 para almacenar sus modelos y otros datos confidenciales. Según la revisión de Protect AI de la configuración de las instancias de MLflow disponibles públicamente, siete de cada diez utilizaban AWS S3. Esto significa que los atacantes pueden configurar el parámetro de origen en su solicitud JSON para que sea la URL s3:// del bucket utilizado por la instancia para robar modelos de forma remota.
También significa que las credenciales de AWS probablemente se almacenan localmente en el servidor MLflow para que el framework pueda acceder a los buckets S3, y estas credenciales se almacenan normalmente en una carpeta llamada ~/.aws/credentials en el directorio de inicio del usuario. La exposición de las credenciales de AWS puede ser una infracción grave porque, dependiendo de la política de IAM, puede dar a los atacantes capacidades de movimiento lateral en la infraestructura de AWS de una organización.
La falta de autenticación por defecto conduce a implementaciones inseguras
Requerir autenticación para acceder al punto final de la API evitaría la explotación de esta falla, pero MLflow no implementa ningún mecanismo de autenticación. La autenticación básica con un nombre de usuario y contraseña estáticos se puede añadir desplegando un servidor proxy como nginx delante del servidor MLflow y forzando la autenticación a través de él. Desafortunadamente, casi ninguna de las instancias expuestas públicamente utiliza una configuración de este tipo.
"Difícilmente puedo llamar a esto un despliegue seguro de la herramienta, pero por lo menos, el despliegue más seguro de MLflow en su forma actual es mantenerlo en una red interna, en un segmento de red que se divide lejos de todos los usuarios, excepto aquellos que necesitan usarlo, y poner detrás de un proxy nginx con autenticación básica", señaló McInerney. "Esto no impide que cualquier usuario con acceso al servidor descargue los modelos y artefactos de otros usuarios, pero al menos limita la exposición. Exponerlo en un servidor público orientado a Internet supone que absolutamente nada de lo almacenado en el servidor o en el servidor remoto de almacenamiento de artefactos contiene datos sensibles".
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú