Google Cloud soluciona vulnerabilidad de escalada de privilegios que afecta al servicio Kubernetes

Google Cloud ha solucionado una vulnerabilidad de seguridad de severidad media en su plataforma que podía ser aprovechada por un atacante que ya tiene acceso a un clúster de Kubernetes para escalar sus privilegios.

«Puede que un atacante que haya comprometido el contenedor de registro Fluent Bit combine ese acceso con los altos privilegios requeridos por Anthos Service Mesh (en clústeres que lo hayan habilitado) para escalar privilegios en el clúster», dijo la empresa como parte de un aviso publicado el 14 de diciembre de 2023.

Palo Alto Networks Unit 42, que descubrió y reportó la falla, dijo que los adversarios podrían utilizarla para llevar a cabo «el robo de datos, desplegar pods maliciosos y perturbar las operaciones del clúster».

No hay evidencia de que el problema haya sido explotado en la naturaleza. Ha sido solucionado en las siguientes versiones de Google Kubernetes Engine (GKE) y Anthos Service Mesh (ASM):

1.25.16-gke.1020000

1.26.10-gke.1235000

1.27.7-gke.1293000

1.28.4-gke.1083000

1.17.8-asm.8

1.18.6-asm.2

1.19.5-asm.4

Un requisito clave para explotar con éxito la vulnerabilidad depende de que un atacante ya haya comprometido un contenedor de FluentBit por otros métodos de acceso inicial, como a través de una falla de ejecución remota de código.

«GKE utiliza Fluent Bit para procesar los registros de cargas de trabajo que se ejecutan en clústeres», explicó Google. «Fluent Bit en GKE también se configuró para recopilar registros de cargas de trabajo de Cloud Run. El montaje de volumen configurado para recopilar esos registros daba a Fluent Bit acceso a tokens de cuenta de servicio de Kubernetes para otros Pods que se ejecutan en el nodo».

Esto significaba que un actor amenazador podría utilizar este acceso para obtener un acceso privilegiado a un clúster de Kubernetes que tenga ASM habilitado y luego posteriormente usar el token de cuenta de servicio de ASM para escalar sus privilegios creando un nuevo pod con privilegios de administrador de clúster.

«La cuenta de servicio de control de agregación de roles de clúster (CRAC) es probablemente el candidato principal, ya que puede agregar permisos arbitrarios a roles de clúster existentes», dijo el investigador de seguridad Shaul Ben Hai. «El atacante puede actualizar el rol del clúster vinculado a CRAC para poseer todos los privilegios».

Como solución, Google ha eliminado el acceso de Fluent Bit a los tokens de cuenta de servicio y ha re-arquitecturado la funcionalidad de ASM para eliminar los permisos excesivos de control de acceso basados en roles (RBAC).

«Los proveedores de nube crean automáticamente pods de sistema cuando se lanza su clúster», concluyó Ben Hai. «Están construidos en su infraestructura de Kubernetes, al igual que los pods de complementos que se crean cuando se habilita una función».

«Esto se debe a que los proveedores de nube o de aplicaciones suelen crearlos y gestionarlos, y el usuario no tiene control sobre su configuración o permisos. Esto también puede ser extremadamente arriesgado ya que estos pods se ejecutan con privilegios elevados».