Logotipo de Zephyrnet

Parche ahora: la falla de Kubernetes RCE permite la adquisición total de los nodos de Windows

Fecha:

Un error de seguridad en el ampliamente utilizado sistema de gestión de contenedores Kubernetes permite a los atacantes ejecutar código de forma remota con privilegios del sistema en puntos finales de Windows, lo que podría llevar a la toma total de todos los nodos de Windows dentro de un Racimo de Kubernetes.

El investigador de seguridad de Akamai, Tomer Peled, descubrió la falla, que se rastrea como CVE-2023-5528 y tiene una puntuación CVSS de 7.2. La explotación radica en la manipulación de volúmenes de Kubernetes, una característica destinada a permitir el intercambio de datos entre pods en un clúster, o almacenarlos de manera persistente fuera del ciclo de vida de un pod, explicó. en un blog publicado en marzo de 13.

Como vector de ataque, los atacantes necesitarían para crear pods y volúmenes persistentes en nodos de Windows, lo que les permitiría escalar a privilegios de administrador en esos nodos, según un listado de GitHub para la falla.

"Es muy fácil explotar esta vulnerabilidad porque un atacante solo necesitaría modificar un parámetro y aplicar 3 archivos YAML para obtener RCE en los puntos finales de Windows", le dice Peled a Dark Reading. El marco de Kubernetes "Utiliza archivos YAML para básicamente todo", escribió en la publicación.

Clústeres de Kubernetes sólo se ven afectados si utilizan un complemento de almacenamiento en árbol para Windows; sin embargo, "hay muchos tipos diferentes de volúmenes que los desarrolladores pueden usar", creando diferentes escenarios de ataque, observó Peled en la publicación.

Las instalaciones predeterminadas de Kubernetes anteriores a la versión 1.28.4 que ejecutan implementaciones locales y el servicio Azure Kubernetes son vulnerables. Se ha alertado al equipo de Kubernetes sobre la falla y hay un parche disponible para solucionarlo, lo cual es muy recomendable.

"Dado que el problema radica en el código fuente, esta amenaza permanecerá activa y su explotación probablemente aumentará; es por eso que recomendamos encarecidamente parchear su clúster incluso si no tiene ningún nodo de Windows", escribió Peled.

Siguiendo los defectos

Peled descubrió la falla después de una investigación de otra vulnerabilidad que compartía la misma causa raíz: llamada de función insegura y falta de desinfección de la entrada del usuario en Kubernetes. Ese defecto fue CVE-2023-3676, una vulnerabilidad de inyección de comandos que podría explotarse aplicando un archivo YAML malicioso en el clúster. El descubrimiento de esta vulnerabilidad llevó al descubrimiento de otras dos que también son causadas por la falta de desinfección del parámetro subPath en los archivos YAML, lo que crea pods con volúmenes y abre una oportunidad para la inyección de código malicioso.

"Al final de esa investigación, notamos un lugar potencial en el código que parecía que podría conducir a otra vulnerabilidad de inyección de comandos", que finalmente se convirtió en CVE-2023-5528, explicó Peled.

"Después de varios intentos, logramos lograr un resultado similar: ejecutar comandos como el servicio kubelet (privilegios del SISTEMA)", escribió.

Explotación y parcheo

La prueba de concepto que ejecutaron los investigadores se centró en los volúmenes locales, uno de los tipos de volúmenes dentro de Kubernetes. Al crear un pod que incluye un volumen local, el servicio kubelet eventualmente llegará a una función con una llamada de línea cmd a "exec.command", creando un enlace simbólico entre la ubicación del volumen en el nodo y la ubicación dentro del pod.

Como muchos terminales, el símbolo del sistema de Windows (cmd) permite la ejecución de dos o más comandos uno tras otro, así como múltiples comandos en la misma línea de comando. "El hecho de que podamos controlar uno de los parámetros en la ejecución de cmd significa que podemos utilizar la inyección de comandos", explicó Peled.

Existen requisitos previos para lograr esto en volúmenes locales, incluida la necesidad de especificar o crear un volumen persistente, entre otros. Sin embargo, una vez creado ese volumen, "un usuario puede solicitar espacio de almacenamiento utilizando un persistenteVolumeClaim", escribió. "Aquí es donde se puede colocar la inyección".

El parche creado para la falla elimina la oportunidad de inyección eliminando la llamada cmd y reemplazándola con una función GO nativa que realizará la misma operación para crear el enlace simbólico. "Ahora, la biblioteca GO 'os' sólo realizará una operación de enlace simbólico, como se pretendía inicialmente", explicó.

¿Es su sistema vulnerable?

Kubernetes se ha convertido en uno de los sistemas de código abierto para contenedores más utilizados; sin embargo, también se ha convertido un objetivo principal para los actores de amenazas debido a su gran potencial para la explotación y acceso a los datos organizacionales. Además, muchas veces la propia configuración de Kubernetes crea una instalación vulnerable, lo que proporciona una amplia superficie de ataque para los actores de amenazas.

"Kubernetes es una herramienta muy compleja y sólida", afirma Peled. "Por un lado, su solidez permite a los usuarios adaptar su experiencia a las necesidades de su organización, pero por otro lado hace que sea muy difícil proteger todos los aspectos tanto desde el punto de vista del desarrollador como del usuario".

De hecho, el descubrimiento de CVE-2023-5528 y sus fallas relacionadas resalta para las empresas que implementan Kubernetes “lo crucial que es verificar los YAML de configuración de Kubernetes, ya que falta desinfección de entradas en varias áreas de código en el propio Kubernetes y sus proyectos paralelos”, escribió Peled. .

Seguir las mejores prácticas, como el control de acceso basado en roles (RBAC) y asegurarse de que los clústeres estén actualizados, también "debería mitigar una gran parte de las amenazas conocidas", le dice a Dark Reading.

Un entorno empresarial que ejecuta Kubernetes es vulnerable a la explotación de la falla solo si una versión del sistema es anterior a la 1.28.4 y el sistema ejecuta nodos de Windows. Si este es el caso, Akamai proporcionó un comando para que los administradores lo ejecuten para determinar si el sistema debe ser parcheado. Si es así, se debe priorizar la aplicación de parches.  

"Si su clúster de Kubernetes no tiene ningún nodo de Windows, no tiene que apresurarse a parchear esta vulnerabilidad específica", señaló Peled. "Pero es importante parchearlo de todos modos cuando tengas tiempo".

Si la aplicación inmediata de parches no es una opción, Akamai también está proporcionando una regla de Open Policy Agent (OPA) para ayudar a detectar y bloquear este tipo de comportamiento. OPA es un agente de código abierto que permite a los usuarios recibir datos sobre el tráfico que entra y sale de los nodos y tomar acciones basadas en políticas sobre los datos recibidos.

punto_img

Información más reciente

punto_img