Kubernetes se convirtió por mucho en el sistema más popular de los contenedores en la nube. Por lo que en realidad solo era una cuestión de tiempo hasta que su primera gran falla de seguridad fuera descubierta.
Y así fue, pues recientemente se dio a conocer el primer gran fallo de seguridad en Kubernetes bajo el CVE-2018-1002105, también conocido como el fracaso de la escalada de privilegios.
Este gran fallo en Kubernetes es un problema pues es un agujero de seguridad crítica CVSS 9.8. En el caso de que se produzca la primera gran falla de seguridad de Kubernetes.
Detalles del error
Con una red de solicitud especialmente diseñada, cualquier usuario puede establecer una conexión a través del servidor de interfaz de programación de aplicaciones (API) Kubernetes a un servidor back-end.
Una vez establecido, un atacante puede enviar solicitudes arbitrarias por la conexión de red directamente a ese back-end en el cual en todo momento el objetivo es ese servidor.
Estas solicitudes se autentican con las credenciales TLS (Transport Layer Security) del servidor Kubernetes API.
Peor aún, en la configuración predeterminada, todos los usuarios (autenticados o no) pueden ejecutar llamadas de descubrimiento de API que permiten esta escalada de privilegios por parte de atacante.
Con lo cual entonces, cualquiera que conozca ese agujero puede aprovechar para asumir el mando de su clúster de Kubernetes.
De momento no hay una manera sencilla de detectar si se utilizó esta vulnerabilidad previamente.
A medida que las solicitudes no autorizadas se realizan en una conexión establecida, que no aparecen en los registros de auditoría de servidor de Kubernetes API o el registro del servidor.
Las solicitudes aparecen en los registros de kubelet o servidor API agregado, pero se distinguen de las solicitudes debidamente autorizados y enviados por poder a través del servidor API Kubernetes.
Abusar de esta nueva vulnerabilidad en Kubernetes no dejaría huellas obvias en los registros, por lo que ahora que el fallo de Kubernetes está expuesto, es sólo una cuestión de tiempo hasta que se utilice.
En otras palabras, Red Hat dijo:
El fallo en el escalonamiento de privilegios permite a cualquier usuario no autorizado, el poder obtener privilegios totales de administrador en cualquier nodo computacional que se esté ejecutando en un pod Kubernetes.
Esto no es sólo un robo o una apertura para inyectar código malicioso, sino que también puede reducir los servicios de aplicación y producción dentro del servidor de seguridad de una organización.
Cualquier programa, incluyendo Kubernetes, es vulnerable. Los distribuidores de Kubernetes ya están liberando correcciones.
Red Hat informa de todos sus productos y servicios basados en Kubernetes incluyendo a Red Hat OpenShift Container Platform, Red Hat OpenShift Online e Red Hat OpenShift Dedicated están afectados «.
Red Hat comenzó a proporcionar parches y actualizaciones de servicios a los usuarios afectados.
Por lo que se sabe, nadie utilizó la brecha de seguridad para atacar todavía. Darren Shepard, arquitecto jefe y co-fundador de Rancher laboratory, descubrió el error e informó mediante el proceso de informe de la vulnerabilidad de Kubernetes.
¿Cómo corregir este fallo?
Afortunadamente ya fue liberada una corrección para este fallo. En lo cual solamente se pide que realicen una actualización de Kubernetes por lo que pueden elegir algunas de las versiones con parches Kubernetes v1.10.11, v1.11.5, v1.12.3 y v1.13.0-RC.1.
Por lo que si todavía están utilizando alguna de las versiones de Kubernetes v1.0.x-1.9.x, es recomendable que actualicen a una versión corregida.
Si por algún motivo no pueden realizar la actualización de Kubernetes y quieren parar este fallo es necesario que realicen el siguiente proceso.
Ustedes deben dejar de utilizar la API de agregados de servidores o eliminar los permisos pod exec /attach /portforward a usuarios que no deberían tener acceso completo a kubelet API.
Jordan Liggitt, el ingeniero de software de Google que corrigió el error, dijo que esas medidas probablemente serán perjudiciales.
Por lo que la única solución real contra este fallo de seguridad es realizar la actualización correspondiente de Kubernetes.