Alerta sobre la seguridad de los modelos de aprendizaje automático con el descubrimiento de una falla grave en el framework de código abierto MLflow. Los atacantes podrían usar esto para extraer información confidencial de los servidores, como claves SSH y credenciales de AWS. Las campañas se pueden ejecutar de forma remota sin autenticación porque MLflow no implementa la autenticación de forma predeterminada y un número cada vez mayor de implementaciones de MLflow están expuestas directamente a Internet.

"En pocas palabras, cada empresa que utiliza esta herramienta corre el riesgo de perder sus modelos de IA, de que un servidor interno se vea comprometido y de que su cuenta de AWS se vea comprometida", dijo Dan McInerney, ingeniero de seguridad senior de Startup de ciberseguridad Protect AI. "Es bastante brutal". Descubrió la vulnerabilidad y la informó al proyecto MLflow de forma privada. Se solucionó 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.

Índice
  1. Un marco ampliamente utilizado
  2. Un defecto clasificado 10 en CVSS
  3. Implementaciones inseguras debido a la falta de autenticación predeterminada

Un marco ampliamente utilizado

Escrito en Python, MLflow automatiza los flujos de trabajo de aprendizaje automático. Debido a sus numerosos componentes, los usuarios pueden implementar modelos de varias bibliotecas de aprendizaje automático, administrar su ciclo de vida, incluida la versión del modelo, transiciones de pasos y anotaciones, realizar un seguimiento de 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 Shodan confirman esta observación: en los últimos dos años, las instancias de MLflow expuestas públicamente han seguido aumentando, y el número actual supera las 800. Sin embargo, podemos suponer que existen muchas otras implementaciones de MLflow dentro de las redes internas y podrían ser alcanzados por atacantes que obtengan acceso a estas redes. "Varias empresas de Fortune 500 con las que contactamos confirmaron que estaban utilizando MLflow internamente para su flujo de trabajo de ingeniería de IA", dijo McInerney.

Un defecto clasificado 10 en CVSS

Catalogada como CVE-2023-1177, la vulnerabilidad descubierta por Dan McInerney tiene una calificación de 10 (crítica) en la escala CVSS. El repositorio lo describe como inclusión de archivos local y remota (LFI/RFI) a través de la API, donde un atacante remoto y no autenticado puede enviar solicitudes específicamente diseñadas al punto final de la API que obligaría 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 de origen es un archivo de su elección en el servidor y la aplicación lo devolverá. Uno de estos archivos pueden ser las claves ssh, generalmente almacenadas en el directorio .ssh dentro del directorio de inicio del usuario local. Sin embargo, el conocimiento previo del directorio personal del usuario no es una condición para la explotación, porque el atacante puede leer primero el archivo. /etc/contraseñadisponible en todos los sistemas Linux, que enumera todos los usuarios disponibles y sus directorios de inicio. Ninguno de los demás parámetros enviados como parte de la solicitud maliciosa necesita existir y puede ser arbitrario.

La vulnerabilidad se vuelve más grave porque la mayoría de las empresas configuran sus instancias de MLflow para usar AWS S3 para almacenar sus modelos y otros datos confidenciales. Según el análisis de configuración de Protect AI de instancias de MLflow disponibles públicamente, siete de cada diez configuraciones utilizaron 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 MLflow para que el marco pueda acceder a los depósitos de S3, y estas credenciales generalmente se almacenan en una carpeta llamada ~/.aws/credenciales 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 brindar a los atacantes capacidades de movimiento lateral dentro de la infraestructura de AWS de una organización.

Implementaciones inseguras debido a la falta de autenticación predeterminada

Requerir autenticación para acceder al punto final de API evitaría que se explotara esta vulnerabilidad, pero MLflow no implementa ningún mecanismo de autenticación. Es posible agregar uno con un nombre de usuario y contraseña estáticos implementando un servidor proxy como nginx frente al servidor MLflow y forzando así la autenticación. Desafortunadamente, casi ninguno de los casos expuestos públicamente utiliza dicha configuración.

"Es difícil decir que este modo de implementar la herramienta es seguro, 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 quién necesita usarlo y colocarlo detrás de un proxy nginx con autenticación básica”, explicó Dan McInerney. “Esto 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 sistema de almacenamiento de artefactos remotos contiene datos confidenciales”, añadió.