Primer agujero de seguridad importante en Kubernetes
Kubernetes es un sistema Open Source que sirve para la automatizar el despliegue, ajustar las escalas y manejo de aplicaciones en contenedores en la nube. Debido al aumento de su popularidad en el último año solo era cuestión de tiempo para que alguien pudiese encontrar una vulnerabilidad critica de seguridad.
El equipo de Kubernetes ha lanzado tres nuevas versiones que solucionan un fallo crítico
Este lunes un ingeniero de Google, Jordan Liggitt, anunciaba las verversion v1.10.11, v1.11.5 y v1.12.3 de Kubernetes que han puesto a disposición de los usuarios para corregir el CVE-2018-1002105, una vulnerabilidad que permite la escaladación de privilegios.
El error de código en el proyecto de código abierto se ha designado con una severidad de 9.8 sobre 10 porque se puede ejecutar de forma remota, el ataque no es complejo y no se requieren interacción del usuario ni privilegios especiales.
Según Jordan Liggitt, un usuario malintencionado podría usar el servidor de API de Kubernetes para conectarse a un servidor de back-end para enviar solicitudes arbitrarias, autenticadas por las credenciales TLS del servidor de API.
El servidor API es la principal entidad de gestión en Kubernetes. Habla con el controlador de almacenamiento distribuido, etc., y con kublets, los agentes que supervisan cada nodo en un grupo de contenedores de software.
La vulnerabilidad fue descubierto por Darren Shepherd, arquitecto jefe y cofundador de los laboratorios Rancher.
Red Hat ya tiene implantados los parches en su plataforma Open Shift
Red Hat OpenShift, una plataforma de contenedores orientada a la empresa, ha introducido parches para todas las variantes de productos.
"Este es un gran problema", dijo Ashesh Badani, director de OpenShift y gerente general de OpenShift en Red Hat. "Los delincuentes no solo pueden robar datos confidenciales o inyectar códigos maliciosos, sino que también pueden reducir las aplicaciones y servicios de producción desde el firewall de una organización".
Dos vectores de ataque primarios
El primer vector de atauqe consiste en que una persona que posee los privilegios de la instancia "exec/attach/portforward" otorgados a un usuario normal de forma predeterminada puede convertirse en un administrador del clúster, obteniendo acceso a cualquier contenedor en el Pod (instancia) y potencialmente a cualquier información que contenga.
Segundo método permite que un usuario no autenticado acceder a la API para crear nuevos servicio que podrían usarse para inyectar código malicioso.
"Cualquier usuario no autenticado con acceso a un entorno Kubernetes puede llegar al punto final de descubrimiento que es el servidor API agregado (no el apiserver de Kube)", explicó Christopher Robinson, gerente de seguridad de productos de Red Hat, en un correo electrónico a The Register.
"La creación de un mensaje a la API para que falle la actualización puede dejar la conexión activa y permitir su reutilización con encabezados arbitrarios, y luego permitir el acceso de nivel de administrador de clúster a ese servidor de API agregado. Esto podría usarse contra el catálogo de servicios que permitiría la creación de instancias de servicio arbitrarias ".
La vulnerabilidad es particularmente preocupante porque las solicitudes no autorizadas no se pueden detectar fácilmente. De acuerdo con Liggitt, no se muestran en los registros de auditoría del servidor Kubernetes API o en el registro del servidor.
Las solicitudes de los atacantes son visibles en los registros del servidor de la API agregada o kublet, pero no hay nada que las distinga de las solicitudes autorizadas y enviadas a través del servidor de la API de Kubernetes.
