imágenes falsas
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 ponen sus manos en un clúster de producción de Ray, es un premio gordo”, escribieron en un comunicado investigadores de Oligo, la empresa de seguridad que detectó los ataques. correo
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.
-
Hashes de contraseña accedidos
-
Credenciales de la 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 del 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 permitir 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 marcó el comportamiento
Un marco de ejecución distribuido
“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ó por 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 debe estar segmentado 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 proteger adecuadamente sus grupos en la forma 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 es disponible en el propio sitio web de Anyscale. Otro ejemplo de una configuración vulnerable disponible públicamente es 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.