SAPwned: vulnerabilidad de SAP AI expuso entornos cloud de clientes y resultados privados de IA

• Wiz Research confirmó que, mediante una cadena de vulnerabilidades de aislamiento de tenants en SAP AI Core, la ejecución de código iniciada desde una tarea legítima de entrenamiento de IA podía derivar en la toma del servicio y el acceso a secretos de clientes
• La ruta de ataque combinaba en cadena una evasión de las restricciones de red de Istio, la exposición de tokens de AWS en la configuración de Loki, recursos compartidos EFS sin autenticación y acceso sin autenticación a Helm v2 Tiller
• Con los permisos obtenidos, era posible leer y modificar imágenes y artefactos del Docker Registry interno de SAP, Google Container Registry y Artifactory interno, y también obtener permisos cluster-admin en el clúster de Kubernetes
• Un atacante potencial podía acceder a credenciales de AWS, Azure y SAP HANA Cloud de los clientes, así como a resultados privados de IA como modelos, datasets y código, o contaminar artefactos internos
• SAP corrigió todas las vulnerabilidades reportadas y rotó los secretos relacionados, y Wiz afirmó que no hubo filtración de datos de clientes

---

Problemas de aislamiento de tenants revelados en SAP AI Core

• Wiz Research ha estado investigando el aislamiento de tenants en proveedores de servicios de IA, y SAP AI Core es su tercer reporte después de Hugging Face y Replicate
• SAP AI Core es un servicio administrado que permite a los usuarios desarrollar, entrenar y ejecutar servicios de IA sobre recursos cloud de SAP
• Los servicios de entrenamiento de IA necesitan acceder a grandes volúmenes de datos sensibles de clientes, y SAP AI Core usa claves de acceso cloud que acceden a datos internos de clientes para integrarse con HANA y otros servicios cloud
• La investigación comenzó creando un proyecto de IA desde una cuenta de cliente de SAP con permisos básicos y generando un Pod de Kubernetes mediante un archivo de Argo Workflow permitido por SAP AI Core
• Por diseño, los usuarios podían ejecutar código arbitrario dentro del Pod, pero en el entorno inicial un sidecar de proxy de Istio restringía el acceso de red, lo que dificultaba escanear la red interna

Bug #1: evasión de restricciones de Istio

• El admission controller de SAP bloqueaba opciones de seguridad riesgosas, y también impedía intentos de ejecutar contenedores como root
• Dos configuraciones no bloqueadas permitieron evadir las restricciones de red
  • shareProcessNamespace permitía compartir el namespace de procesos con el contenedor sidecar, lo que hacía posible ver la configuración del proxy de Istio y el token de acceso al servidor central Istiod
  • runAsUser y runAsGroup permitían UID distintos de root, por lo que era posible ejecutar procesos con 1337, el UID de Istio
• Como Istio en sí queda excluido de las reglas iptables de Istio, los procesos ejecutados con UID 1337 operaban sin restricciones de tráfico
• Luego, con el token de Istio, fue posible leer la configuración del servidor Istiod y obtener información del entorno interno

Bug #2: exposición de tokens de AWS en la configuración de Loki

• Dentro del clúster se encontró una instancia de Grafana Loki, y mediante una solicitud al endpoint /config se pudo ver la configuración completa
• La respuesta incluía secretos de AWS que Loki usaba para acceder a S3
• Esos secretos otorgaban acceso al bucket S3 de Loki, que contenía muchos logs del servicio AI Core y logs de Pods de clientes
• SAP consideró que esos logs no eran sensibles

Bug #3: exposición de archivos de usuarios en recursos compartidos EFS sin autenticación

• En la red interna se encontraron seis instancias de AWS Elastic File System, es decir EFS, escuchando en el puerto 2049
• Esas instancias de EFS permitían ver o editar archivos sin credenciales siempre que hubiera acceso de red
• Con solo herramientas NFS de código abierto se podía acceder libremente al contenido compartido
• En EFS había grandes volúmenes de datos de IA, como código y datasets de entrenamiento clasificados por ID de cliente

Bug #4: Helm Tiller sin autenticación expuso Registry interno y Artifactory

• En la red interna se encontró el servicio Tiller, el componente de servidor de Helm v2
• Tiller se comunica mediante una interfaz gRPC en el puerto 44134 y, por defecto, queda expuesto sin autenticación
• Las consultas a Tiller expusieron secretos con altos privilegios para SAP Docker Registry y servidores Artifactory
• Con permisos de lectura era posible leer imágenes internas y builds para extraer secretos comerciales y datos de clientes
• Con permisos de escritura era posible contaminar imágenes y builds para ejecutar un ataque a la cadena de suministro contra el servicio SAP AI Core

Bug #5: toma del clúster de Kubernetes mediante permisos de escritura de Helm Tiller

• Tiller permitía no solo operaciones de lectura, sino también de escritura
• Como el comando install recibe un paquete Helm y lo despliega en un clúster de Kubernetes, el equipo de investigación creó e instaló un paquete Helm malicioso que generaba un nuevo Pod con permisos cluster-admin
• Con este proceso obtuvieron permisos completos sobre el clúster
• Esos permisos alcanzaban para acceder directamente a Pods de otros clientes y robar datos sensibles como modelos, datasets y código
• También podían interferir con Pods de clientes, contaminar datos de IA y manipular inferencias de modelos
• Con los mismos permisos también podían consultar en texto plano secretos de clientes que iban más allá del alcance de SAP AI Core
  • La cuenta de AI Core del equipo de investigación tenía secretos de una cuenta de AWS para acceso a datos en S3
  • Había secretos de una cuenta de SAP HANA para acceso a Data Lake
  • Había secretos de una cuenta de Docker Hub para hacer pull de imágenes
• En la misma consulta también se identificó una clave de acceso de SAP para Google Container Registry llamada sap-docker-registry-secret, y esa clave otorgaba permisos tanto de lectura como de escritura

Alcance de acceso confirmado e impacto potencial

• Las acciones posibles mediante la cadena de vulnerabilidades eran las siguientes
  • Leer y modificar imágenes Docker del Registry interno de contenedores de SAP
  • Leer y modificar imágenes Docker de SAP en Google Container Registry
  • Leer y modificar artefactos del servidor Artifactory interno de SAP
  • Obtener permisos cluster-admin en el clúster Kubernetes de SAP AI Core
  • Acceder a credenciales cloud de clientes y a resultados privados de IA
• Un atacante potencial podía acceder a datos de clientes y contaminar artefactos internos, extendiendo el impacto a servicios relacionados y a entornos de otros clientes
• Todas las vulnerabilidades fueron reportadas al equipo de seguridad de SAP y corregidas por SAP, que las reconoció en su página de créditos para investigadores de seguridad
• Los datos de clientes no fueron comprometidos

Problemas revelados desde la perspectiva defensiva

• La principal línea de defensa era una arquitectura en la que Istio bloqueaba el acceso a la red interna, pero una vez superada esa barrera, varios activos internos no requerían autenticación adicional
• Al tratar la red interna como una zona confiable, una sola evasión escaló hasta una toma del servicio
• Si los servicios internos hubieran estado reforzados, el impacto del ataque podría haberse reducido de una toma completa del servicio a un incidente de seguridad menor
• Los servicios administrados basados en Kubernetes pueden caer en trampas de aislamiento de tenants, porque el plano de control y la computación de clientes quedan conectados lógicamente mediante APIs, identidades, computación compartida y segmentación de red basada en software
• Como el entrenamiento de IA requiere por naturaleza ejecutar código arbitrario, se necesitan guardrails para separar correctamente el código no confiable de los activos internos y de otros tenants

Cronograma de divulgación

• 25 de enero de 2024: Wiz Research reportó los hallazgos de seguridad a SAP
• 27 de enero de 2024: SAP respondió y asignó un número de caso
• 16 de febrero de 2024: SAP corrigió la primera vulnerabilidad y rotó los secretos relacionados
• 28 de febrero de 2024: Wiz Research eludió el parche con 2 vulnerabilidades nuevas y las reportó a SAP
• 15 de mayo de 2024: SAP desplegó correcciones para todas las vulnerabilidades reportadas
• 17 de julio de 2024: divulgación pública

[GN⁺]

Opiniones en Hacker News

• Entiendo que sea un producto de IA, pero aquí la vulnerabilidad está en la configuración de k8s.
  No tiene mucho que ver con el producto de IA en sí, ni con el entrenamiento de IA, machine learning o IA generativa; se parece más a una seguridad de plataforma en la nube deficiente.

  • Incluso podría ser peor. Una empresa tan grande como SAP, que maneja mucha información importante, arruinó aspectos básicos de seguridad en la nube; no suena a que hayan hecho mal algo novedoso, sino a un error común.
  • El artículo no dice que el problema sea el producto en sí. Más bien explica bien que es un problema de aislamiento de modelos de entrenamiento de IA.
    Que “un atacante pudiera ejecutar un modelo de IA malicioso y procedimientos de entrenamiento” es la causa raíz, y eso en esencia es ejecución de código.
    Entiendo que se investigó porque los productos de IA se están masificando y hay que tener cuidado con esa infraestructura.
  • La marca que se vende debe hacerse responsable.
    Aplicar seguridad, saber que la seguridad es necesaria, probarla o no lanzar hasta que sea segura son todas cosas que esa marca debe hacer como vendedora.

• Me gustaría que SAP hiciera una retrospectiva fuerte sobre por qué la investigación de Wiz no fue bloqueada antes de llegar a permisos de administrador de todo el clúster.
  Quisiera saber si SAP recibió alertas sobre esta actividad y si la investigó correctamente. También me pregunto si SAP está sujeta a regulaciones que le exijan tener suficientes mecanismos de alerta ante actividad de red sospechosa, y si esta investigación podría ser evidencia de que no los cumplió.

  • Reglas y regulaciones claramente hay. Basta ver la página de certificaciones: https://www.sap.com/about/trust-center/certification-complia...
    El problema es si realmente las cumplen o si solo están en una carpeta guardada en un estante.
  • Normalmente, un investigador de seguridad debe contactar al objetivo antes de profundizar más en el sistema y pedir permiso para continuar.
    Los programas de bug bounty también suelen exigir estas reglas dentro del alcance definido. Como el investigador pertenece a una empresa de seguridad, esperaría que aquí también haya sido así.
    Los investigadores suelen indicar en el artículo en qué punto pidieron autorización adicional, aunque no siempre lo hacen.
  • Si realmente no lo detectaron, me pregunto cómo saben que no se comprometieron datos de clientes.
  • A SAP le falta capacidad de seguridad en la nube. Hay una larga lista de problemas de seguridad en los servicios cloud de SAP, y eso solo contando los conocidos.
  • Sería bueno que saliera un artículo que muestre cómo detectar este tipo de cosas en IA.

• Me impacta que hubiera una instancia de tiller corriendo. Está sin soporte desde 2020: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Te horrorizarías si supieras cuánto software anterior a 2020, e incluso anterior a 2010, sigue corriendo en entornos de producción.
    Aquí se trata de una gran empresa y hay una migración algo compleja para salir de tiller, pero aun sin esas circunstancias atenuantes es fácil encontrar software antiguo.
  • Por experiencia, “sin soporte” a menudo se interpreta como “todavía no lo quitaron, así que se puede seguir usando”, lo que a veces resulta bastante desalentador.
  • Microsoft Dynamics tiene una cantidad enorme de código legado viejo, inseguro y sin parches.

• Esto es realmente malo. ¿Operaban un único clúster de K8s y esperaban garantías sólidas de multi-tenancy?
  Los principales proveedores cloud usan límites de máquinas virtuales y clústeres K8s separados entre clientes. Microsoft también sufrió algo parecido hace unos años en uno de sus productos de funciones, donde esperaba que K8s fuera el principal límite de seguridad.

  • Puede que se me haya pasado dónde el artículo dice que esperaban garantías sólidas, pero ¿dónde se ve esa expectativa?
    Por ejemplo, en una situación en la que se ejecuta código arbitrario, como entrenamiento de modelos, no tengo claro qué papel cumple el multi-tenancy de K8s.
    A mi entender, el principal problema fue que, una vez detrás de Istio como proxy/firewall, confiaban en toda la comunicación de la red interna. Aunque quizá sea que no entiendo lo suficiente los clústeres k8s.
  • El multi-tenancy fuerte dentro del mismo clúster lógico de K8s es difícil de lograr en la práctica.
    Es un objetivo en movimiento, así que el plan de hacerlo seguro con admission controllers tampoco es muy bueno.
    Si quieres considerar multi-tenancy fuerte asumiendo tenants hostiles, deberías empezar mirando cosas como VirtualClusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Y eso solo habla del plano de control, ni siquiera toca el plano de datos.
    Ni siquiera sé qué tan seguro es con esa capa adicional. Incluso en el ámbito de las máquinas virtuales, durante años hubo vulnerabilidades absurdas de escape de VM.
  • K8S correctamente configurado está diseñado literalmente para multi-tenancy.
    Tener un clúster separado por cliente es absurdamente caro y además malo para el planeta. Podría tener sentido en un producto premium donde la seguridad sea la prioridad máxima, pero clústeres separados por cliente básicamente equivalen a quemar dinero.

• Creo que las empresas que se infiltran en redes sin permiso para encontrar vulnerabilidades y generar contenido de blog deberían ser procesadas.
  Este artículo en particular suena como un texto ofensivo apenas disfrazado de divulgación de vulnerabilidades. Lo de “agradecieron la colaboración” también suena un poco a extorsión.

  • Eso puede reformularse como: “las empresas que recopilan datos sensibles de usuarios de forma descuidada y los almacenan de manera insegura no deberían ser examinadas de cerca, y se les debería permitir seguir exponiendo datos de usuarios inocentes a ciberdelincuentes maliciosos”.
    Visto desde ese ángulo, ¿no se ve bastante diferente?
  • Intentar hackear una gran empresa sin invitación es un delito y normalmente sería algo por lo que te procesarían seriamente.
    Pero, como suele mostrar la práctica legal, termina aplicando aquello de que “si tienes miles de millones de dólares, la ley ya no se aplica”.

• ¿Alguien ha usado Wiz?
  Puede que sea el cohete más rápido entre las empresas de software empresarial. En 1.5 años llegó a 100 millones de dólares de ARR, y al final del tercer año alcanzó 350 millones de dólares
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Lo usamos y estamos muy satisfechos. Incluso dejando de lado el aspecto de seguridad, es la mejor herramienta que he probado para hacer bien la gestión de activos multicloud
    Con la función de grafo, si quieres puedes consultar prácticamente cualquier cosa en todas las cuentas
  • Google también está intentando adquirirla por 23 mil millones de dólares

• Me alegra haber convencido a la gente de la empresa de ejecutar la prueba de penetración anual del producto en el entorno de producción, e incluir toda la infraestructura de producción dentro del alcance
  El foco puede estar en un producto o sistema específico, pero todo está dentro del alcance. La primera prueba está en curso y todavía nadie está gritando, así que espero que salga bien

  • Cuando dices anual, ¿puedo entender que no hacen pruebas de penetración internas periódicas?
    También me pregunto si puedes recomendar una empresa de pentesting que haga un trabajo serio, más allá de pasar por encima con Metasploit

• Si leí bien, ¿los datos de cuenta de los clientes se exponen al mismo cliente? Solo algunas partes de los logs parecen ser la excepción

  • No solo algunas partes de los logs: también quedaron expuestos datos de entrenamiento y código de otros clientes, e incluso el repositorio interno de imágenes Docker de SAP. ¡Y con permisos de lectura y escritura!

• Si eres investigador de seguridad, pensaría que sabes que pixelar texto para ocultarlo no es una buena opción
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Todos los bugs reportados ya fueron parcheados, y probablemente también se rotaron los secretos que pudieron haber sido comprometidos
    Independientemente de si el desenfoque o el pixelado son efectivos, en la práctica parecen innecesarios. Los datos ocultos parecen ser nombres de host locales y partes de hashes de imágenes
  • A mi parecer no era pixelado, sino desenfoque
    Edit: viéndolo de nuevo, parece que en algunas partes usaron desenfoque y en otras pixelado