La falla del SDK de Google Vertex AI permite a los atacantes secuestrar cargas de modelos a través de Bucket Squatting – CYBERDEFENSA.MX

Una falla en el SDK de Google Cloud Vertex AI para Python permitió a un atacante sin acceso al proyecto de una víctima secuestrar el modelo de aprendizaje automático de la víctima, cargar y ejecutar código dentro de la infraestructura de servicio de Google.

Unidad 42 de Palo Alto Networks, que encontró y reportado El error a través del programa de recompensas por errores de Google, llama a la técnica «Pepinillo en el medio» y dijo que no vio ninguna explotación en la naturaleza. Google lo ha parcheado; si usa el SDK, actualice a la versión 1.148.0 o posterior.

El atacante solo necesitaba un proyecto propio de Google Cloud y el ID del proyecto de la víctima, que suele ser público. Sin credenciales, sin phishing, sin punto de apoyo en el objetivo.

La falla estaba en cómo el SDK eligió un depósito temporal de Cloud Storage para la carga de modelos. Si un usuario no configuró un depósito, el SDK generó un nombre predecible a partir del ID del proyecto y la región, como región-ensayo-vértice-del-proyecto. Comprobó si ese cubo existía, pero no si la víctima era su propietario.

Debido a que los nombres de los depósitos son globalmente únicos, un atacante podría crear primero el depósito esperado en su propio proyecto. El SDK de la víctima luego cargaría los archivos del modelo en el depósito del atacante. Luego, el atacante podría reemplazar el modelo cargado por uno malicioso.

Ciberseguridad

Muchos modelos de Python ML se guardan con conservar en vinagre o biblioteca de trabajoque puede ejecutar código cuando se carga un archivo. Cuando Vertex AI cargó más tarde el modelo intercambiado, el código del atacante se ejecutó dentro del contenedor de servicio.

El ataque dependía de la velocidad. La Unidad 42 midió aproximadamente 2,5 segundos entre la carga de la víctima y Vertex AI leyendo el archivo. En su prueba de concepto, el atacante utilizó una función en la nube que se activó después de la carga y reemplazó el modelo en 1,4 segundos, antes de que Vertex AI lo leyera.

Luego, la carga útil robó un token OAuth del servidor de metadatos del contenedor de servicio y lo envió al atacante. En el entorno de prueba de la Unidad 42, ese token no se limitó a la implementación comprometida. Podría acceder a otros artefactos del modelo en el mismo proyecto de inquilino administrado por Google, incluido un modelo TensorFlow completo con pesos entrenados, así como metadatos de BigQuery, listas de acceso, registros de inquilinos, nombres de clústeres de GKE y rutas de imágenes de contenedores internos.

El ataque solo funcionó bajo condiciones específicas: el depósito de preparación predeterminado de la víctima no existía aún en esa región y la víctima abandonó el cubo_puesta en escena parámetro desarmado. El primero es común para un nuevo proyecto en Vertex AI en una región.

El segundo depende de que el desarrollador confíe en el valor predeterminado del SDK en lugar de nombrar su propio depósito.

La Unidad 42 informó la falla a través del Programa de recompensa por vulnerabilidades de Google el 5 de marzo de 2026. Probó las versiones 1.139.0 y 1.140.0, las últimas disponibles en ese momento, y encontró que ambas eran vulnerables.

Google envió una solución inicial en v1.144.0 el 31 de marzo, agregando un uuid4 aleatorio al nombre del depósito. Completó la solución en v1.148.0 el 15 de abril, se agregó la verificación de propiedad del depósito para bloquear la okupación del depósito en Model.upload(). Al momento de su publicación, ni Unit 42 ni los boletines de seguridad Vertex AI de Google enumeran un CVE para el problema.

Ciberseguridad

Actualice a 1.148.0 o posterior para que la verificación de propiedad esté activa. Además, establezca un staging_bucket explícito en una ubicación de Cloud Storage que controle al cargar modelos. Debido a que la lógica defectuosa reside en el SDK del cliente, verifique la versión de google-cloud-aiplatform dondequiera que se ejecute, incluidos los cuadernos, los trabajos de CI y los canales de capacitación, no solo los servicios de producción.

Es la segunda falla con nombre de depósito predecible que surge en Vertex AI este año. Google parcheado CVE-2026-2473 en febrero, un error separado en Vertex AI Experiments que también permitió la ejecución de código entre inquilinos, el robo de modelos y el envenenamiento.

El trabajo anterior de la Unidad 42 sobre los permisos de agente de servicio predeterminados de Vertex AI trazó una ruta relacionada desde un agente de IA implementado hasta los datos de clientes e inquilinos.

La vulnerabilidad de Vertex AI expone datos de Google Cloud y artefactos privados – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han revelado un «punto ciego» de seguridad en la plataforma Vertex AI de Google Cloud que podría permitir que un atacante utilice agentes de inteligencia artificial (IA) para obtener acceso no autorizado a datos confidenciales y comprometer el entorno de nube de una organización.

Según la Unidad 42 de Palo Alto Networks, el problema se relaciona con cómo se puede hacer un mal uso del modelo de permisos de Vertex AI aprovechando la agente de servicioEl alcance excesivo del permiso de forma predeterminada.

«Un agente mal configurado o comprometido puede convertirse en un ‘agente doble’ que parece cumplir su propósito previsto, mientras extrae secretamente datos confidenciales, compromete la infraestructura y crea puertas traseras en los sistemas más críticos de una organización», dijo el investigador de la Unidad 42, Ofir Shaty. dicho en un informe compartido con The Hacker News.

Ciberseguridad

Específicamente, la empresa de ciberseguridad descubrió que el agente de servicio por proyecto y por producto (P4SA) asociado con un agente de IA implementado creado con el kit de desarrollo de agentes de Vertex AI (ADK) tenía permisos excesivos otorgados de forma predeterminada. Esto abrió la puerta a un escenario en el que los permisos predeterminados de P4SA podrían usarse para extraer las credenciales de un agente de servicio y realizar acciones en su nombre.

Después de implementar el agente Vertex a través de Motor de agentecualquier llamada al agente invoca el servicio de metadatos de Google y expone las credenciales del agente de servicio, junto con el proyecto de Google Cloud Platform (GCP) que aloja al agente de IA, la identidad del agente de IA y los alcances de la máquina que aloja al agente de IA.

La Unidad 42 dijo que pudo usar las credenciales robadas para saltar del contexto de ejecución del agente de IA al proyecto del cliente, socavando efectivamente las garantías de aislamiento y permitiendo el acceso de lectura sin restricciones a todos los datos de los depósitos de Google Cloud Storage dentro de ese proyecto.

«Este nivel de acceso constituye un riesgo de seguridad significativo, transformando al agente de IA de una herramienta útil a una potencial amenaza interna», añadió.

Eso no es todo. Con el Vertex AI Agent Engine implementado ejecutándose dentro de un proyecto de inquilino administrado por Google, las credenciales extraídas también otorgaron acceso a los depósitos de Google Cloud Storage dentro del inquilino, ofreciendo más detalles sobre la infraestructura interna de la plataforma. Sin embargo, se descubrió que las credenciales carecían de los permisos necesarios para acceder a los depósitos expuestos.

Para empeorar las cosas, las mismas credenciales del agente de servicio P4SA también permitieron el acceso a repositorios restringidos de Artifact Registry propiedad de Google que se revelaron durante la implementación de Agent Engine. Un atacante podría aprovechar este comportamiento para descargar imágenes de contenedores de repositorios privados que constituyen el núcleo de Vertex AI Reasoning Engine.

Es más, las credenciales de P4SA comprometidas no solo permitieron descargar imágenes que aparecían en los registros durante la implementación de Agent Engine, sino que también expusieron el contenido de los repositorios de Artifact Registry, incluidas varias otras imágenes restringidas.

«Obtener acceso a este código propietario no sólo expone la propiedad intelectual de Google, sino que también proporciona al atacante un modelo para encontrar más vulnerabilidades», explicó la Unidad 42.

Ciberseguridad

«El Artifact Registry mal configurado resalta una falla adicional en la gestión del control de acceso para la infraestructura crítica. Un atacante podría potencialmente aprovechar esta visibilidad no intencionada para mapear la cadena de suministro de software interna de Google, identificar imágenes obsoletas o vulnerables y planificar futuros ataques».

Google desde entonces actualizó su documentación oficial para explicar claramente cómo Vertex AI utiliza los recursos, las cuentas y los agentes. El gigante tecnológico también recomendó que los clientes utilicen Traiga su propia cuenta de servicio (BYOSA) para reemplazar al agente de servicio predeterminado y hacer cumplir el principio de privilegio mínimo (PoLP) para garantizar que el agente tenga solo los permisos que necesita para realizar la tarea en cuestión.

«Otorgar a los agentes permisos amplios de forma predeterminada viola el principio de privilegio mínimo y es una falla de seguridad peligrosa por diseño», dijo Shaty. «Las organizaciones deben tratar la implementación de agentes de IA con el mismo rigor que el nuevo código de producción. Validar los límites de permisos, restringir los alcances de OAuth al mínimo privilegio, revisar la integridad de la fuente y realizar pruebas de seguridad controladas antes del lanzamiento de la producción».