Google Cloud ha parcheado una vulnerabilidad que pudo haber permitido malicioso actores con acceso a un clúster de Kubernetes para elevar sus privilegios y causar estragos.
«Un atacante que haya comprometido el contenedor de registro de Fluent Bit podría combinar ese acceso con altos privilegios requeridos por Anthos Service Mesh (en los clústeres que lo han habilitado) para escalar los privilegios en el clúster», dijo la compañía en un aviso.
«Los problemas con Fluent Bit y Anthos Service Mesh se han mitigado y ahora hay soluciones disponibles. Estas vulnerabilidades no se pueden explotar por sí solas en GKE y requieren un compromiso inicial».
Robo de datos
Google también afirma que no encontró evidencia de que las vulnerabilidades estuvieran explotadas en la naturaleza.
En cuanto a las correcciones, estas son las versiones de Google Kubernetes Engine (GKE) y Anthos Service Mesh (ASM) que están protegidas:
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
La vulnerabilidad fue descubierta por primera vez por la Unidad 42, la ciberseguridad brazo de Palo Alto Networks, TheHackerNoticias informes. En su informe, la Unidad 42 dice que las fallas podrían usarse para el robo de datos, el despliegue de módulos maliciosos y la interrupción de las operaciones del clúster. Sin embargo, para que funcione, el atacante debe tener un contenedor Fluent Bit comprometido de antemano.
«GKE utiliza Fluent Bit para procesar registros de cargas de trabajo que se ejecutan en clústeres», explica Google con más detalle. «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».
En otras palabras, un pirata informático podría usar un clúster de Kubernetes con ASM habilitado y luego usar el token de la cuenta de servicio de ASM para crear un nuevo pod con privilegios de administrador del clúster, escalando efectivamente sus privilegios al nivel más alto.
«La cuenta de servicio clusterrole-aggregation-controller (CRAC) es probablemente la principal candidata, ya que puede agregar permisos arbitrarios a las funciones de cluster existentes», dijo el investigador de seguridad Shaul Ben Hai. «El atacante puede actualizar la función del clúster vinculada a CRAC para poseer todos los privilegios».
