Los investigadores de ciberseguridad advierten sobre los riesgos de seguridad en la cadena de suministro de software de aprendizaje automático (ML) tras el descubrimiento de más de 20 vulnerabilidades que podrían explotarse para apuntar a plataformas MLOps.
Estas vulnerabilidades, descritas como fallas inherentes y relacionadas con la implementación, podrían tener consecuencias graves, que van desde la ejecución de código arbitrario hasta la carga de conjuntos de datos maliciosos.
Las plataformas MLOps brindan la capacidad de diseñar y ejecutar una canalización de modelos de ML, con un registro de modelos que actúa como un repositorio utilizado para almacenar y entrenar modelos de ML. Estos modelos luego se pueden integrar en una aplicación o permitir que otros clientes los consulten utilizando una API (también llamada modelo como servicio).
«Las vulnerabilidades inherentes son vulnerabilidades causadas por los formatos y procesos subyacentes utilizados en la tecnología de destino», explican los investigadores de JFrog. dicho en un informe detallado.
Algunos ejemplos de vulnerabilidades inherentes incluyen el uso indebido de modelos de aprendizaje automático para ejecutar código elegido por el atacante aprovechando el hecho de que los modelos admiten la ejecución automática de código al cargar (por ejemplo, archivos de modelo Pickle).
Este comportamiento también se extiende a ciertos formatos y bibliotecas de conjuntos de datos, que permiten la ejecución automática de código, lo que podría abrir la puerta a ataques de malware simplemente cargando un conjunto de datos disponible públicamente.
Otro ejemplo de vulnerabilidad inherente es el de JupyterLab (anteriormente Jupyter Notebook), un entorno informático interactivo basado en web que permite a los usuarios ejecutar bloques (o celdas) de código y mostrar los resultados correspondientes.
«Un problema inherente que muchos desconocen es el manejo de la salida HTML cuando se ejecutan bloques de código en Jupyter», señalaron los investigadores. “La salida de su código Python puede emitir HTML y [JavaScript] que será felizmente renderizado por su navegador.»
El problema aquí es que el resultado de JavaScript, una vez ejecutado, no está protegido por la aplicación web principal y la aplicación web principal puede ejecutar automáticamente código Python arbitrario.
En otras palabras, un atacante podría generar código JavaScript malicioso que agrega una nueva celda en el cuaderno actual de JupyterLab, inyecta código Python en él y luego lo ejecuta. Esto es particularmente cierto en casos de explotación de una vulnerabilidad de secuencias de comandos entre sitios (XSS).
Con este fin, JFrog dijo que ha identificado una falla XSS en MLFlow (CVE-2024-27132Puntuación CVSS: 7,5) que resulta de una falta de limpieza suficiente al ejecutar un archivo que no es de confianza recetalo que da como resultado la ejecución de código del lado del cliente en JupyterLab.
«Una conclusión clave de esta investigación es que debemos tratar todas las vulnerabilidades XSS en las bibliotecas de ML como posible ejecución de código arbitrario, ya que los científicos de datos pueden usar estas bibliotecas de ML con Jupyter Notebook», dijeron los investigadores.
El segundo conjunto de fallas se refiere a las debilidades de implementación, como la falta de autenticación en las plataformas MLOps, lo que potencialmente permite que un actor malicioso con acceso a la red obtenga capacidades de ejecución de código abusando de la funcionalidad ML Pipeline.
Estas amenazas no son teóricas: adversarios motivados financieramente están explotando estas fallas, como se observa en el caso de Anyscale Ray sin parche (CVE-2023-48022, puntuación CVSS: 9,8), para implementar mineros de criptomonedas.
Un segundo tipo de vulnerabilidad de implementación es un escape de contenedor dirigido a Seldon Core que permite a los atacantes ir más allá de la ejecución de código para moverse lateralmente dentro del entorno de la nube y acceder a modelos de datos y conjuntos de datos de otros usuarios cargando un modelo malicioso en el servidor de inferencia.
El resultado neto de encadenar estas vulnerabilidades es que no sólo podrían usarse como armas para infiltrarse y propagarse dentro de una organización, sino también comprometer servidores.
«Si implementas una plataforma que permite servir modelos, ahora necesitas saber que cualquiera que pueda servir un nuevo modelo también puede ejecutar código arbitrario en ese servidor», dijeron los investigadores. “Asegúrese de que el entorno en el que se ejecuta el modelo esté completamente aislado y protegido contra una fuga del contenedor. »
La divulgación se produce como Unidad 42 de Palo Alto Networks detallado dos vulnerabilidades ahora parcheadas en el marco de IA generativa de código abierto LangChain (CVE-2023-46229 y CVE-2023-44467) que podrían haber permitido a los atacantes ejecutar código arbitrario y acceder a datos confidenciales, respectivamente.
El mes pasado, Trail of Bits también reveló Cuatro problemas en Ask Astro, una aplicación de chatbot de generación de recuperación aumentada (RAG) de código abierto, que podrían provocar envenenamiento de la salida del chatbot, ingestión de documentos inexactos y posible denegación de servicio (DoS).
Así como se exponen los problemas de seguridad en las aplicaciones basadas en IA, también se están implementando técnicas. diseñado envenenar conjuntos de datos de entrenamiento con el objetivo final de engañar a grandes modelos de lenguaje (LLM) para que produzcan código vulnerable.
“A diferencia de los ataques recientes que incorporan cargas útiles maliciosas en secciones de código detectables o irrelevantes (por ejemplo, comentarios), CodeBreaker aprovecha los LLM (por ejemplo, GPT-4) para una transformación sofisticada de la carga útil (sin afectar las funciones), lo que garantiza que los datos envenenados para realizar ajustes y El código generado puede escapar a una fuerte detección de vulnerabilidades”, dijo un grupo de académicos de la Universidad de Connecticut. dicho.
