El año 2023 fue un año crucial para la inteligencia artificial generativa (GenIA). El lanzamiento de Large Language Models (LLM) ha demostrado el poder de la tecnología para hacer que los procesos comerciales sean más eficientes. Muchas empresas han buscado activamente adoptar la IA generativa entrenando modelos en sus propios conjuntos de datos. Desarrollar y entrenar modelos de IA puede resultar tan costoso que se convierte en uno de los activos más valiosos de la empresa. Por lo tanto, es importante tener en cuenta que estos modelos son susceptibles a robos o ataques y que los sistemas que los albergan deben tener políticas y protecciones de seguridad sólidas. Una vulnerabilidad parcheada recientemente en la plataforma de gestión del ciclo de vida del modelo de aprendizaje automático de código abierto MLflow muestra con qué facilidad los atacantes podrían robar o envenenar datos de entrenamiento confidenciales cuando un desarrollador visita un sitio web aleatorio en Internet desde la misma máquina donde se ejecuta MLflow. La falla, con referencia CVE-2023-43472, se corrigió en la versión 2.9.0 de MLflow. Esta no es la primera vez que esta plataforma expone modelos de IA y aprendizaje automático almacenados en la nube. Este también fue el caso el pasado mes de marzo..
Muchos desarrolladores creen erróneamente que los servicios vinculados al host local (el nombre de host interno de una computadora) no pueden accederse desde Internet. Esto es lo que explicó Joseph Beeton, investigador principal en seguridad de aplicaciones de Contrast Security, durante una conferencia dedicada a atacar entornos de desarrollo a través de servicios localhost organizada a finales de noviembre durante DefCamp 2023. De hecho, Joseph Beeton descubrió recientemente graves vulnerabilidades en el marco de Java. Quarkus y MLflow permiten a atacantes remotos explotar localmente características de interfaces de desarrollo o API expuestas por estas aplicaciones. Los ataques solo requieren que el usuario visite un sitio web controlado por el atacante en su navegador o un sitio legítimo donde el atacante haya colocado con éxito anuncios específicos.
Ataques al servidor local mediante código JavaScript malicioso
Los ataques de secuestro de sitios ocultos existen desde hace mucho tiempo, pero son poderosos cuando se combinan con una vulnerabilidad de falsificación de solicitudes entre sitios (CSRF) en una aplicación. En el pasado, los piratas informáticos han utilizado ataques ocultos a través de anuncios maliciosos colocados en sitios web para secuestrar la configuración DNS de los enrutadores domésticos de los usuarios. Normalmente, los navegadores sólo permiten que el código JavaScript realice solicitudes a recursos del mismo origen (dominio) que el script. Pero es posible utilizar un mecanismo especial llamado Intercambio de recursos entre orígenes (CORS) para evitar esta restricción y permitir que los scripts realicen solicitudes de diferentes orígenes si el servidor de destino lo autoriza específicamente. Por ejemplo, si un fragmento de código JavaScript cargado en un navegador del dominio A intenta realizar una solicitud al dominio B, el navegador primero realizará una llamada solicitud de verificación previa para verificar si el dominio B tiene una política CORS que permita solicitudes con script desde dominio a.
Aunque esta restricción también se aplica al host local, Joseph Beeton señala que existe otro tipo de solicitud llamada "solicitud simple", que todavía está permitida por la mayoría de los navegadores (excepto Safari) y que no desencadena una solicitud de diligencia debida porque es anterior a la política CORS. Por ejemplo, estas solicitudes las utiliza el elemento estándar HTML para enviar datos de un origen a otro, pero también pueden activarse mediante JavaScript. Una solicitud simple puede ser de tipo GET, POST y HEAD y puede tener un tipo de contenido application/x-www-form-urlencoded, multipart/form-data, text/plain o ningún tipo de contenido. Sin embargo, con una limitación: el script que los crea no recibe una respuesta, a menos que el servidor de destino la acepte a través del encabezado Access-Control-Allow-Origin. origen). Pero, desde la perspectiva de un ataque, no es realmente necesario obtener una respuesta siempre que se produzca la acción prevista desencadenada por la solicitud. Este es el caso de las vulnerabilidades de MLflow y Quarkus.
Robo y envenenamiento de modelos de aprendizaje automático.
Una vez instalado MLflow, se puede acceder a su interfaz de usuario de forma predeterminada a través de http://localhost:5000 y admite una API REST a través de la cual es posible realizar acciones mediante programación. Normalmente, la interacción con la API se realiza mediante solicitudes POST con un tipo de contenido aplicación/JSON que no está permitido para solicitudes simples. Sin embargo, Beeton descubrió que la API de MLflow no verificaba el tipo de contenido de las consultas y permitía consultas de texto sin formato. Esto permite ataques remotos de origen cruzado a través del navegador mediante solicitudes simples. La API tiene una funcionalidad limitada, como crear una nueva experiencia o cambiar el nombre de una experiencia existente, pero no eliminar experiencias.
Convenientemente, el experimento predeterminado en MLflow, en el que se guardarán nuevos datos, se llama "Predeterminado", por lo que los atacantes pueden enviar primero una solicitud para cambiarle el nombre a "Antiguo" y luego crear uno nuevo. experiencia, que se llamará "Predeterminado" pero tendrá un artefacto_uri que apunta a un depósito de almacenamiento S3 externo que ellos controlan. "Una vez que se realiza una nueva ejecución de MLFLow, por ejemplo, mlflow run sklearn_elasticnet_wine -P alpha=0.5, nombre-experimento predeterminado, el resultado de la ejecución se cargará en el depósito de S3", explicó Joseph Beeton. en una publicación de blog. Esto permitiría al atacante obtener una versión serializada del modelo ML junto con los datos utilizados para entrenarlo. El atacante podría llegar incluso más lejos. "Dado que un modelo de ML está almacenado en el depósito, sería posible envenenar el modelo de ML en sí", dijo el investigador. "En tal ataque, un adversario puede inyectar datos erróneos en el grupo de entrenamiento del modelo y hacer que aprenda algo que no debería", añadió el investigador.
La ejecución remota de código también es posible si el atacante modifica el archivo model.pkl para inyectar un exploit Python Pickle. La ejecución remota de código también fue posible en el caso de la vulnerabilidad Quarkus, también descubierta por Beeton. Y también era explotable a través de solicitudes simples desde sitios web remotos porque la interfaz de usuario de desarrollo de la aplicación estaba vinculada al host local y no tenía protección adicional contra ataques de falsificación de solicitudes entre sitios. CSRF. "Como demostré durante la presentación en DefCamp, es posible generar ejecución remota de código (RCE) en la máquina del desarrollador o en otros servicios en su red privada", dijo. declaró el investigador. “Dado que los desarrolladores tienen acceso de escritura a las bases de código, claves de AWS, ID de servidor, etc., el acceso a la máquina del desarrollador le da al atacante mucho espacio para acceder a otros recursos de la red y modificar o robar por completo la base del código. "
Otras noticias que te pueden interesar