Pesquisadores de segurança descobriram malware baseado em Go sendo distribuído através de dois módulos Go e dois provedores Terraform hospedados no registro centralizado da HashiCorp — a primeira vez que atores de ameaça usam esse repositório como vetor de distribuição para cargas maliciosas. A descoberta marca um novo ponto de vulnerabilidade em cadeias de suprimento de infraestrutura como código (IaC).
A tática é preocupante porque provedores Terraform e módulos Go são componentes confiáveis que infraestruturas inteiras dependem. Quando comprometidos, podem injetar malware em centenas ou milhares de ambientes de produção sem que os administradores percebam de imediato.
Quais Provedores e Módulos Foram Comprometidos?
De acordo com a Aikido, os pacotes maliciosos identificados incluem:
- gocommunity-io/dockerd (222 downloads)
- kreuzwenker/ (números de download ainda sendo contabilizados)
Ambos foram hospedados no Terraform Registry oficial e no repositório Go central. O baixo número de downloads em um caso não diminui a gravidade — basta um único download em ambiente crítico para que a infecção se propague.
A Aikido notificou a HashiCorp sobre os pacotes maliciosos, e eles foram removidos do registro público. No entanto, qualquer organização que tenha puxado essas dependências entre o momento da publicação e a remoção pode estar comprometida sem saber.
Como o Malware Go Age nos Ambientes Terraform
Quando um provedor Terraform malicioso é carregado durante a inicialização de infraestrutura (terraform init), o código Go malicioso é executado com os mesmos privilégios do usuário ou da conta de serviço que roda o Terraform. Isso significa acesso potencial a:
- Credenciais armazenadas em variáveis de ambiente
- Chaves SSH e tokens de autenticação
- Dados sensíveis em arquivos de estado do Terraform
- Conectividade de rede para comunicação com command-and-control (C2)
O ataque aproveita a confiança implícita que desenvolvedores e engenheiros de infraestrutura depositam em repositórios oficiais. Diferentemente de dependências de aplicação, provedores Terraform são frequentemente revisados apenas por política, nunca por análise manual de código.
Impacto em Cadeias de Suprimento de IaC
A infraestrutura como código se tornou o padrão ouro para deploy e gerenciamento de nuvem. Terraform é a ferramenta mais usada no mercado. Comprometer provedores Terraform é atacar a fundação sobre a qual ambientes inteiros são construídos.
| Vetor Anterior | Vetor Novo | Risco | |—|—|—| | Dependências de aplicação (pip, npm, Maven) | Provedores Terraform e módulos Go | Execução durante deploy de infraestrutura | | Comprometimento de uma app | Comprometimento de toda a infraestrutura | Acesso direto a chaves, secretos, dados | | Detecção por análise de código | Difícil de auditar sem revisão manual | Propagação antes da descoberta |
Eventos anteriores como o SolarWinds e o ataque à cadeia de suprimento do Codecov provaram que repositórios centralizados são alvo prioritário. O registro Terraform, por estar associado a infraestrutura crítica, é um prêmio ainda mais valioso.
Recomendações Práticas para Proteção
1. Revise Histórico de Dependências
Se sua organização usa Terraform, revise seus arquivos de configuração e logs de terraform init para identificar qual versão de provedores foi usada. Ferramentas de auditoria de IaC podem acelerar esse processo.
2. Implemente Verificação de Integridade
Use hash de provedor (terraform get -update com verificação de checksum) e, quando possível, espelhe provedores em repositório privado com aprovação antes de uso em produção.
3. Monitore Execução de Terraform
Configure logs e alertas para quando terraform init, terraform apply ou terraform plan rodarem em ambiente crítico. Desvios de padrão normal podem indicar uso de dependência comprometida.
4. Segregue Permissões de Provedor
Implemente princípio de menor privilégio: contas de serviço que rodam Terraform devem ter apenas as permissões necessárias para seus recursos específicos, não acesso amplo a credenciais ou segredos.
Por Que o Terraform Registry Estava Vulnerável?
O Terraform Registry não implementa verificação de autoria tão rigorosa quanto repositórios como npm ou PyPI. Qualquer um com conta HashiCorp pode publicar provedores públicos sem processo de revisão obrigatório ou sandbox de execução.
A HashiCorp começou a reforçar validação com o programa de “Verificação de Parceiros” (Partner Verification), mas ainda há espaço para provedores não verificados. A responsabilidade cai em grande parte sobre os usuários.
Perguntas Frequentes
P: Meu Terraform já foi executado com essas versões. Como sei se fui comprometido?
R: Procure em logs de sistema por conexões de rede incomuns, criação de processos filhos não esperados ou variáveis de ambiente lidas durante terraform init. Se disponível, revise registros de cloud provider (AWS CloudTrail, Azure Activity Log) no momento da execução.
P: Posso confiar em provedores “Oficiais” da HashiCorp?
R: Sim, provedores oficiais (aws, google, azurerm) são auditados pela HashiCorp. Risco maior está em provedores comunitários — sempre verifique autor, quantidade de downloads, data da última atualização e reviews.
P: Devo parar de usar Terraform?
R: Não. O problema não é Terraform, mas vigilância insuficiente em repositórios. Use Terraform, mas seja exigente com provedores que inclui e implemente as recomendações acima.
P: Qual é a diferença entre esse ataque e um tradicional de malware?
R: Esse ataque acontece na camada de infraestrutura, não em runtime de aplicação. Ele é executado com privilégios de deploy, podendo tocar em segredos e configurações antes mesmo da aplicação iniciar.
Ferramentas para Validar Infraestrutura e Dependências
Se trabalha com Terraform e quer garantir segurança de dependências, nossa Calculadora de CIDR pode ajudar na validação de sub-redes e planejamento de segmentação. Para quem gerencia múltiplas provedores e quer auditar conectividade, use nosso Verificador de IP para confirmar IPs de saída de seus ambientes Terraform e detectar chamadas suspeitas.
O Que Fazer Agora
- Imediato: Revise provedores Terraform em uso em sua organização
- Curto prazo: Implemente política de aprovação para novos provedores
- Médio prazo: Automatize auditoria de integridade de dependências
- Longo prazo: Considere espelhamento privado de provedores críticos
A confiança em repositórios públicos é prática, mas segurança em supply chain de infraestrutura exige vigilância contínua. Esse incidente não é isolado — é sinal de que ferramentas IaC precisam de atenção de segurança equivalente à de dependências de aplicação.
