El bug puede usarse de dos formas: una relacionada con un usuario normal con derechos de exec, attach o portfoward sobre un grupo de contenedores que compartan almacenamiento y recursos en red. Se podrían escalar privilegios a nivel de cluster-admin y ejecutar cualquier proceso en un contenedor.
El segundo método explota la característica de extensión usada por metrics-server y service catalog de la API en una plataforma de contenedores OpenShift, OpenShift Online y dedicado. No es necesario tener ningún privilegio y un usuario sin autenticar puede tener derechos de administrador para cualquier extensión de la API.
En las configuraciones predeterminadas de Kubernetes, todos los usuarios (autenticados y no autenticados) pueden realizar llamadas a la API y por lo tanto explotar la vulnerabilidad. Básicamente, cualquiera que sepa sobre este agujero puede tomar el control de Kubernetes.
No hay una forma sencilla de detectar si se ha explotado esta vulnerabilidad previamente, debido a que las solicitudes no autorizadas se realizan a través de una conexión ya establecida y no aparecen en los registros de auditoría del servidor API de Kubernetes ni en el registro del servidor. Las solicitudes aparecen en los registros de Kubelet o API agregada del servidor, pero no se pueden distinguir de las solicitudes correctamente autorizadas y enviadas a través del servidor de la API de Kubernetes.
Red Hat dijo: «Esta falla de escalamiento de privilegios hace posible que cualquier usuario obtenga privilegios de administrador completos en cualquier nodo que esté ejecutando un pod Kubernetes. El atacante no solo puede robar datos confidenciales o inyectar código malicioso, sino que también pueden bajar las aplicaciones y servicios de producción».
«Afortunadamente», hay una solución: se debe actualizar Kubernetes YA, específicamente a la versión parcheada de Kubernetes v1.10.11, v1.11.5, v1.12.3, y v1.13.0-rc.1.
Si por alguna razón no se puede actualizar, hay algunas mitigaciones pero son casi peores que la enfermedad: se debe suspender el uso de servidores de API y eliminar los permisos del pod exec/attach/portforward de los usuarios que no deben tener acceso completo a la API de Kubelet.
De todas formas, Jordan Liggitt, el ingeniero de software de Google que corrigió el error, dijo que es probable que estas mitigaciones sean perjudiciales y que la única solución real es actualizar Kubernetes.
Otra cosa importante a tener en cuenta es que la explotación de la vulnerabilidad no deja rastros obvios en los registros y, ahora que se conoce la noticia de la falla, es solo una cuestión de tiempo hasta que sea abusada. Debido a que no hay forma de saber si esta falla de seguridad se ha usado activamente o no, se debe asumir que los datos confidenciales se han visto comprometidos y se deben rotar las contraseñas y otros secretos.
Cualquier programa, que incluye Kubernetes, es vulnerable. Los distribuidores de Kubernetes ya están lanzando soluciones. Por ejemplo, Red Hat informa que «todos sus servicios y productos basados en Kubernetes, incluyendo la plataforma de contenedores OpenShift de Red Hat, OpenShift en línea de Red Hat y OpenShift dedicado de Red Hat están afectados». Red Hat ha comenzado a lanzar los parches y actualizaciones de servicio a los usuarios afectados. Lo mismo ha hecho Azure AKS y Google Kubernetes Engine (GKE).
Más información:
- Elastisys
- Official mailing list announcement
- GitHub Issue 71411
- Red Hat security statement regarding OpenShift
Fuente: ZDNET
