Getty Images Miles de servidores que almacenan cargas de trabajo de IA y credenciales de red han sido pirateados en una campaña de ataque en curso dirigida a una vulnerabilidad reportada en Ray, un marco informático utilizado por OpenAI, Uber y Amazon. Los ataques, que han estado activos durante al menos siete meses, han provocado la manipulación de modelos de IA. También han resultado en el compromiso de las credenciales de red, permitiendo el acceso a redes internas y bases de datos y tokens para acceder a cuentas en plataformas como OpenAI, Hugging Face, Stripe y Azure. Además de corromper modelos y robar credenciales, los atacantes detrás de la campaña han instalado mineros de criptomonedas en infraestructura comprometida, que normalmente proporciona cantidades masivas de potencia informática. Los atacantes también han instalado shells inversos, que son interfaces basadas en texto para controlar servidores de forma remota. Ganar el premio gordo “Cuando los atacantes consiguen un clúster de producción de Ray, es un premio gordo”, escribieron en una publicación investigadores de Oligo, la empresa de seguridad que detectó los ataques. «Los datos valiosos de la empresa, además de la ejecución remota de código, facilitan la monetización de los ataques, todo ello mientras se permanece en las sombras, sin ser detectado (y, con herramientas de seguridad estáticas, indetectable)». Entre la información sensible comprometida se encuentran las cargas de trabajo de producción de IA, que permiten a los atacantes controlar o alterar los modelos durante la fase de entrenamiento y, a partir de ahí, corromper la integridad de los modelos. Los clústeres vulnerables exponen un panel central a Internet, una configuración que permite a cualquiera que lo busque ver un historial de todos los comandos ingresados ​​hasta la fecha. Este historial permite a un intruso aprender rápidamente cómo funciona un modelo y a qué datos confidenciales tiene acceso. Oligo capturó capturas de pantalla que exponían datos privados confidenciales y mostraban historiales que indicaban que los clústeres habían sido pirateados activamente. Los recursos comprometidos incluían hashes de contraseñas criptográficas y credenciales para bases de datos internas y cuentas en OpenAI, Stripe y Slack. Operador de Kuberay ejecutándose con permisos de administrador en la API de Kubernetes. Se accedió a hash de contraseña Credenciales de base de datos de producción Modelo de IA en acción: manejo de una consulta enviada por un usuario en tiempo real. El atacante podría abusar del modelo, lo que potencialmente podría modificar las solicitudes o respuestas de los clientes. Tokens para OpenAI, Stripe, Slack y credenciales de bases de datos. Panel de control de clúster con cargas de trabajo de producción y tareas activas Ray es un marco de código abierto para escalar aplicaciones de IA, lo que significa que permite que una gran cantidad de ellas se ejecuten a la vez de manera eficiente. Normalmente, estas aplicaciones se ejecutan en grandes grupos de servidores. La clave para que todo esto funcione es un panel central que proporciona una interfaz para mostrar y controlar las tareas y aplicaciones en ejecución. Una de las interfaces de programación disponibles a través del panel, conocida como Jobs API, permite a los usuarios enviar una lista de comandos al clúster. Los comandos se emiten mediante una simple solicitud HTTP que no requiere autenticación. El año pasado, investigadores de la firma de seguridad Bishop Fox señalaron el comportamiento como una vulnerabilidad de ejecución de código de alta gravedad rastreada como CVE-2023-48022. Un marco de ejecución distribuida «En la configuración predeterminada, Ray no aplica la autenticación», escribió Berenice Flores García, consultora senior de seguridad de Bishop Fox. «Como resultado, los atacantes pueden enviar trabajos libremente, eliminar trabajos existentes, recuperar información confidencial y explotar las otras vulnerabilidades descritas en este aviso». Anyscale, el desarrollador y mantenedor de Ray, respondió cuestionando la vulnerabilidad. Los funcionarios de Anyscale dijeron que siempre han presentado a Ray como marco para ejecutar código de forma remota y, como resultado, han aconsejado durante mucho tiempo que debería segmentarse adecuadamente dentro de una red debidamente segura. «Debido a la naturaleza de Ray como marco de ejecución distribuida, el límite de seguridad de Ray está fuera del clúster de Ray», escribieron los funcionarios de Anyscale. «Es por eso que enfatizamos que debe evitar el acceso a su clúster Ray desde máquinas que no sean de confianza (por ejemplo, la Internet pública)». La respuesta de Anyscale decía que el comportamiento informado en la API de trabajos no era una vulnerabilidad y no se abordaría en una actualización a corto plazo. La compañía continuó diciendo que eventualmente introduciría un cambio que impondría la autenticación en la API. Explicó: Hemos considerado muy seriamente si algo así sería una buena idea o no, y hasta la fecha no lo hemos implementado por temor a que nuestros usuarios confíen demasiado en un mecanismo que podría terminar proporcionando una fachada de seguridad sin asegurando adecuadamente sus grupos de la manera que imaginaban. Dicho esto, reconocemos que las mentes razonables pueden diferir sobre este tema y, en consecuencia, hemos decidido que, si bien todavía no creemos que una organización deba depender de controles de aislamiento dentro de Ray como la autenticación, puede ser valioso en ciertos contextos para promover una estrategia de defensa en profundidad, por lo que implementaremos esto como una nueva característica en una versión futura. Los críticos de la respuesta de Anyscale han señalado que los repositorios para optimizar la implementación de Ray en entornos de nube vinculan el tablero a 0.0.0.0, una dirección utilizada para designar todas las interfaces de red y para designar el reenvío de puertos en la misma dirección. Uno de esos textos estándar para principiantes está disponible en el sitio web de Anyscale. Otro ejemplo de una configuración vulnerable disponible públicamente está aquí. Los críticos también señalan que la afirmación de Anyscale de que el comportamiento informado no es una vulnerabilidad ha impedido que muchas herramientas de seguridad detecten ataques. Un representante de Anyscale dijo en un correo electrónico que la compañía planea publicar un script que permitirá a los usuarios verificar fácilmente si sus instancias de Ray están expuestas a Internet o no. Los ataques en curso subrayan la importancia de configurar Ray correctamente. En los enlaces proporcionados anteriormente, Oligo y Anyscale enumeran prácticas que son esenciales para bloquear clústeres. Oligo también proporcionó una lista de indicadores que los usuarios de Ray pueden utilizar para determinar si sus instancias se han visto comprometidas.

Source link