Encontramos e confirmamos cerca de 50.000 IPs comprometidos por este ataque perpetrado pelo TeamTNT em vários clusters. Vários IPs foram explorados repetidamente durante o período do episódio, que ocorreu entre março e maio.

O Kubernetes é a plataforma de orquestração de contêiner mais adotada para automatizar a implantação, escalonamento e gerenciamento de aplicações em contêineres. Infelizmente, como qualquer aplicação amplamente usada, ele é um alvo atraente para os agentes de ameaças, pois costuma estar mal configurado, especialmente aqueles executados principalmente em ambientes de nuvem com acesso a recursos quase infinitos. Este artigo tratará como o TeamTNT — que discutimos extensivamente em artigos anteriores — tem verificado e comprometido os clusters do Kubernetes que estão na ativa.

Encontramos e confirmamos cerca de 50.000 IPs comprometidos por este ataque perpetrado pelo TeamTNT em vários clusters. Vários IPs foram explorados repetidamente durante o período do episódio, ocorrendo entre março e maio. A maioria dos nós comprometidos era da China e dos EUA — identificados na lista de ISP (Internet Service Provider), que teve provedores chineses e norte-americanos como os maiores resultados, incluindo alguns CSPs (Cloud Service Providers ou Provedores de Serviços em Nuvem). Deve-se observar que os números refletem a probabilidade de um número significativamente maior de clusters em operação nos EUA e na China do que em muitos outros países.

Figura 1. A porcentagem de servidores comprometidos por país. China e Estados Unidos constituem a maioria dos IPs comprometidos.

Ao analisar os dados pertencentes a alguns servidores TeamTNT, descobrimos as ferramentas e técnicas utilizadas pelo grupo para esta campanha.

 

Como um cluster do Kubernetes é comprometido

Esta seção analisará um dos scripts que coletamos desse agente de ameaça que tem como alvo os clusters do Kubernetes. Coletamos um dos arquivos de seu servidor, denominado kube.lateral.sh, que tinha uma taxa de detecção baixa no VirusTotal no momento da redação deste blog. Detalhamos o que esse script faz e como o faz.

Figura 2. Detecções de VirusTotal para kube.lateral.sh verificadas em 24 de abril de 2021 (parte superior) e 5 de maio de 2021 (parte inferior)

 

Configurando o ambiente

A primeira ordem de negócios do TeamTNT é desabilitar o histórico do bash no host de destino e definir variáveis de ambiente para seu servidor de comando e controle (command and control ou C&C), como o script para instalar o crypto miner mais tarde e o binário do XMRig Monero miner. Em seguida, uma pasta é criada dentro de/tmp usando $ RANDOM três vezes, gerando uma sequência de números aleatórios — por exemplo, 132963764049, 64049520243 e 55772468520243. As informações de arquitetura do usuário e do sistema são coletadas usando whoami e uname –m, que são armazenados em variáveis de ambiente para serem usadas posteriormente.

O script também instala duas ferramentas gratuitas de código aberto disponíveis no GitHub, a ferramenta de varredura de rede masscan — desenvolvida em C — e o Zgrab obsoleto para apanhar banners — desenvolvido em Go. A nova versão Zgrab2 também é open source e está disponível no GitHub, mas não é instalada com o script.

 

Baixando e instalando o Bot de IRC

O script tem um grande bloco de código codificado em base64 para instalar seu bot de IRC. Decodificamos, analisamos e descobrimos que ele está escrito em C e armazenado na pasta /tmp com o nome kube.c para evitar suspeitas. O código do bot é compilado com Gnu Compiler Collection (GCC) e removido após a conclusão da compilação. O binário resultante gerado é então movido para a pasta /root e renomeado para kube conforme o código abaixo ilustra:

---

“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

---

O bot de IRC, também escrito em C, é baseado em outro bot de IRC famoso chamado Kaiten. Códigos semelhantes para esses bots também estão disponíveis no GitHub.

Figura 3. Código para instalar o bot IRC denominado kube.c.

 

Pods de Pwning e cryptojacking do Kubernetes

Na última parte do script, podemos ver uma função — kube_pwn ()—  sendo declarada, assim como na imagem abaixo. Como visto no código, a função kube_pwn usa o Masscan para verificar todos os hosts com a porta 10250 aberta.

Figura 4. Código mostrando como a função kube_pwn usa o Masscan para verificar hosts com a porta 10250 aberta.

 

Kubelets

Quem está familiarizado com o Kubernetes saberá que essa porta pertence à API kubelet e, por padrão, está aberta em todos os nós de um cluster, incluindo o plano de controle e os nós de trabalho. E essa é uma das primeiras alterações essenciais de proteção de segurança que você deve fazer em um cluster K8s operacional. Kubelet é o agente executado em cada nó e garante que todos os contêineres sejam executados em um pod. É também o agente responsável por quaisquer alterações de configuração nos nós. Embora não esteja no diagrama de arquitetura principal do Kubernetes, até mesmo o nó do plano de controle tem um agente kubelet (e um kube-proxy) em execução se um usuário quiser executar outros pods lá. No entanto, não é considerada uma prática recomendada executar os pods de sua aplicação no plano de controle, pois isso permite que os invasores tenham a oportunidade de possuir o cluster, como vemos aqui.

Existem três fatores críticos para as configurações de segurança do kubelet:

1. Habilitando a autenticação Kubelet. De acordo com a documentação do Kubernetes, as solicitações ao endpoint da API do kubelet, que não são bloqueadas por outros métodos de autenticação, são tratadas como solicitações anônimas por padrão. Certifique-se de iniciar os kubelets com o sinalizador –anonymous-auth = false e desabilitar o acesso anônimo. Para mais informações, verifique as recomendações oficiais do Kubernetes sobre a autenticação do Kubelet.
2. Restringir as permissões do kubelet para evitar que invasores leiam as credenciais do kubelet após sair do contêiner para realizar ações maliciosas.
3. Alternar os certificados kubelet na chance de ocorrer um comprometimento, os certificados têm vida curta e o impacto potencial é reduzido.

De acordo com a documentação para instalação do Kubernetes via kubeadm, as portas abaixo são as que precisam ser abertas para que um cluster funcione corretamente. A porta da API kubelet (10250) não deve ser exposta à Internet, pois é semelhante a deixar a API Docker Daemon exposta. No entanto, TeamTNT está comprometendo o kubelet após obter acesso ao ambiente neste ataque específico, então eles executam as verificações internamente.

Figura 5. Portas necessárias para instalação do kubeadm.

A API kubelet não está bem documentada. No entanto, analisamos o código do Kubernetes diretamente para entender o que está acontecendo, o que é explicado nas seções a seguir. Primeiro, vimos o arquivo server.go dentro do pacote/kubelet/server. Conforme mostrado na Figura 5, a primeira coisa que a função kube_pwn () faz é obter algumas informações da API Kubelet por meio do endpoint/runningpods, filtrando o namespace, o nome do pod e os nomes do contêiner.

Figura 6. Análise do código-fonte da API Kubernetes kubelet. Fonte: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/server/server.go#L489

 

Crypto jacking (implantado em pods)

Como podemos ver no código kubelet server.go acima, o endpoint/runningpods da API faz exatamente o que o endpoint diz, ele lista os pods em execução. Primeiro, a função kube_pwn () lista todos os pods em execução no momento dentro do nó em um formato JSON. Em seguida, para cada contêiner em execução em cada nó, ele aproveita o endpoint/run na API kubelet para executar os seguintes comandos:

1.   Atualizar o índice do pacote do contêiner.
2.   Instalar os seguintes pacotes: bash, wget e curl.
3.   Fazer o download de um shellscript chamado setup_xmr.sh do servidor TeamTNT C&C e o salvar na pasta tmp.
4.   Executar o script para iniciar a mineração para a criptomoeda Monero.

Figura 7. Parte do código do servidor API do kubelet do repositório central do Kubernetes no GitHub. Fonte: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/server/server.go#L410

Para terminar, eles executam a mesma função kube_pwn () que analisamos em uma série de intervalos de IP internos em busca de novos alvos para comprometer, com comportamento semelhante a um worm.

Figura 8. Um pedaço de código do kube.lateral.sh, o arquivo identificado no servidor de C&C do TeamTNT.

 

Recomendações e soluções de segurança em nuvem da Trend Micro

De acordo com o novo MITRE ATT&CK for Containers, Exploit Public-Facing Applications (T1190) é um dos pontos de entrada para invasores e pode permitir que eles assumam o cluster de uma organização por meio de configuração incorreta de RBAC ou de uma versão vulnerável de um cluster.

 

Como proteger o servidor Kube API

É importante garantir que seus servidores Kube API não sejam expostos. Uma maneira direta de verificar é tentando acessar o servidor API a partir de um IP externo. Esta solicitação curl deve ser usada para verificar se a API é voltada ao público ou não: “curl -k https://API-SERVER-IP: PORT/api.”

Se houver uma resposta dessa solicitação curl, semelhante à mostrada na Figura 9, isso significa que a API está disponível publicamente e está exposta:

Figura 9. Um exemplo de resposta após a execução de uma solicitação curl para verificar se uma API está acessível publicamente.

Outras práticas recomendadas para proteger as implantações do Kubernetes podem ser encontradas em nosso guia infosec, “The Basics of Keeping Kubernetes Clusters Secure”.

Soluções de segurança em nuvem, como Trend Micro Cloud One™, ajudam as empresas a acessar proteção para integração contínua e pipelines de entrega contínua (CI/CD) e aplicações. A plataforma inclui:

•       Workload Security: proteção de tempo de execução para workloads
•       Container Security: varredura avançada de imagem de contêiner e proteção de tempo de execução de contêiner
•       File Storage Security: segurança para arquivos em nuvem e serviços de armazenamento de objetos
•       Network Security: camada de rede em nuvem para segurança do sistema de prevenção de intrusão (IPS)
•       Application Security: segurança para funções serverless, APIs e aplicações
•     Conformity: segurança em tempo real para infraestrutura em nuvem — proteja, otimize, esteja em conformidade

 

Conclusão

Esta campanha é notável porque é a primeira vez que analisamos ferramentas publicadas do grupo TeamTNT. Além disso, o uso contínuo de cripto-jacking e roubo de credenciais indicam que eles permanecerão no repertório principal de técnicas do agente de ameaça em um futuro próximo.

O alto número de alvos mostra que TeamTNT ainda está expandindo seu alcance (especialmente em ambientes de nuvem) e talvez infraestrutura, uma vez que o grupo pode monetizar uma quantia mais significativa de suas campanhas com mais vítimas em potencial. As atividades do grupo aumentam o número de ameaças potenciais que os usuários do Kubernetes enfrentam.

 

Indicadores de Comprometimento (IOCs)

File name	SHA256	Detection name
kube.lateral.sh	0dc0d5e9d127c8027c0a5ed0ce237ab07d3ef86706d1f8d032bc8f140869c5ea	Trojan.SH.YELLOWDYE.A