Clústeres de Kubernetes expuestos, los puertos de Kubelet pueden ser objeto de abuso en ataques cibernéticos



Los clústeres de Kubernetes proporcionan una columna vertebral escalable y resistente para muchas aplicaciones modernas orientadas a World-wide-web. Sin embargo, si los adversarios pueden acceder a los nodos en esos clústeres, esencialmente se apoderan de su infraestructura. Pueden comprometer la integridad de sus sistemas y secuestrar la infraestructura y utilizarla para sus propios fines.

Los datos recientes de Shodan muestran 243 469 clústeres de Kubernetes que están expuestos públicamente. Estos clústeres también expusieron el puerto 10250, utilizado por el kubelet (el agente que se ejecuta en cada nodo y garantiza que todos los contenedores se ejecuten en un pod) como configuración predeterminada. Los atacantes podrían usar potencialmente la API de kubelet como un punto de entrada para apuntar a los clústeres de Kubernetes para extraer criptomonedas.

Magno Logan, investigador de Development Micro analizó cómo los ciberdelincuentes podían abusar de estos clústeres y expuso los puertos de kubelet.

En primer lugar, existe el problema de la fuga de información confidencial al devolver datos en los pods en ejecución en el nodo.

Además, dado que la API de kubelet está expuesta, hay otro punto last /correr que permitiría a un atacante ejecutar comandos dentro de los pods en ejecución del clúster simplemente enviando un CORREO solicitud a los pods específicos y usando el parámetro cmd para ejecutar los comandos de shell deseados. Development Micro dice actor de amenazas TeamTNT realizó múltiples /correr comandos de esta manera para comprometer varios clústeres el año pasado. Esta técnica puede facilitar las cosas para que los atacantes se apoderen de los clústeres, dice Logan en el informe.

Logan calificó de «muy preocupante» que los piratas informáticos pudieran usar la API de kubelet como punto de entrada al apuntar a los clústeres de Kubernetes.

«Esos 600 kubelets que encontramos completamente expuestos y sin autenticación o autorización podrían verse fácilmente comprometidos a través de simples solicitudes de API», dijo. «Eso permitiría a un atacante ejecutar comandos en los pods que se ejecutan dentro de ese nodo, la mayoría de las veces para extraer criptomonedas».

Kubelets expuestos dejan la puerta abierta a actores maliciosos

Según Michael Isbitski, director de estrategia de seguridad cibernética de Sysdig, cuando los clústeres o kubelets de Kubernetes se exponen incorrectamente o no aplican un handle de acceso adecuado, deja la puerta abierta para una amplia gama de actividades maliciosas.

«Los atacantes pueden recolectar potencialmente datos confidenciales que se transmiten dentro del clúster, activar nuevas cargas de trabajo, reconfigurar elementos de un nodo, deshabilitar controles de acceso, borrar pistas de auditoría, agregar dependencias vulnerables, arrancar criptomineros maliciosos y más», dice.

Isbitski señala que muchas configuraciones de Kubernetes son seguras de forma predeterminada con las ofertas de plataforma actuales, pero algunas organizaciones pueden estar sentadas en implementaciones antiguas o mal configuradas.

Señala que, en ocasiones, las organizaciones también anulan inadvertidamente los valores predeterminados de seguridad para llevar un clúster a un estado operativo sin comprender los posibles riesgos de seguridad.

«Hemos visto problemas con las vulnerabilidades en los componentes de tiempo de ejecución, lo que puede provocar escapes de contenedores y movimientos laterales dentro de las redes si los atacantes tienen éxito en sus intentos de explotación», dice.

Practique la defensa en profundidad, confianza cero

Matt Dupre, director de ingeniería de program de Tigera, un proveedor de seguridad y observabilidad para contenedores, Kubernetes y la nube, señala que el acceso suficientemente privilegiado al kubelet equivale a un compromiso full de ese host y, potencialmente, de cualquier otra carga de trabajo que se ejecute en él.

El acceso a la API de Kubernetes tiene el mismo impacto potencial: el acceso de administrador esencialmente proporciona un control completo del clúster y todo lo que contiene.

Señala que si bien el riesgo de seguridad es significativo, una abrumadora mayoría de los clústeres que aceptaron conexiones de Internet rechazaron las solicitudes debido a la falta de autenticación o autorización.

«Teniendo en cuenta eso, hay dos preocupaciones: en primer lugar, que caiga en esos clústeres 613 mal configurados, o que se encuentre una nueva vulnerabilidad crítica que pasa por alto authn o authz, y esta sería una vulnerabilidad muy importante», dice Dupre. «Las API internas de las organizaciones son probablemente una preocupación mayor en la práctica».

Aconseja practicar la defensa en profundidad siguiendo los principios de confianza cero y no permitiendo conexiones a sus kubelets desde fuentes desconocidas, como World-wide-web.

«Además, podría escanear puertos de su infraestructura e investigar cualquier respuesta», agrega. «Siempre es importante mantener un handle cuidadoso de los tokens de acceso: nunca deben publicarse y debe tener procesos implementados para garantizar que estos y otros secretos se almacenen correctamente».

Evite exponer el puerto predeterminado de Kubelet

Como práctica básica de seguridad de kubelet, Logan dice que las organizaciones no deberían exponer su puerto de kubelet (10250 de forma predeterminada) a Internet.

«Si necesita hacer eso, al menos habilite la autenticación y autorización de kubelet en la API de kubelet para evitar que los atacantes puedan realizar solicitudes a la API y recibir la respuesta 401: no autorizada», agrega.

Mark Lambert, vicepresidente de productos de ArmorCode, un proveedor de seguridad de aplicaciones, dice que al implementar este tipo de sistemas, adopte una «mentalidad de confianza cero» y recuerde que las configuraciones predeterminadas generalmente se configuran para facilitar el uso, no para la seguridad.

«Esto significa que debe prestar mucha atención a los archivos de configuración, deshabilitar las funciones que no está utilizando, cambiar los puertos predeterminados y minimizar la fuga de información para que los piratas informáticos no puedan obtener información que podría proporcionarles otro punto de ataque», dice.

Finalmente, todo esto debe ponerse en funcionamiento como parte de su programa de seguridad de la aplicación, y los equipos de desarrollo deben participar desde el principio, ya que desempeñan un papel clave en la incorporación de la seguridad en el diseño de la aplicación desde el principio.

Además de habilitar la autenticación y autorización de kubelet en la API de kubelet, Logan recomienda restringir los permisos de kubelet mediante el principio de privilegios mínimos y rotar periódicamente los certificados de kubelet para reducir la superficie de ataque.

«Las organizaciones también deberían investigar herramientas para la protección del tiempo de ejecución, como Falco, para prevenir y alertar cuando se produzcan ejecuciones sospechosas dentro de sus contenedores», dice.

Analice constantemente IaaC, monitoree clústeres en tiempo de ejecución

Isbitski dice que las capacidades nativas y las herramientas de los proveedores de la nube y los proveedores de la plataforma Kubernetes pueden proporcionar un punto de partida para mantener protegidos los kubelets.

Agrega que los equipos de seguridad deben analizar continuamente la infraestructura como código utilizada para configurar y operar clústeres, escanear dependencias utilizadas por cargas de trabajo y monitorear clústeres en tiempo de ejecución para detectar actividad maliciosa, como cuando un atacante intenta acceder sin autorización a las API de Kubernetes.

«También se debe implementar un regulate de acceso apropiado en múltiples puntos de un clúster», dice. «Las capacidades nativas como la política de red de Kubernetes también ayudan a restringir la comunicación dentro de un clúster y hacen cumplir los principios de confianza cero».

Isbitski señala que el plano de manage de Kubernetes también tiene varias capas cuando se trabaja con Kubernetes administrado.

En esos escenarios, los equipos de seguridad también deben validar continuamente las configuraciones de los inquilinos de la nube, junto con las políticas de IAM, en busca de errores de configuración y permisos excesivos.



Enlace a la noticia initial