Recentemente, observamos uma implementação de payload interessante usando o Metasploit Framework (MSF) em APIs do Docker expostas.

Por David Fisher e Alfredo Oliveira

 

Discutimos a importância de manter as APIs do Docker seguras em artigos anteriores, pois deixá-las expostas pode dar aos cibercriminosos acesso irrestrito ao host com privilégios de root. Esse acesso pode levar a ataques de DDoS, execução remota de código (RCE) e atividade de mineração não autorizada de criptomoedas.

Este ataque ativo, usando o Metasploit Framework (MSF), envolve a implantação do shellcode do Metasploit como um payload, e este é o primeiro ataque que vimos que usa o MSF contra o Docker. Ele também utiliza uma imagem de base pequena e sem vulnerabilidade para que o ataque prossiga de maneira rápida e furtiva.

 

Análise técnica

Uma das primeiras coisas que notamos é o uso de “alpine:latest” pelos invasores como sua imagem de contêiner de base. Além de ser conhecido por seu pequeno tamanho, a Snyk não detectou nenhuma vulnerabilidade na imagem, permitindo que os invasores passassem por verificações destinadas a sinalizar o uso de imagens vulneráveis. A Snyk fornece serviços de varredura de segurança, incluindo código-fonte aberto e contêineres.

Figura 1: Uma varredura Snyk da imagem alpine retornando com zero vulnerabilidades

 

Descobrimos que a maioria dos ataques mais recentes a nossos honeypots de contêiner estão se aproveitando de imagens de base bem conhecidas e estabelecidas. Isso permite que eles contornem a checagem de malwares e vulnerabilidades.

Também vimos que os comandos executados seguem a codificação Base64 em oposição à codificação de texto simples mais tradicional, uma tendência na cena de malwares de Linux que mencionamos em um artigo anterior. O contêiner é executado com sinalizadores privilegiados, o que significa que o payload tem privilégios root do host.

Figura 2. A implantação do contêiner malicioso mostrando os privilégios root

Figura 3. O invasor usa uma imagem de base estabelecida e coloca o arquivo malicioso como comandos codificados em texto Base64

 

Por fim, a observação mais interessante diz respeito ao próprio payload. Conforme mostrado na captura de tela da Figura 4, todo o payload é compactado em um arquivo pequeno usando a codificação Base64. Quando o decodificamos, obtivemos um arquivo em formato de link executável (executable link format ou ELF) com um tamanho minúsculo de apenas 250 bytes.

Figura 4. O payload do arquivo ELF de 250 bytes implantado

 

Uma análise posterior revelou que o payload não foi escrito em nenhuma linguagem de programação de alto nível, mas em puro código assembly. Como tal, não há instruções em excesso que requerem processamento, permitindo uma codificação Base64 muito pequena para realizar o trabalho necessário para executar o código. No entanto, a motivação pode ser mais simples do que isso, por exemplo, o limite do número de caracteres presentes na linha shell.

O payload implementado primeiro aloca uma página de memória de 4.096 bytes com os sinalizadores de proteção “PROT_READ,” “PROT_WRITE” e “PROT_EXECUTE”. Esses sinalizadores permitem que os invasores rodem código dentro desta parte da região da memória.

Figura 5. A conexão com o servidor de comando e controle (C&C) para execução de comando malicioso

 

O soquete TCP é então aberto de dentro do sistema e a conexão é iniciada com o servidor C&C. Isso é evidenciado pela estrutura “sockaddr” codificada.

Figura 6. Obtendo um shellcode executável

 

Um “read syscall” é executado em um descritor de socket aberto, e então irá ler até 126 bytes do servidor C&C. Estes são salvos dentro da região de memória alocada mencionada anteriormente e então executados.

Esta técnica notável é uma reminiscência do comportamento do shellcode, então nós a examinamos e descobrimos que o arquivo ELF é um shellcode Metasploit reverse_tcp compilado. É um arquivo ELF x64 simples com o IP e a PORT do invasor codificados no binário. Apesar de não ter sido ofuscado, o hash do arquivo não foi encontrado em nenhuma plataforma online de ameaças no momento da escrita.

Como havia uma indicação de que era um arquivo reverse_tcp gerado pelo MSF, criamos uma prova de conceito que falsifica o IP do invasor de um contêiner e executa o backdoor em um ambiente seguro para obter o shell reverso.

Figura 7. O MSF com IP falsificado ouvindo na porta 4444 para obter uma conexão reversa

 

Figura 8. O backdoor em execução em um ambiente de contêiner seguro

 

Figura 9. Uma sessão MSF aberta com um shell reverso

 

Conclusão

APIs do Docker expostas se tornaram alvos predominantes para invasores, pois permitem que eles executem seu próprio código malicioso com privilégios de root em um host alvo. Embora tenhamos visto principalmente implantações de mineração de criptomoedas em ataques que abusam de APIs do Docker expostas no passado, este ataque recente indica que técnicas mais furtivas estão entrando no cenário. Também esperamos que os invasores implantem ameaças mais avançadas em um futuro próximo.

Em dois anos monitorando nossos honeypots, esta é a primeira vez que vimos um ataque que usa um exploit MSF imediatamente. É importante observar que, devido à configuração do nosso honeypot, o invasor não teve muito tempo para realizar novos ataques. Isso significa que não podemos concluir qual é a principal motivação dos agentes maliciosos com este ataque específico. Continuamos monitorando os indicadores de comprometimento (IOCs) e forneceremos atualizações com base em novas descobertas e análises futuras.