GKE también admite el acceso anónimo, y las solicitudes realizadas a la API de Kubernetes sin presentar un certificado de cliente o un token de portador autorizado se ejecutarán automáticamente como el usuario «sistema:anónimo» y el rol de grupo «sistema:no autenticado». Sin embargo, si se presenta un token o certificado, la solicitud de API se identificará como la identidad correspondiente con sus roles definidos pero también con los roles asignados al sistema: grupo autenticado. De forma predeterminada, este grupo proporciona acceso a algunas URL de descubrimiento básicas que no exponen información confidencial, pero los administradores podrían ampliar los permisos del grupo sin darse cuenta de las implicaciones. «Los administradores podrían pensar que el sistema vinculante: autenticado para un nuevo rol, para aliviar la carga administrativa de decenas o cientos de usuarios, es completamente seguro», dijeron los investigadores. «Aunque esto definitivamente tiene sentido a primera vista, en realidad podría convertirse en un escenario de pesadilla».
Para ejecutar solicitudes autenticadas a un clúster de GKE, todo lo que un usuario debe hacer es usar OAuth 2.0 Playground de Google y autorizar su cuenta para la API de Kubernetes Engine v1. Al completar el proceso de autorización del grupo de juego, cualquier usuario con una cuenta de Google puede obtener un código de autorización que puede canjear por un token de acceso en la misma página. Este token de acceso se puede usar para enviar solicitudes a cualquier clúster de GKE e identificarse correctamente como sistema: autenticado, que incluye el rol sistema: usuario básico.
El sistema:basicuser permite a los usuarios enumerar todos los permisos que tienen actualmente, incluidos los heredados del sistema:grupo autenticado consultando el objeto SelfSubjectRulesReview. Esto proporciona una forma sencilla para que los atacantes investiguen si el administrador de un clúster ha otorgado permisos excesivos al sistema: autenticado.
Los investigadores de Orca demostraron el impacto con un ejemplo en el que el administrador decidió asociar cualquier usuario autenticado con la capacidad de leer todos los recursos en todos los apiGroups del clúster. Esto es «algo que puede resultar algo útil cuando existe una gobernanza real en torno a los usuarios que pueden autenticarse en el clúster, pero no en GKE», dijeron. «Nuestro atacante ahora puede, en la configuración actual, enumerar todos los secretos del clúster y, por lo tanto, lograr un compromiso real del clúster, adquiriendo todas las contraseñas del clúster, incluidos los tokens de cuentas de servicio».
Impacto en el mundo real de los permisos erróneos para Google Kubernetes Engine
Para ver qué tan común era esta mala configuración, los investigadores probaron todos los clústeres de GKE en uno de los rangos de IP de GCP. En una semana, pudieron escanear 250.000 clústeres activos de GKE e identificaron 1.300 clústeres (0,5%) que eran potencialmente vulnerables. El número puede parecer pequeño, pero los investigadores estiman que los 250.000 clústeres escaneados representan solo alrededor del 2 % de todos los clústeres disponibles en GKE, por lo que extrapolar una tasa de configuración incorrecta del 0,5 % daría como resultado un número muy grande de clústeres potencialmente vulnerables.
Por supuesto, no todos se verían afectados de la misma manera. Por ejemplo, solo 108 de los 1300 permitieron acceso de administrador de clúster, lista de secretos en todo el clúster o acciones de escritura/eliminación en todo el clúster. El resto permitía permisos de lectura sobre recursos nativos de Kubernetes, pero también recursos personalizados, que pueden tener varios niveles de impacto dependiendo de cuáles sean esos recursos. Orca notificó a los propietarios del clúster que pudo identificar e informó del problema a Google.
Mitigar permisos peligrosos en Google Kubernetes Engine
Según Orca, Google respondió que este es el comportamiento previsto y que depende de las organizaciones asegurarse de no cometer este error. De acuerdo con la modelo de responsabilidad compartida, los usuarios son responsables de configurar los controles de acceso. Sin embargo, Google bloqueó la vinculación del sistema: grupo autenticado a la función de administrador del clúster en las versiones 1.28 y superiores de GKE y planea notificar a los usuarios sobre esta posible configuración incorrecta.
Se recomienda encarecidamente a las organizaciones que actualicen a esta versión de GKE y practiquen los principios de privilegio mínimo al asignar permisos, lo que dicta que los permisos deben ser lo más detallados posible para cada usuario según su función en el sistema y, por lo tanto, no deben asignarse de forma masiva a través de grupos como sistema: autenticado.
«Google tiene razón», dijeron los investigadores. “Las organizaciones deben asumir la responsabilidad y no implementar sus activos y permisos de una manera que conlleve riesgos y vulnerabilidades de seguridad. Sin embargo, el alcance del sistema: grupo autenticado es un concepto ampliamente mal entendido con graves consecuencias, que se ha verificado como viable y fructífero. […] Esto no es muy diferente del fenómeno de explotación del depósito abierto S3, que hizo que Amazon tomara medidas, aunque llevó años. La única diferencia es que en este momento no tenemos ningún registro público de un ataque a gran escala utilizando este vector de ataque, pero lo más probable es que sea sólo cuestión de tiempo”.
