El marco de IA de código abierto MLflow afectado por una falla crítica

MLflow, un marco de código abierto utilizado por muchas empresas para administrar sus pruebas de aprendizaje automático y registrar los resultados, se ve afectado por una falla crítica. Esto abre el camino para que los atacantes extraigan información confidencial de los servidores, como claves SSH y credenciales de AWS. Los ataques se pueden ejecutar de forma remota sin autenticación, ya que MLflow no implementa la autenticación de forma predeterminada, ya que un número cada vez mayor de implementaciones de MLflow están expuestas directamente a Internet. "En pocas palabras, todas las empresas que utilizan esta herramienta corren el riesgo de perder sus modelos de IA, tener un servidor interno comprometido y su cuenta de AWS comprometida", dijo Dan McInerney, ingeniero de seguridad sénior de la startup. Proteja la ciberseguridad de la IA. "Es bastante brutal". El Sr. McInerney descubrió la vulnerabilidad y la informó al proyecto MLflow de forma privada. Se corrigió en la versión 2.2.1 del marco lanzado hace tres semanas, pero las notas de la versión no mencionan ninguna corrección de seguridad.

Inclusión de archivos locales y remotos a través de un ataque transversal de ruta

Escrito en Python, MLflow automatiza los flujos de trabajo de aprendizaje automático. Debido a sus muchos componentes, los usuarios pueden implementar modelos de varias bibliotecas de aprendizaje automático, administrar su ciclo de vida, incluida la versión del modelo, las transiciones de etapa y las anotaciones, realizar un seguimiento de los experimentos para registrar y comparar parámetros y resultados, e incluso empaquetar código de aprendizaje automático en forma reproducible para compartir con otros científicos de datos. MLflow se puede controlar a través de una API REST y una interfaz de línea de comandos. Todas estas capacidades hacen de este marco una herramienta valiosa para cualquier empresa que experimente con el aprendizaje automático. Los análisis que utilizan el motor de búsqueda de Shodan confirman este hallazgo: en los últimos dos años, las instancias de MLflow expuestas públicamente han aumentado constantemente, con un número actual de más de 800. Sin embargo, se puede suponer que existen muchas otras implementaciones de MLflow dentro de las redes internas y podrían ser alcanzado por los atacantes que obtienen acceso a esas redes. “Varias empresas de Fortune 500 con las que contactamos nos han confirmado que usan MLflow internamente para su flujo de trabajo de ingeniería de IA”, dijo McInerney.

Catalogada con la referencia CVE-2023-1177, la vulnerabilidad crítica descubierta por Dan McInerney tiene una notable puntuación CVSS de 10. Según este repositorio, ésta -de tipo inclusión de archivo local (LFI) o remota (RFI) da la posibilidad de una atacante remoto no autenticado para enviar solicitudes diseñadas específicamente al punto final de la API, lo que obliga a MLflow a exponer el contenido de cualquier archivo legible en el servidor. Por ejemplo, el atacante puede incluir JSON en una solicitud donde el parámetro fuente es un archivo de su elección en el servidor y la aplicación lo devolverá. Uno de estos archivos puede ser una clave ssh, generalmente almacenada en el directorio .ssh dentro del directorio de inicio del usuario local. Sin embargo, el conocimiento previo del directorio de inicio del usuario no es un requisito para la explotación, ya que el atacante puede leer primero el archivo /etc/passwd, disponible en todos los sistemas Linux, que enumera todos los usuarios disponibles y sus directorios de inicio.

Despliegues inseguros debido a la autenticación predeterminada

Ninguno de los otros parámetros enviados como parte de la solicitud maliciosa debe existir y puede ser arbitrario. La vulnerabilidad se ve agravada por el hecho de que la mayoría de las empresas configuran sus instancias de MLflow para usar Amazon AWS S3 para almacenar sus modelos y otros datos confidenciales. Según el análisis de configuración de Protect AI de las instancias de MLflow disponibles públicamente, siete de cada diez configuraciones utilizaron AWS S3. Esto significa que los atacantes pueden configurar el parámetro de origen de su solicitud JSON para que sea la URL s3:// del depósito utilizado por la instancia para robar modelos de forma remota. Esto también significa que las credenciales de AWS probablemente se almacenen localmente en el servidor de MLflow para que el marco pueda acceder a los depósitos de S3, y esas credenciales generalmente se almacenan en una carpeta llamada ~/.aws/credentials en el directorio de inicio del usuario. Exponer las credenciales de AWS puede ser una infracción grave porque, según la política de IAM, puede otorgar a los atacantes capacidades de movimiento lateral dentro de la infraestructura de AWS de una empresa.

Requerir autenticación para acceder al extremo de la API evitaría que se explote esta falla, pero MLflow no implementa ningún mecanismo de autenticación. Es posible agregar una autenticación básica con un nombre de usuario y una contraseña estáticos al implementar un servidor proxy como nginx frente al servidor MLflow y, por lo tanto, forzar la autenticación. Desafortunadamente, casi ninguna de las instancias expuestas públicamente usa esa configuración. "Es difícil decir que esta forma de implementar la herramienta es segura, pero al menos, la implementación más segura de MLflow tal como está actualmente es mantenerlo en una red interna, en un segmento de red separado de todos los usuarios excepto aquellos que necesita usarlo y ponerlo detrás de un proxy nginx con autenticación básica ", explicó McInerney. "No impide que un usuario con acceso al servidor descargue modelos y artefactos de otros usuarios, pero al menos limita la exposición. La exposición en un servidor público con acceso a Internet supone que absolutamente nada almacenado en el servidor o en el servidor de almacenamiento de artefactos remotos contiene datos confidenciales”, agregó.