Hemos encontrado y confirmado alrededor de 50,000 IPs comprometidas por el ataque perpetrado por TeamTNT a lo largo de múltiples clusters. Varias IPs fueron explotadas repetidamente durante el marco de tiempo del episodio, el cual ocurrió entre marzo y mayo.
Kubernetes es la plataforma de orquestación de containers más ampliamente adaptada para la automatización del despliegue, escalamiento y administración de aplicaciones contenerizadas. Desafortunadamente, como cualquier aplicación comúnmente utilizada, se ha convertido en un blanco atractivo para los actores maliciosos, ya que a menudo existen temas de configuración, especialmente en aquellas que corren en ambientes principalmente en la nube con acceso a recursos casi infinitos. Este artículo discutirá cómo TeamTNT — el cual ha sido discutido de forma extensiva previamente — ha estado escaneando y comprometiendo clusters de Kubernetes in the wild.
Hemos encontrado confirmado alrededor de 50,000 IPs comprometidas por este ataque que TeamTNT ha perpetrado a lo largo de múltiples clusters. Varios de estas IPs se vieron explotadas de forma repetida durante el marco del tiempo del episodi, el cual ocurrió entre marzo y mayo. La mayoría de los nodos comprometidos provenían de China y los Estados Unidos – identificados en la lista de ISP (Internet Service Provider), la cual mostraba a los proveedores chinos y estadounidenses como los más afectados, incluyendo a algunos CSP (Cloud Service Providers). Debe notarse que los números reflejan la probabilidad de que hay más clusters en operación en los Estados Unidos y en China que en muchos otros países.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Captura-de-Pantalla-2021-08-05-a-las-18.24.35-300×187.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”187″]
Al analizar los datos que pertenecen algunos de los servidores de TeamTNT, descubrimos las herramientas y técnicas que utiliza este grupo para esta campaña.
Cómo se compromete el cluster de Kubernetes
Esta sección analizará uno de los scripts que hemos recolectado de este actor malicioso y que se dirige hacia los clusters de Kubernetes. Obtuvimos uno de los archivos de su servidor, llamado kube.lateral.sh, que tenía un índice bajo de detección en VirusTotal al momento en que este artículo se escribió. Exploramos lo que hace este script y cómo lo hace.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-2-300×177.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”177″]
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-3-300×217.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”217″]
Configurando el ambiente
Lo primero que hace TeamTNT es deshabilitar el historial de bash en el host objetivo y definir las variables del ambiente para su servidor de comando y control (C&C), como el script para instar el cryptominer y el binario del miner XMRig Monero. Entonces, se crea un folder dentro de /tmp usando $RANDOM tres veces, generando una secuencia de números al azar – por ejemplo, 132963764049, 64049520243 y 55772468520243. Se recolecta la información sobre usuarios y la arquitectura del sistema usando whoami y uname –m, los cuales se almacenan en las variables del ambiente para usarse después.
El script también instala dos herramientas gratuitas de código abierto de GitHub, la herramienta de escaneo de redes masscan, desarrrollada en C, y Zgrab, desarrollada en Go. La nueva versión Zgrab2 también es open source y está disponible en GitHub pero no se instala con el script.
Descargando e instalando el Bot IRC
El script tiene un bloque grande de código base64 codificado para instalar su bot IRC. Desciframos, analizamos y descubrimos que está escrito en C y que está almacenado en el folder /tmp bajo el nombre kube.c para evitar sospechas. El código del bot se compila con Gnu Compiler Collection (GCC) y se elimina después de que termina de compilar. El binario resultante generado entonces se mueve al folder /root y se cambia el nombre a kube como ilustra el código abajo:
“BASE64 ENCODED KUBE.C CODE HERE” | base64 -d > /var/tmp/kube.c
cd /var/tmp/; gcc -o /var/tmp/kube /var/tmp/kube.c && rm -f /var/tmp/kube.c
mv /var/tmp/kube /root/.kube && chmod +x /root/.kube && /root/.kube
El bot IRC, también escrito en C, se basa en otro bot IRC famoso llamado Kaiten. Código similar para estos bots está disponible en GitHub.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-4-300×89.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”89″]
Pwning y cryptojacking pods de Kubernetes
En la última parte del script, podemos ver una función — kube_pwn() — declarándose, justo como se muestra en la imagen debajo. Como se ve desde el código, la función kube_pwn usa Masscan revisa cualquier host con el puerto 10250 abierto.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-5-300×150.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”150″]
Kubelets
Aquellos familiares con Kubernetes sabrán que este Puerto pertenece a la API de kubelet, y por defecto, está abierto en todos los nodos de un cluster, incluyendo el plano de control y los nódos de trabajo. Y ese es uno de los primeros cambios de fortalecimiento de seguridad que debe de hacer en un cluster K8s operacional. Kubelet es el agente que corre en cada nodo y asegura que todos los containers están corriendo en un pod. También es el agente que es responsable por cualquier cambio de configuración en los nodos. Aunque no se encuentra en el diagrama principal de arquitectura de Kubernetes, incluso el nodo del plano de control tiene un agente kubelet (y un kube-proxy) corriendo si un usuario quiere correr otros pods ahí. Sin embargo, no se considera una mejor práctica correr los pods de sus aplicaciones en el plano de control ya que le da a los atacantes la oportunidad de adueñarse del cluster como vemos aquí.
Hay tres factores críticos para las configuraciones de seguridad de kubelets:
- Permitir la autenticación deKubelets. De acuerdo con las solicitudes dedocumentación de Kubernetes a la API kubelet del endpoint, las cuales no se bloquean con otros métodos de autenticación, se tratan como solicitudes anónimas por defecto. Por favor asegure que inicie los kubelets con la alerta –anonymous-auth=false y deshabilite el acceso anónimo. Para más información revise las recomendaciones oficiales de Kubernetes sobre la autenticación de Kubelets.
- Restringir los permisos dekubeletspara prevenir que los atacantes lean las credenciales de los kubelets después de salirse del container para realizar acciones maliciosas.
- Rotar los certificados dekubeletsen caso de que ocurra un compromiso, los certificados tienen poca duración y se reduce el impacto potencial.
De acuerdo con la documentación para la instalación de Kubernetes vía kubeadm, los puertos abajo son los que se necesita tener abiertos para que un cluster funcione adecuadamente. El puerto de la API de kubelet (10250) no debe exponerse al internet ya que equivale a exponer su API Docker Daemon. Sin embargo, TeamTNT está comprometiendo el kubelet después de obtener acceso al ambiente en este ataque específico, entonces corren los escaneos de forma interna.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-6-300×230.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”230″]
La API de kubelet no está bien documentada; sin embargo, analizamos directamente el código de Kubernetes para entender qué es lo que está pasando, lo cual se explica en las siguientes secciones. Primero, miramos el archivo server.go dentro del paquete /kubelet/server. Como se muestra en la figura 5, lo primero que hace la función kube_pwn() es obtener información acerca de la API de kubelet a través del endpoint /runningpods, filetrando el espacio para nombre, nombre del pod y los nombres de los containers.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-7-300×133.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”133″]
Crypto jacking (despliegue a pods)
Como podemos ver en el código arriba, /runningpods hace exactamente lo que dice el endpoint, lista los pods que corren en ese momento. Primero, la función kube_pwn() lista todos los pods que corren en ese momento dentro del nodo en un formato JSON. Entonces, para cada container que corre en cada nodo, aprovecha el endpoint /run en la API de kubelet para correr los siguientes comandos:
- Actualiza el índice del paquete delcontainer
- Instala los siguientes paquetes:bash, wgety curl.
- Descarga unshellscript llamado setup_xmr.sh del servidor C&C de TeamTNT y lo guarda en el folder tmp.
- Ejecuta el script para comenzar a minar lacriptomonedaMonero.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-8-300×109.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”109″]
Para terminar, corren la misma función kube_pwn() que analizamos contra una serie de rangos internos de IPs, buscando nuevos blancos para comprometer, con un comportamiento similar al de un gusano.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-9-300×23.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”23″]
Recomendaciones y soluciones de seguridad de Trend Micro para la nube
De acuerdo con el nuevo MITRE ATT&CK for Containers, los exploits de aplicaciones de cara al público (T1190) es uno de los puntos de entrada para los atacantes y podría permitirles tomar el control del clúster de una organización a través de una falla de configuración RBAC o la versión vulnerable de un clúster.
Cómo proteger el Servidor API Kube
Es importante asegurar que los Servidores API Kube no estén expuestos. Una forma directa de revisarlo es intentar llegar al servidor API desde una IP externa. Esta solicitud puede usarse para revisar si la API está de cara al público o no: “curl -k https://API-SERVER-IP:PORT/api.”
Si llega a haber una respuesta a esta solicitud, similar a la mostrada en la Figura 9, significa que la API está disponible al público y se encuentra expuesta:
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/08/Team-TNT-Kubernetes-10-300×107.jpeg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”107″]
Otras mejores prácticas para la protección de los despliegues de Kubernetes pueden encontrarse en nuestra guía infosec “The Basics of Keeping Kubernetes Clusters Secure.”
Soluciones de seguridad en la nube como Trend Micro Cloud One™ ayudan a las empresas a acceder a la protección para aplicaciones y pipelines de integración continua y entrega continua (CI/CD). La plataforma incluye:
- Workload Security: protección para workloads en ejecución
- Container Security: escanea automatizado de imágenes y registros en containers
- File Storage Security: seguridad para servicios de almacenamiento en la nube de archivos y objetos
- Network Security: seguridad IPS para la capa de la red en la nube
- Application Security: seguridad para funciones, APIs y aplicaciones serverless
- Conformity: protección en tiempo real para la infraestructura de la nube – proteja, optimice, cumpla
Conclusión
La campaña es notoria porque es la primera vez que analizamos herramientas publicadas del grupo TeamTNT. Además, el uso continuo de crypto-jacking y robo de credenciales indica que estos permanecerán en el repertorio de técnicas principal del actor malicioso en el futuro cercano.
El alto número de targets muestra que TeamTNT aún está expandiendo su alcance (especialmente en los ambientes en la nube) y tal vez también su infraestructura, ya que el grupo puede monetizar una cantidad significativa de sus campañas con más víctimas potenciales. Las actividades del grupo agregan al número amenazas potenciales que enfrentan los usuarios de Kubernetes.
Indicadores de Compromiso (IOCs)
-Nombre de archivo: kube.lateral.sh
-SHA256: 0dc0d5e9d127c8027c0a5ed0ce237ab07d3ef86706d1f8d032bc8f140869c5ea
-Nombre de detección: Trojan.SH.YELLO
Leave a Reply