Google Cloud ha abordado una falla de seguridad de gravedad media en su plataforma que podría ser abusada por un atacante que ya tiene acceso a un clúster de Kubernetes para escalar sus privilegios.
«Un atacante que ha comprometido la Poco fluido El contenedor de registro podría combinar ese acceso con altos privilegios requeridos por Malla de servicios Anthos (en los clústeres que lo han habilitado) para escalar privilegios en el clúster», la empresa dicho como parte de un aviso publicado el 14 de diciembre de 2023.
La Unidad 42 de Palo Alto Networks, que descubrió e informó la deficiencia, dijo que los adversarios podrían utilizarla como arma para llevar a cabo «robo de datos, desplegar cápsulas maliciosas e interrumpir las operaciones del clúster».
De USUARIO a ADMIN: aprenda cómo los piratas informáticos obtienen el control total
Descubra las tácticas secretas que utilizan los piratas informáticos para convertirse en administradores, cómo detectarlos y bloquearlos antes de que sea demasiado tarde. Regístrese hoy para nuestro seminario web.
No hay evidencia de que el problema haya sido explotado en la naturaleza. Se ha 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-asamb.8
- 1.18.6-ensam.2
- 1.19.5-ensam.4
Un requisito previo clave para explotar con éxito la vulnerabilidad depende de que un atacante ya haya comprometido un contenedor FluentBit mediante otros métodos de acceso inicial, como mediante una falla de ejecución remota de código.
«GKE utiliza Fluent Bit para procesar registros de cargas de trabajo que se ejecutan en clústeres», explicó Google. «Fluent Bit en GKE también se configuró para recopilar registros para cargas de trabajo de Cloud Run. El montaje de volumen configurado para recopilar esos registros le dio a Fluent Bit acceso a los tokens de la cuenta de servicio de Kubernetes para otros Pods que se ejecutan en el nodo».
Esto significaba que un actor de amenazas podría usar este acceso para obtener acceso privilegiado a un clúster de Kubernetes que tenga ASM habilitado y luego usar el token de cuenta de servicio de ASM para escalar sus privilegios mediante la creación de un nuevo pod con privilegios de administrador de clúster.
«El controlador de agregación de roles de clúster (CRAC) la cuenta de servicio es probablemente la principal candidata, ya que puede agregar permisos arbitrarios a las funciones del clúster existente», afirma el investigador de seguridad Shaul Ben Hai. dicho. «El atacante puede actualizar la función del clúster vinculada a CRAC para poseer todos los privilegios».
A modo de correcciones, Google eliminó el acceso de Fluent Bit a los tokens de la cuenta de servicio y rediseñó la funcionalidad de ASM para eliminar el control de acceso excesivo basado en roles (RBAC) permisos.
«Los proveedores de nube crean automáticamente módulos de sistema cuando se lanza su clúster», concluyó Ben Hai. «Están integrados en su infraestructura de Kubernetes, al igual que los pods complementarios que se crean cuando habilita una función».
«Esto se debe a que los proveedores de aplicaciones o de nube generalmente los crean y administran, y el usuario no tiene control sobre su configuración o permisos. Esto también puede ser extremadamente riesgoso ya que estos pods se ejecutan con privilegios elevados».
