“Siloscape”: o primeiro malware a ter como alvo os contêineres do Windows

Os contêineres do Windows foram vitimados por mais de um ano pelo primeiro malware conhecido a atingir os contêineres do Windows. A campanha em andamento perfura os clusters do Kubernetes para plantar backdoors, permitindo que os invasores roubem dados e credenciais do usuário ou até sequestrem bancos de dados inteiros hospedados em um cluster

O malware foi descoberto pelo pesquisador de segurança da Unit 42, Daniel Prizmant. Ele o apelidou de Siloscape, que ele pronuncia “Silo Escape“. O malware abre vulnerabilidades conhecidas em servidores da web e bancos de dados para comprometer os nós do Kubernetes e os clusters de backdoor.

Em uma postagem publicada na segunda-feira, Prizmant escreveu que o Siloscape é um malware fortemente ofuscado que visa clusters Kubernetes por meio de contêineres do Windows, com o objetivo principal de abrir “um backdoor em clusters Kubernetes mal configurados para executar contêineres maliciosos”

O Siloscape é um malware fortemente ofuscado que visa clusters do Kubernetes por meio de contêineres do Windows. Seu principal objetivo é abrir um backdoor em clusters do Kubernetes mal configurados para executar contêineres maliciosos.
Comprometer um cluster inteiro é muito mais grave do que comprometer um contêiner individual, pois um cluster pode executar vários aplicativos em nuvem, enquanto um contêiner individual geralmente executa um único aplicativo em nuvem. Por exemplo, o invasor pode ser capaz de roubar informações críticas, como nomes de usuário e senhas, arquivos confidenciais e internos de uma organização ou até mesmo bancos de dados inteiros hospedados no cluster. Esse tipo de ataque pode até ser aproveitado como um ataque de ransomware, tornando os arquivos da organização como reféns. Pior ainda, com as organizações migrando para a nuvem, muitas usam clusters Kubernetes como seus ambientes de desenvolvimento e teste, e uma violação desse ambiente pode levar a ataques devastadores à cadeia de suprimentos de software.
O Siloscape usa o proxy Tor e um domínio .onion para se conectar anonimamente ao seu servidor de comando e controle (C2). Consegui obter acesso a este servidor. Identificamos 23 vítimas ativas do Siloscape e descobrimos que o servidor estava sendo usado para hospedar 313 usuários no total, sugerindo que o Siloscape era uma pequena parte de uma campanha mais ampla. Também descobri que essa campanha já acontece há mais de um ano. (Daniel Prizmant – Unit42)

Golpeando o coração de recipientes cada vez mais populares

Em uma postagem separada , os pesquisadores da Unit 42, Ariel Zelivansky e Matthew Chiodi, compararam os contêineres aos usados ​​para embalar diferentes materiais em navios de carga. Eles são uma maneira fácil de executar aplicativos na nuvem, pois eles embalam diferentes materiais juntos para maior eficiência, permitindo que as equipes de desenvolvimento se movam rapidamente e operem “em quase qualquer escala“.

A execução de um aplicativo em um contêiner dessa maneira é conhecida como conteinerização (do inglês containerization) e, como outras formas remotas de trabalho, é acelerada devido ao COVID-19. “Temos visto mais e mais organizações usando contêineres na nuvem nos últimos anos, especialmente desde que a pandemia de COVID-19 fez com que muitos buscassem se mover mais rapidamente e implantar cargas de trabalho em nuvem com mais eficiência”, observaram os pesquisadores.

Componentes do Kubernetes. Fonte: Kubernetes

Windows: um primeiro indesejável

De acordo com Zelivansky e Chiodi, esta é a primeira vez que pesquisadores viram malware direcionado a contêineres do Windows. O sistema operacional Linux em ambientes de nuvem é muito mais popular, disseram eles.

Os pesquisadores da Unit 42 identificaram 23 vítimas do Siloscape e disseram que as evidências apontam para a campanha ter sido lançada há mais de um ano.

Prizmant determinou a data de início da campanha – 12 de janeiro de 2020 – coletando a data de criação do servidor de onde ela está vindo. Isso não significa necessariamente que o Siloscape foi criado naquela data, observou ele; em vez disso, é provável que tenha começado a campanha de malware.

Depois de uma engenharia reversa particularmente árdua, Prizmant conseguiu se conectar ao servidor de comando e controle (C2) do Siloscape, onde descobriu que estava hospedando um total de 313 usuários. Isso implica que o Siloscape é “uma pequena parte de uma campanha mais ampla”, observou ele.

Como Siloscape Escapes

O malware começa tendo como alvo vulnerabilidades conhecidas – “1 dia” – em aplicativos de nuvem comuns, como servidores da web. Esse acesso inicial é presumivelmente obtido usando exploits encontrados na natureza. No ano passado, Prizmant documentou uma maneira de quebrar os limites do contêiner do Windows. Em um relatório publicado em 2020, ele descreveu o que os invasores poderiam fazer se escapassem de um contêiner.

Ele optou por se concentrar no cenário atual: uma fuga de um nó de cluster do Windows no Kubernetes que permitiria a um invasor obter acesso fora do nó e se espalhar pelo cluster.

Fluxo de execução do Siloscape. Fonte: Unidade 42

Depois de comprometer os servidores da Web, o Siloscape usa táticas de escape do contêiner para obter a execução do código no nó do Kubernetes. Prizmant disse que o uso intenso de ofuscação pelo Siloscape tornava a engenharia reversa uma tarefa árdua. “Quase não há strings legíveis em todo o binário. Embora a lógica da ofuscação em si não seja complicada, a reversão desse binário é frustrante ”, explicou ele.

O malware ofusca funções e nomes de módulos – incluindo APIs simples – e apenas os desofusca em tempo de execução. Em vez de apenas chamar as funções, o Siloscape “se esforçou para usar a versão Native API (NTAPI) da mesma função”, disse ele. “O resultado final é malware que é muito difícil de detectar com ferramentas de análise estática e frustrante para fazer engenharia reversa.”

“O Siloscape está sendo compilado exclusivamente para cada novo ataque, usando um único par de chaves”, Prizmant continuou. “A chave codificada torna cada binário um pouco diferente do resto, o que explica por que não consegui encontrar seu hash em lugar nenhum. Também torna impossível detectar o Siloscape apenas por hash. ”

O que o Siloscape faz após o escape

Depois que o Siloscape compromete os nós, o malware busca as credenciais que permitem que ele se espalhe para outros nós no cluster do Kubernetes. Em seguida, ele alcança seu servidor C2 via IRC – um protocolo antigo – pela rede de comunicação anônima Tor e fica inativo, esperando por comandos.

Prizmant adotou um nome de usuário que ele imaginou que pareceria legítimo quando se conectasse ao servidor C2. Depois de se conectar com sucesso, ele descobriu que ainda estava funcionando e que havia 23 “vítimas ativas”, além de uma operadora de canal chamada admin.

Mas sua presença não passou despercebida. Após cerca de 2 minutos, ele foi expulso do servidor. Dois minutos depois disso, o servidor foi encerrado – pelo menos, não estava mais ativo no oniondomínio original que ele usava para se conectar.

Mas essa foi apenas uma fatia de toda a campanha. Na verdade, ele viu que no canal #WindowsKubernetes que acessou havia muito mais do que aqueles 23 usuários. Na verdade, havia um total de 313 usuários. Ele não seria capaz de identificar, contatar ou avisar qualquer um deles, no entanto.

“Infelizmente, quando me conectei ao servidor, a lista de canais estava vazia, indicando que o servidor foi configurado para não revelar seus canais”, escreveu Prizmant. “Portanto, não consegui obter mais informações sobre os nomes dos canais.”

Mas o pesquisador conseguiu recolher um detalhe importante. Ou seja, a convenção usada para os nomes das vítimas. Os pesquisadores da Unit 42 usaram o nome “php_35”, que sua amostra do Siloscape executou por meio de uma instância php vulnerável. Outros nomes que incluem a string “sqlinj” indicam que o invasor provavelmente conseguiu executar a execução do código por meio de injeção de SQL .

Perigo de roubo de criptografia, envenenamento da cadeia de suprimentos e muito mais

Em sua postagem de julho de 2020, Prizmant disse que sua pesquisa sugeria que “executar qualquer código em [Windows Server Containers] deve ser considerado tão perigoso quanto executar admin no host. Esses contêineres não são projetados para sandbox e descobri que é fácil escapar deles. ”

Isso pode permitir que um invasor roube credenciais críticas, arquivos confidenciais e internos, ou mesmo bancos de dados inteiros hospedados no cluster, ele alertou na postagem de segunda-feira. Pode até levar a um ataque de ransomware se os invasores tomarem os arquivos de uma organização como reféns. Pior ainda, disse ele, é a ameaça apresentada pela mudança em massa das organizações para a nuvem. Considerando que muitos estão usando clusters Kubernetes para desenvolver e testar códigos, uma violação “pode levar a ataques devastadores à cadeia de suprimentos de software”, disse ele.

Na postagem de segunda-feira, dia 07 de junho, ele explicou que comprometer um cluster inteiro é muito mais grave do que comprometer um contêiner individual, visto que “um cluster pode executar vários aplicativos em nuvem, enquanto um contêiner individual geralmente executa um único aplicativo em nuvem“.

Ele observou que o Siloscape não é como a maioria dos malwares em nuvem, que normalmente se concentra no sequestro de recursos para coisas como criptomineração e DoS. O Siloscape, por outro lado, “não se limita a nenhum objetivo específico”, disse Prizmant. “Em vez disso, ele abre uma backdoor para todos os tipos de atividades maliciosas.”

Ataques recentes na cadeia de suprimentos e Kubernetes

Ataques à cadeia de suprimentos semelhantes aos que Prizmant alertou têm sido associados à instalação de spyware , à Operação SignSight, ao comprometimento do Able Desktop, às violações de companhias aéreas e ao maior de todos eles: a violação SolarWinds do governo dos EUA.

No que diz respeito a outras catástrofes do Kubernetes, algumas manchetes recentes incluem um bug de segurança de abril de 2021 que permitiu aos invasores bloquear os clusters do Kubernetes : uma vulnerabilidade em uma das bibliotecas Go nas quais o Kubernetes se baseia e que pode levar à negação de serviço (DoS) para os motores de contêiner CRI-O e Podman. No início de abril, uma campanha organizada e autopropagada de criptomineração foi descoberta, direcionada a portas de API Docker Daemon abertas e mal configuradas. Milhares de tentativas de comprometimento de contêineres estavam sendo observadas todos os dias relacionadas à campanha.

Também em abril, a tecnologia de contêiner em nuvem da Microsoft, Azure Functions, foi descoberta para abrigar uma fraqueza que permite que os invasores gravem diretamente em arquivos, disseram os pesquisadores. Alguns meses antes, em fevereiro de 2021, um novo malware estava sequestrando os clusters do Kubernetes para o criptomine Monero .

Outro exemplo de por que a infraestrutura em nuvem precisa de segurança forte, um honeypot de contêiner Docker simples foi usado para quatro campanhas criminosas diferentes no período de 24 horas, em um teste de laboratório recente .

Ter seu bolo de nuvem e comê-lo também

Trevor Morgan, gerente de produto da empresa de segurança de dados corporativos comforte AG, acha que o Siloscape é o tipo de ameaça que pode deixar as organizações nervosas quanto à adoção da nuvem. “As empresas adotam estratégias nativas da nuvem porque desejam acelerar sua capacidade de inovação. Infelizmente, a maioria das organizações luta com o nível certo de segurança de dados para evitar o comprometimento com arquiteturas de aplicativos nativos da nuvem ”, disse ele ao Threatpost por e-mail na segunda-feira dia 07.

“Malware como o Siloscape complica esse esforço ao atingir o núcleo da conteinerização e cria uma hesitação real por parte dos esforços de desenvolvimento nativo da nuvem, ameaçando desacelerar esses processos e derrotar a agilidade que essas organizações buscam”, ressaltou. “As ameaças de malware configuram uma falsa escolha entre ser ágil e ser cauteloso e seguro com dados confidenciais.”

Morgan sugeriu que a segurança centrada em dados, como a tokenização, construída especificamente para aplicativos nativos em nuvem, “pode ajudar a encontrar o equilíbrio certo entre esses dois”, protegendo os próprios dados em vez de “as fronteiras em camadas, até mesmo amorfas, que cercam os ambientes de aplicativos nativos em nuvem”.

“As organizações podem ter certeza de que a segurança dos dados não impede a velocidade e a agilidade, porque as informações confidenciais tokenizadas, mesmo em contêineres, não podem ser comprometidas se caírem em mãos erradas”, disse ele. “Organizações que adotam estratégias nativas da nuvem podem ter sua segurança de dados ao mesmo tempo em que obtêm agilidade.”

O que fazer

Prizmant recomendou que os usuários sigam o conselho da Microsoft para não usar contêineres do Windows como um recurso de segurança. Em vez disso, a Microsoft recomenda o uso estritamente de contêineres Hyper-V para qualquer coisa que dependa da conteinerização como limite de segurança, observou ele. ” Qualquer processo em execução em contêineres do Windows Server deve ser considerado como tendo os mesmos privilégios de administrador no host, que neste caso é o nó Kubernetes. Se você estiver executando aplicativos em contêineres do Windows Server que precisam ser protegidos, recomendamos mover esses aplicativos para contêineres do Hyper-V ”, disse ele.

A configuração segura de clusters Kubernetes também é crucial. “Um cluster protegido do Kubernetes não será tão vulnerável a esse malware específico, pois os privilégios dos nós não serão suficientes para criar novas implantações. Nesse caso, o Siloscape sairá ”, disse Prizmant.

“O Siloscape nos mostra a importância da segurança do contêiner, já que o malware não seria capaz de causar nenhum dano significativo se não fosse pelo escape do contêiner”, escreveu ele. “É fundamental que as organizações mantenham um ambiente de nuvem bem configurado e seguro para se proteger contra essas ameaças.”