A fork bomb nos salvou

O malware presente no LiteLLM 1.82.8 trazia um arquivo .pth que era executado em qualquer inicialização do Python. Ele coletava chaves SSH, credenciais de nuvem, carteiras de criptomoedas e segredos de CI/CD, criptografava tudo com uma chave RSA de 4096 bits e exfiltrava o arquivo compactado para um domínio controlado pelo atacante. O payload era bem construído. A criptografia era sólida. A exfiltração era limpa.¹ Este caso faz parte da minha série sobre segurança de agentes, dedicada às falhas do mundo real que moldam a forma como construímos confiança em sistemas automatizados.⁵

Só que o arquivo .pth também criava um processo filho do Python para fazer o trabalho. Esse processo filho disparava o arquivo .pth de novo. O que criava mais um processo filho. Que disparava tudo outra vez. Uma fork bomb exponencial que consumia 100% da CPU e mais de 5 GB de RAM em questão de segundos.²

A fork bomb era um bug. O atacante não queria que o malware fosse visível. Uma versão implementada corretamente teria rodado em silêncio a cada invocação do Python em cada sistema infectado, possivelmente por semanas. Em vez disso, desenvolvedores perceberam suas máquinas travando, foram investigar e encontraram o ladrão de credenciais. O PyPI colocou as duas versões em quarentena 46 minutos depois da publicação.¹

Quarenta e seis mil instalações em quarenta e seis minutos. O mecanismo de detecção foi um erro de implementação do malware.

Quando a dependência de um agente de IA instala um pacote que contém uma fork bomb, a criação exponencial de processos consome 100% da CPU e vários gigabytes de RAM em segundos, deixando a máquina inutilizável. No incidente do LiteLLM 1.82.8, essa fork bomb acidental foi a única razão pela qual o payload ladrão de credenciais foi detectado: desenvolvedores notaram suas máquinas travando e resolveram investigar. Sem o bug, o malware teria exfiltrado silenciosamente chaves SSH, credenciais de nuvem e carteiras de cripto durante semanas antes de alguém perceber.

Resumo

• O bug: o ladrão de credenciais do LiteLLM 1.82.8 tinha um bug de fork bomb que travava as máquinas infectadas. Sem esse bug, ele teria rodado em silêncio por semanas.
• A lacuna: análise estática, monitoramento comportamental e revisão de código deixaram o ataque passar. Cada camada de detecção presumiu que outra camada pegaria o problema. Nenhuma pegou.³
• A curva: a qualidade do atacante melhora a cada iteração. A técnica do .pth agora está documentada publicamente. O próximo atacante herda a técnica sem o bug.
• O que funciona sem sorte: verificação da idade do domínio no tráfego de saída, linha de base comportamental para instalação de pacotes, iscas no sistema de arquivos, isolamento da instalação. Cada uma funciona independentemente da qualidade do payload.
• A assimetria: quem defende escolhe o ambiente. Se o ambiente de instalação não tem credenciais para roubar, um payload perfeito não colhe nada.

Tivemos sorte

Tire a fork bomb do payload e o ataque é bem-sucedido em silêncio. O arquivo .pth roda antes de qualquer import, antes de qualquer código da aplicação, antes de qualquer isolamento em nível de Python. Não existe ponto de interceptação. Não existe registro em log. O ladrão de credenciais roda, criptografa, exfiltra, e o processo do Python segue normalmente. O desenvolvedor não vê nada. O pipeline de CI não vê nada. O varredor de segurança não vê nada, porque o varredor de segurança era o próprio vetor do ataque.³

A história da detecção do LiteLLM 1.82.8 não é “nosso monitoramento pegou o ataque”. A história da detecção é “o atacante publicou um bug junto”.

Esse não é um alicerce confortável para a segurança da cadeia de suprimentos. Como argumento em o isolamento do seu agente é só uma sugestão, as fronteiras que imaginamos existir entre código confiável e não confiável são bem mais porosas do que a maioria dos times imagina.

A curva de qualidade do atacante

A qualidade do software melhora a cada iteração. Isso vale tanto para quem ataca quanto para quem defende. A campanha do TeamPCP atingiu cinco ecossistemas em uma semana: GitHub Actions, Docker Hub, npm, Open VSX e PyPI.⁴ Cada ecossistema comprometido foi invadido com credenciais colhidas no anterior. A campanha mostrou sofisticação operacional: registro do domínio 24 horas antes da entrega do payload, sequestro de tags em referências mutáveis e evasão da rotação de credenciais por causa de uma troca incompleta de chaves na Aqua Security.

A fork bomb foi o único erro em uma operação competente em todo o restante. A próxima campanha não vai cometer esse erro. A técnica do arquivo .pth já está documentada publicamente, analisada por CrowdStrike, Microsoft, Wiz e Palo Alto.³ O próximo atacante herda a técnica sem o bug.

A capacidade ofensiva segue a mesma curva de evolução da capacidade defensiva. A técnica é pública. A análise é pública. O próximo atacante começa onde o TeamPCP parou. Analiso o que essa curva significa para sistemas autônomos em o que realmente quebra sem supervisão.

A detecção não pode depender dos erros do atacante

O modelo atual de detecção na cadeia de suprimentos tem três camadas, e as três falharam no caso do LiteLLM:

A análise estática não pegou. O arquivo .pth é um recurso legítimo do Python. O payload estava com codificação base64 dupla e era decodificado em tempo de execução. Varredores estáticos que procuram padrões maliciosos conhecidos não encontram nada, porque o padrão é novo.

O monitoramento comportamental não pegou. O ladrão de credenciais fez um único POST HTTPS de saída para um domínio com cara de serviço legítimo (models.litellm.cloud). Um monitoramento de saída que inspeciona domínios de destino precisaria saber que aquele domínio específico havia sido registrado 24 horas antes. A maioria dos monitores de saída não verifica a idade do domínio.

A revisão de código não pegou. As versões maliciosas foram publicadas direto no PyPI, contornando por completo o pipeline de CI/CD do GitHub. Não havia pull request para revisar. Não havia diff para inspecionar. O atacante usou credenciais de publicação roubadas para subir pacotes pré-compilados.

Cada camada de detecção presumiu que outra parte da cadeia do ataque pegaria o problema. Nenhuma pegou. Quem pegou foi a fork bomb.

O que de fato detecta malware silencioso

Se você não pode contar com os erros do atacante, precisa de mecanismos de detecção que funcionem independentemente da qualidade da implementação.

Verificar a idade do domínio nas requisições de saída. O domínio de exfiltração foi registrado 24 horas antes do ataque. Uma regra de firewall que sinaliza requisições de saída para domínios com menos de 7 dias teria pegado o caso. A regra é simples, a taxa de falsos positivos é administrável e ela pega o padrão de exfiltração mais comum.

Linha de base comportamental para processos do Python. Um pip install que de repente começa a fazer POSTs HTTPS para um domínio desconhecido é anômalo. Um monitoramento comportamental em nível de processo que acompanhe a atividade de rede durante a instalação de pacotes sinalizaria isso.

Iscas no sistema de arquivos. Coloque uma chave SSH falsa em um caminho-isca e uma credencial AWS falsa em outro. Monitore qualquer processo que leia esses arquivos. Um ladrão de credenciais que varre os caminhos padrão vai ler as iscas. Um processo legítimo não vai. A isca dispara o alerta antes que a exfiltração termine.

Isolamento da instalação. Rode o pip install em um ambiente sem acesso a credenciais reais. Depois copie os pacotes instalados para o ambiente de produção. O arquivo .pth dispara dentro do próprio processo Python do pip, ou seja, o ladrão de credenciais roda durante a instalação. Se o ambiente de instalação não tem credenciais para roubar, o ataque não colhe nada.

Nenhum desses mecanismos exige que o atacante cometa um erro. Todos funcionam independentemente da qualidade do payload. O padrão arquitetural — projetar ambientes em que até um ataque perfeito não colhe nada — é o mesmo princípio por trás de implantar e defender: o paradoxo da confiança em agentes.

A assimetria

A defesa tem uma vantagem estrutural: quem defende escolhe o ambiente. O atacante precisa trabalhar dentro do ambiente em que o pacote for instalado, seja ele qual for. Se esse ambiente não tem credenciais, não tem acesso à rede e tem iscas no sistema de arquivos, o payload funciona tecnicamente, mas fracassa na prática.

O ataque ao LiteLLM funcionou porque o ambiente de instalação era o mesmo que guardava credenciais de publicação, chaves SSH e tokens de nuvem. A fork bomb era irrelevante para a arquitetura de segurança. Ela foi relevante para a linha do tempo.

Da próxima vez, a fork bomb não vai estar lá. As credenciais vão continuar no mesmo ambiente do gerenciador de pacotes. A pergunta é se você terá mudado o ambiente antes que o próximo atacante entregue um payload sem falhas. Minha análise da arquitetura de agentes Ralph mostra como estruturar sistemas de agentes para que componentes comprometidos não consigam escalar além da sua fronteira de isolamento.

Perguntas frequentes

Por que o atacante não testou a fork bomb?

Fazer o arquivo .pth criar um processo filho é uma escolha de implementação razoável para executar um payload sem bloquear o processo pai. O disparo recursivo vem de uma interação sutil entre o .pth e a inicialização do site.py do Python. É o tipo de bug que aparece em testes de integração, mas não em testes unitários — e autores de malware têm pouca oportunidade de testar integração em ambientes realistas.

A fork bomb poderia ter sido intencional?

Improvável. A fork bomb tornou o malware imediatamente visível, o oposto do objetivo do atacante. Um ladrão de credenciais silencioso que roda por semanas colhe ordens de grandeza a mais de credenciais do que um que é descoberto em 46 minutos.

Verificar a idade do domínio é prático em escala?

Sim. A idade do domínio está disponível via WHOIS ou por APIs de data de registro de DNS. A verificação acrescenta milissegundos de latência por requisição. A maioria das organizações consegue colocar em uma lista de permissões os domínios novos que já conhece.

Fontes