Se ha identificado una vulnerabilidad de seguridad crítica en la cápsula de Kubernetes V0.10.3 y las versiones anteriores, lo que permite a los usuarios de inquilinos autenticados inyectar etiquetas arbitrarias en espacios de nombres de sistemas y omitir los controles de aislamiento multiinquilino.
La vulnerabilidad, rastreada como GHSA-FCPM-6MXQ-M5VV, fue revelada por el investigador de seguridad Oliverbaehler y representa una amenaza significativa para las organizaciones que dependen de la cápsula para Kubernetes múltiples tensiones.
Control de llave
1. Cápsula V0.10.3 permite a los usuarios de los inquilinos inyectar etiquetas en espacios de nombres del sistema.
2. La inyección de etiquetas permite el acceso no autorizado de recursos de inquilino cruzado a través de selectores TenantResource.
3. Actualice inmediatamente para evitar la escalada de privilegios.
Vulnerabilidad de inyección del espacio de nombres
La falla reside en la lógica de Validación de Names Validation dentro de PKG/Webhook/Namespace/Validation/Patch. Go: 60-77, donde una verificación condicional crítica solo valida la propiedad del inquilino cuando un espacio de nombres ya contiene una etiqueta de inquilino.
La estructura de código problemático revela el problema central:
Esta vulnerabilidad refleja el patrón de ataque de CVE-2024-39690, pero emplea la inyección de etiquetas en lugar de la manipulación del propietario.
Los espacios de nombres del sistema como Kube-System, predeterminado y cápsula-System carecen de la etiqueta Capsule.clastix.io/Tenant de forma predeterminada, haciéndolos susceptibles a la inyección de etiquetas no autorizada por usuarios de inquilinos autenticados, lee el consultivo.
El proceso de explotación sigue un enfoque sistemático donde los atacantes pueden inyectar etiquetas maliciosas en espacios de nombres de sistemas sin protección utilizando comandos estándar de parche Kubectl:
Posteriormente, los atacantes pueden crear objetos de TenantResource maliciosos que aprovechen los selectores del espacio de nombres para dirigirse a estas etiquetas inyectadas, obteniendo efectivamente el acceso a los recursos del espacio de nombres del sistema.
La cadena de ataque progresa de la inyección de etiquetas (controlada por el usuario) → Selector de espacio de nombres (coincidencia del sistema) → TenantResource/cuota (Política de autenticación) → Acceso a recursos de inquilino cruzado, sin pasar por los límites de seguridad previstos de la cápsula.
Mitigaciones
La vulnerabilidad afecta a los grupos de Kubernetes múltiples con Capsule V0.10.3 y versiones potencialmente más tempranas, lo que plantea riesgos significativos para las organizaciones y los proveedores de servicios en la nube que ofrecen plataformas de Kubernetes como servicio.
Las implicaciones de seguridad incluyen bypass de aislamiento de múltiples inquilinos, escalada de privilegios, exfiltración de datos potenciales de espacios de nombres del sistema, la elección de las cuotas de recursos y las violaciones de políticas.
Los atacantes pueden explotar esta vulnerabilidad para acceder a secretos confidenciales del sistema de kube que contienen certificados de clúster y tokens de cuentas de servicio, modificar las configuraciones críticas del sistema y potencialmente lograr un compromiso en todo el clúster.
La vulnerabilidad socava fundamentalmente el modelo de seguridad de múltiples inquilinos de Capsule, lo que permite a los usuarios autenticados escapar de los límites de los inquilinos y acceder a los recursos a nivel del sistema.
Las organizaciones que utilizan versiones de cápsula afectadas deben actualizarse inmediatamente a la versión 0.10.4, que aborda esta falla de seguridad crítica.
La versión parcheada implementa mecanismos de validación adecuados para evitar la inyección de etiquetas no autorizada en los espacios de nombres del sistema, restaurando los límites de aislamiento multiinquilino previstos esenciales para operaciones seguras de Kubernetes.
Detonar de forma segura archivos sospechosos para descubrir amenazas, enriquecer sus investigaciones y reducir el tiempo de respuesta de incidentes. Comience con una prueba de Sandbox Anyrun →
