¿Cómo hackear Google Kubernetes Engine (GKE)? Protección contra amenazas de GKE

Una investigación reciente realizada por la Unidad 42 de Palo Alto Networks ha descubierto una cadena de escalada de privilegios duales en Google Kubernetes Engine (GKE). Esta vulnerabilidad, que surge de configuraciones específicas en el agente de registro FluentBit y Anthos Service Mesh (ASM) de GKE, presenta un riesgo de seguridad significativo, que podría permitir a los atacantes acceso no autorizado a los clústeres de Kubernetes .

Descripción general de Kubernetes y GKE: Kubernetes, la plataforma de contenedores de código abierto más adoptada, se utiliza para la implementación y administración de aplicaciones. GKE, Kubernetes Engine de Google, ofrece funciones y capacidades adicionales, lo que mejora la implementación y la gestión de los clústeres de Kubernetes. Sin embargo, la complejidad de los entornos de Kubernetes a menudo los hace susceptibles a violaciones de seguridad debido a una mala configuración y privilegios excesivos.

PROBLEMAS EN FLUENTBIT Y ANTHOS SERVICE MESH:

• FluentBit : la configuración predeterminada de FluentBit, un procesador y reenviador de registros liviano, incluye un montaje de volumen que proporciona acceso innecesario al directorio del pod, incluidos los tokens de cuenta de servicio proyectados.
• Anthos Service Mesh (ASM) : el DaemonSet de la interfaz de red de contenedores (CNI) de ASM conserva permisos excesivos después de la instalación, que pueden explotarse para crear un nuevo pod con privilegios elevados.

VULNERABILIDAD DE FLUENTBIT

La vulnerabilidad descrita en el contenedor FluentBit dentro de un clúster de Kubernetes es un problema importante. Esta vulnerabilidad surge de la forma en que FluentBit está configurado para acceder a los volúmenes dentro del clúster. Analicemos esta vulnerabilidad y sus implicaciones:

COMPRENDER LA VULNERABILIDAD

1. Configuración de montaje de volumen de FluentBit :
   • Mala configuración : FluentBit está montado con acceso al /var/lib/kubelet/podsvolumen. Este directorio contiene subdirectorios para cada pod que se ejecuta en un nodo.
   • Acceso a datos confidenciales : dentro del directorio de cada pod, hay un kube-api-accessvolumen que almacena tokens de cuenta de servicio proyectados. Estos tokens se utilizan para autenticarse con la API de Kubernetes y son muy confidenciales.
2. Explotación de la mala configuración :
   • Compromiso de FluentBit : si un atacante obtiene acceso al contenedor de FluentBit, puede aprovechar esta configuración errónea.
   • Acceso a tokens : el atacante puede acceder a cualquier token de cuenta de servicio de los pods en el mismo nodo.
   • Suplantación y acceso no autorizado : al utilizar estos tokens, el atacante puede hacerse pasar por pods con distintos niveles de privilegios, obteniendo potencialmente acceso no autorizado al servidor API de Kubernetes.
3. Alcance del ataque :
   • Mapeo del clúster : el atacante podría enumerar todos los pods en ejecución en el clúster ( get podscomando), lo que le permitiría mapear todo el clúster.
   • Potencial de escalada de privilegios : dependiendo de los permisos asociados con los tokens comprometidos, el atacante podría escalar sus privilegios dentro del clúster.
   • Acciones dañinas : el atacante podría realizar diversas acciones dañinas, como robo de datos, interrupción del servicio o explotación adicional de los recursos del clúster.

EL PAPEL DEL CONTENEDOR SIDECAR

• Funcionalidad del contenedor sidecar : en una configuración típica de Kubernetes, se utiliza un contenedor sidecar como FluentBit para la recopilación de registros. Opera dentro del contexto de su pod, recopilando, analizando y reenviando registros desde el contenedor principal de la aplicación.
• No se necesita acceso directo a la API : el contenedor sidecar generalmente no requiere acceso directo al servidor API de Kubernetes. Utiliza la infraestructura de Kubernetes para acceder a archivos de registro y metadatos de tiempo de ejecución del contenedor.

Cómo hackear pods de Kubernetes y ejecutar código malicioso de forma remota

VULNERABILIDADDE LA MALLA DE SERVICIO DE ANTHOS (ASM)

Imagine que está administrando un clúster de Kubernetes que utiliza Anthos Service Mesh (ASM) con el complemento CNI de Istio. El clúster alberga varias aplicaciones críticas para su organización.

CONFIGURACIÓN INICIAL

• Instalación de ASM : durante la configuración de ASM, el DaemonSet Istio-cni-node se instala en el clúster.
• Función de DaemonSet : este DaemonSet es responsable de instalar el complemento Istio CNI en cada nodo. También tiene un modo de reparación para manejar pods mal configurados.

LA FALLA

• Permisos excesivos : después de la instalación, Istio-cni-node DaemonSet conserva permisos de alto nivel, que ya no son necesarios para su funcionamiento diario. Aquí es donde reside el defecto.

EJEMPLO DE EXPLOTACIÓN

1. Entrada del atacante : un atacante, que ya tiene acceso limitado al clúster (tal vez como un usuario con pocos privilegios), descubre los permisos excesivos del DaemonSet de Istio-cni-node.
2. Creando un Pod Poderoso :
   • El atacante crea un nuevo pod en el clúster y le asigna los mismos permisos que el DaemonSet de Istio-cni-node. Esto es posible debido a los permisos excesivos que aún posee DaemonSet.
   • Esta nueva cápsula, que podemos llamar una “cápsula poderosa”, ahora tiene capacidades mucho más allá de las que debería tener una cápsula normal.
3. Uso indebido de permisos :
   • El atacante utiliza el potente pod para realizar acciones que normalmente están restringidas, como acceder a datos confidenciales o modificar configuraciones críticas.
   • El pod también podría manipular otros pods o servicios, interrumpir operaciones o incluso propagarse a otros nodos, intensificando el impacto del ataque.
4. Escalada de privilegios :
   • Aprovechando las capacidades del potente pod, el atacante aumenta sus privilegios a los de administrador de clúster.
   • Con acceso a nivel de administrador, obtienen control total sobre el clúster de Kubernetes, lo que genera una grave violación de seguridad.

LA CADENA DE ESCALADA DE PRIVILEGIOS

La combinación de estos dos problemas se puede aprovechar en un ataque de segunda etapa para obtener el control total de un clúster de Kubernetes. El ataque implica explotar los permisos de FluentBit para leer tokens de cuentas de servicio proyectados y luego aprovechar los permisos posteriores a la instalación de ASM para escalar privilegios.

Analicemos esta cadena de ataques para comprender cómo un atacante podría escalar privilegios para convertirse en administrador del clúster:

DESGLOSE PASO A PASO DE LA CADENA DE ATAQUE

1. ACCESO INICIAL A TRAVÉS DEL CONTENEDOR FLUENTBIT

• Requisito previo : el atacante necesita que la función Anthos Service Mesh esté habilitada en el clúster de Kubernetes.
• Explotación de FluentBit : el atacante obtiene el control del contenedor FluentBit. FluentBit, al ser una herramienta de registro, a menudo tiene amplio acceso dentro de un clúster para fines de recopilación de registros.
• Montaje de un volumen sensible : el atacante aprovecha FluentBit para montar el /var/lib/kubelet/podsvolumen que contiene el kube-api-access-<random-suffix>directorio. Este directorio contiene tokens de todos los pods de un nodo.

2. RECOLECCIÓN DE TOKENS EN TODO EL CLÚSTER

• Aprovechando la naturaleza DaemonSet de FluentBit : dado que FluentBit se ejecuta como un DaemonSet (un pod en cada nodo), el atacante replica el compromiso inicial en cada nodo.
• Mapeo del clúster : al hacerlo, el atacante puede acceder a tokens montados de otros pods en el clúster.
• Apuntar al token del contenedor Istio-Installer : entre estos tokens, el atacante busca específicamente el token del contenedor Istio-Installer.

3. EXPLOTACIÓN DE LOS PERMISOS DE ASM CNI DAEMONSET

• Creación de un nuevo pod : utilizando los permisos retenidos de ASM CNI DaemonSet, el atacante crea un nuevo pod en el kube-systemespacio de nombres.
• Dirigirse a una cuenta de servicio potente : el objetivo es asociar este pod con una cuenta de servicio que tenga amplios privilegios.

4. ELEGIR LA CUENTA DE SERVICIO CRAC

• Selección de CRAC : la cuenta de servicio ClusterRoleAggregationController (CRAC) es un objetivo principal debido a su capacidad para agregar permisos a las funciones del clúster.
• Actualización de la función del clúster : el atacante modifica la función del clúster vinculada a la cuenta de servicio CRAC para obtener privilegios completos.

5. PASOS FINALES PARA OBTENER ACCESO DE ADMINISTRADOR DEL CLÚSTER

• Montaje del token CRAC : el token de la cuenta de servicio CRAC se monta en el pod recién creado.
• Explotar FluentBit nuevamente : el atacante luego explota la mala configuración de FluentBit para extraer el token CRAC de su módulo.
• Uso del token CRAC : con el token CRAC, que tiene permisos de administrador del clúster, el atacante puede operar con control total sobre el clúster de Kubernetes.

RESPUESTA Y SOLUCIONES DE GOOGLE:

Google solucionó estos problemas de configuración el 14 de diciembre de 2023 con el lanzamiento de GCP-2023-047. Las correcciones implicaron eliminar el montaje de volumen /var/lib/kubelet/pod del pod Fluent Bit y modificar ClusterRole de ASM para eliminar permisos RBAC excesivos.

CORRECCIONES Y MITIGACIONES IMPLEMENTADAS

1. ACTUALIZACIÓN DE LA CONFIGURACIÓN DE FLUENTBIT

• Problema : Inicialmente, FluentBit tenía acceso excesivo debido a un montaje del volumen hostPath del /var/lib/kubelet/podsdirectorio, que incluía acceso a tokens confidenciales de cuentas de servicio.
• Solución : el equipo de seguridad de Google restringió el acceso de FluentBit y eliminó el montaje de volumen innecesario. Este cambio garantiza que FluentBit solo pueda acceder a los registros que necesita para su funcionamiento, lo que reduce significativamente el riesgo de comprometer el token.

2. AJUSTE DE PERMISOS DE ANTHOS SERVICE MESH (ASM)

• Problema : CNI DaemonSet de ASM tenía altos privilegios, como se identifica en un informe interno.
• Acción tomada : antes del informe externo, Google ya estaba trabajando para reducir estos permisos.
• Solución : Google modificó el ClusterRole de ASM y reestructuró algunas funcionalidades para eliminar permisos RBAC innecesarios. Este cambio aborda los permisos excesivos que anteriormente permitían una posible explotación.

IMPACTO DE LAS CORRECCIONES

• Refuerzo de la seguridad : estas actualizaciones mejoran significativamente la seguridad de FluentBit y ASM dentro de los clústeres de Kubernetes, mitigando las vulnerabilidades específicas y fortaleciendo la postura de seguridad general contra amenazas similares.
• Prevención de la escalada de privilegios : al rectificar estos problemas, Google ha cerrado efectivamente el vector de ataque que permitía la escalada a privilegios de administrador del clúster.
• Gestión proactiva de vulnerabilidades : la respuesta de Google, especialmente su trabajo preventivo sobre los permisos de ASM, destaca la importancia de las evaluaciones de seguridad continuas y la gestión proactiva de vulnerabilidades.

IMPLICACIONES MÁS AMPLIAS PARA LA SEGURIDAD DE KUBERNETES

• Monitoreo y auditoría continuos : los entornos de Kubernetes deben monitorearse y auditarse continuamente para detectar configuraciones incorrectas y permisos excesivos, especialmente para componentes con acceso de amplio alcance como DaemonSets.
• Principio de privilegio mínimo : este principio debe aplicarse rigurosamente a todos los componentes de Kubernetes, garantizando que cada componente tenga solo los permisos necesarios para su función.
• Parches y actualizaciones inmediatas : la actualización periódica de Kubernetes y sus componentes asociados es crucial para mantener la seguridad, ya que las vulnerabilidades se pueden descubrir y explotar rápidamente.

Este descubrimiento resalta la importancia de prácticas de seguridad vigilantes en entornos de nube. Kubernetes, aunque potente, puede ser vulnerable a ataques sofisticados debido a configuraciones erróneas y privilegios excesivos en los módulos del sistema. La respuesta proactiva de Google y el análisis detallado de Palo Alto Networks subrayan la necesidad continua de medidas de seguridad sólidas en las infraestructuras de la nube.

El cargo ¿Cómo hackear Google Kubernetes Engine (GKE)? Protección contra amenazas de GKE apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente