Ciberseguridad
Inteligencia artificial

Miles de servidores se ven comprometidos por la implementación insegura del marco Ray

Las implementaciones de Ray no están destinadas a conectarse a Internet, pero los desarrolladores de IA lo hacen de todos modos y dejan sus servidores vulnerables.

Fortinet - estrategia de seguridad

Un grupo de investigadores de Oligo ha advertido de que miles de servidores se han visto comprometidos en los últimos meses debido a la falta de autenticación predeterminada en un marco informático de código abierto llamado Ray, que se utiliza para distribuir cargas de trabajo de inteligencia artificial (IA) y aprendizaje automático. No obstante, los desarrolladores de este marco no reconocen la falta de autenticación como una vulnerabilidad ya que se trata de una decisión intencional de diseño documentada. Esto no ha impedido que las organizaciones expongan las implementaciones a Internet.

“Miles de empresas y servidores que ejecutan infraestructura de IA están expuestos al ataque a través de una vulnerabilidad crítica que está en disputa y, por lo tanto, no tiene parche",aseguran los investigadores en un informe. "Esta vulnerabilidad permite a los atacantes apoderarse de la potencia informática de las empresas y filtrar datos confidenciales".

Hasta ahora, Oligo ha identificado servidores comprometidos de organizaciones de muchos sectores industriales, incluidos educación, criptomonedas, biofarmacia y análisis de vídeo. Muchos de los servidores de Ray tenían habilitado el historial de comandos, lo que significa que los atacantes podían descubrir fácilmente secretos confidenciales que se utilizaron en comandos anteriores en esos servidores.

Ray se utiliza a menudo para ejecutar cargas de trabajo que se utilizan para entrenar, servir y ajustar modelos de IA y algunos de los trabajos incluyen scripts de Python y comandos bash que pueden contener las credenciales necesarias para integrarse con servicios de terceros. "Un entorno ML-OPS consta de muchos servicios que se comunican entre sí, dentro del mismo clúster y entre clústeres", dijeron los investigadores. “Cuando se utiliza para entrenamiento o ajuste, generalmente tiene acceso a conjuntos de datos y modelos, en disco o en almacenamiento remoto, como un depósito S3. A menudo, los modelos o conjuntos de datos son la propiedad intelectual privada única que diferencia a una empresa de sus competidores”.

 

Una característica prevista con implicaciones de seguridad

El año pasado, investigadores de seguridad de Bishop Fox encontraron e informaron cinco vulnerabilidades en el marco de Ray. Anyscale, la empresa que mantiene el software, decidió parchear cuatro de ellos (CVE-2023-6019, CVE-2023-6020, CVE-2023-6021 y CVE-2023-48023) en la versión 2.8.1, pero afirmó que el quinto, al que se le asignó CVE-2023-48022, no era realmente una vulnerabilidad, por lo que no se solucionó.

Esto se debe a que CVE-2023-48022 en realidad es causado directamente por el hecho de que el panel de Ray y la API del cliente no implementan controles de autenticación. Por lo tanto, cualquier atacante que pueda llegar a los puntos finales de la API puede enviar nuevos trabajos, eliminar trabajos existentes, recuperar información confidencial y, esencialmente, lograr la ejecución remota de comandos.

El problema es que, como marco cuyo objetivo principal es facilitar la ejecución de cargas de trabajo en clústeres informáticos, la "ejecución remota de comandos" es esencialmente una característica y la falta de autenticación también es una cuestión de diseño. "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", dijo Anyscale en su aviso. “Es por eso que enfatizamos que debe impedir el acceso a su clúster Ray desde máquinas que no sean de confianza (por ejemplo, la Internet pública). Esta es la razón por la que no se ha abordado el quinto CVE (la falta de autenticación integrada en Ray) y por qué, en nuestra opinión, no es una vulnerabilidad, ni siquiera un error”.

La documentación de Ray establece claramente que "Ray espera ejecutarse en un entorno de red seguro y actuar según un código confiable" y que es responsabilidad de los desarrolladores y proveedores de plataformas garantizar esas condiciones para una operación segura. Sin embargo, como hemos visto con otras tecnologías en el pasado que carecían de autenticación de forma predeterminada, los usuarios no siempre siguen las mejores prácticas y, tarde o temprano, las implementaciones inseguras llegarán a Internet. Si bien Anyscale no quiere que los usuarios pongan toda su confianza en un control de aislamiento como la autenticación dentro de Ray en lugar de aislar todo el marco y los clústeres con controles externos, ha decidido trabajar para agregar un mecanismo de autenticación en versiones futuras.

 

Configuraciones inseguras por defecto

Hasta entonces, sin embargo, es probable que muchas organizaciones sigan exponiendo involuntariamente dichos servidores a Internet porque, según Oligo, muchas guías de implementación y repositorios de Ray, incluidos algunos de los oficiales, vienen con configuraciones de implementación inseguras. Las configuraciones erróneas también se facilitan por el hecho de que, de forma predeterminada, el panel de Ray y la API de Jobs se vinculan a 0.0.0.0, lo que básicamente significa todas las interfaces de red disponibles en un sistema y abre el reenvío de puertos en el firewall para todas ellas.

"Los expertos en IA NO son expertos en seguridad, lo que los deja potencialmente peligrosamente inconscientes de los riesgos muy reales que plantean los marcos de IA", dijeron los investigadores. "Sin autorización para la API Jobs de Ray, la API puede quedar expuesta a ataques de ejecución remota de código si no sigue las mejores prácticas".



TE PUEDE INTERESAR...

Accede a la cobertura de nuestros encuentros
 
Lee aquí nuestra revista digital de canal

DealerWorld Digital

 

Forma parte de nuestra comunidad
 
¿Interesado en nuestros foros? 

 

Whitepaper

Documento Pure Storage y Kyndryl INFRAESTRUCTURAS