Ataque Supply Chain ao LiteLLM v1.107.0: Envenenamento PyPI e Fuga AWS

O que torna os ataques à cadeia de fornecimento (supply chain attacks) tão letais é o facto de o código malicioso entrar na tua infraestrutura assinado e distribuído por canais oficiais. Quando a versão envenenada v1.107.0 do LiteLLM chegou ao PyPI e ao Docker Hub, milhares de servidores descarregaram o pacote em processos normais de CI/CD, sem disparar qualquer alarme perimetral.

Ao instalar uma biblioteca legítima usada para ligar aplicações a modelos da OpenAI, Anthropic e Amazon Bedrock, servidores de produção entregaram em segundos as credenciais de cloud da AWS e chaves de API secretas aos atacantes.

Na minha experiência a auditar incidentes em produção, o roubo de credenciais cloud resulta rapidamente em faturas de dezenas de milhares de euros por consumo fraudulento de GPUs, exfiltração de bases de dados e paralisação operacional.

No Webxtek Studio, onde desenhamos e protegemos infraestruturas para empresas de cibersegurança e pen-test e plataformas de SaaS empresarial B2B, este incidente confirma as recomendações do nosso artigo-mãe sobre o Alerta CISA, NSA e FBI: Blindagem PHP, Node e Portas Expostas: confiar cegamente em dependências externas sem blindagem perimetral e segregação de privilégios destrói qualquer perímetro em minutos.

Abaixo explico como o exploit usou ganchos do arranque do Python (sitecustomize.py e .pth) e os comandos exatos para purgares a infeção do teu servidor.

1. Da Linha de Montagem ao Interpretador Python: Anatomia do Envenenamento do LiteLLM v1.107.0

Para mitigar o ataque supply chain ao LiteLLM v1.107.0, tens de eliminar imediatamente ambientes virtuais e imagens Docker com esta versão, auditar diretórios site-packages à procura de ficheiros .pth e sitecustomize.py maliciosos, revogar chaves estáticas IAM na AWS, inspecionar chamadas sts:GetCallerIdentity no CloudTrail e migrar pipelines do GitHub Actions para autenticação efémera via OIDC.

Para perceberes porque é que este ataque enganou sistemas automatizados de verificação de código, precisamos de fazer a ponte entre aquela fábrica de ingredientes e a forma como o ecossistema Python e o Docker distribuem software. Quando a tua equipa instala uma biblioteca através do comando pip install litellm ou puxa uma imagem do Docker Hub, o teu servidor descarrega um pacote pré-compilado (chamado Wheel, com extensão .whl) gerado automaticamente pelos servidores de integração contínua do projeto no GitHub. A intrusão na versão v1.107.0 não explorou um erro matemático no código de Inteligência Artificial; explorou uma falha clássica de higiene operacional na gestão de segredos:

Cadeia de Execucao do Ataque Supply Chain ao LiteLLM v1.107.0:
1. Fuga Inicial: Um Personal Access Token (PAT) do GitHub escapa em texto limpo para logs de telemetria de debug.
2. Sequestro de CI/CD: O atacante recolhe o token e injeta um passo malicioso no workflow de release do GitHub Actions.
3. Envenenamento de Artefactos: O pipeline oficial compila e publica o pacote litellm v1.107.0 no PyPI e na tag :latest do Docker Hub.
4. Persistencia Furtiva: O pacote instala os ficheiros distutils-sys.pth e sitecustomize.py dentro da pasta site-packages.
5. Disparo no Arranque: Qualquer invocacao do binario python3 executa o modulo site.py, que corre o codigo do ficheiro .pth.
6. Colheita de Segredos: O payload le ~/.aws/credentials, variaveis de ambiente (.env) e chaves de API (OpenAI, Anthropic).
7. Validacao e Exfiltracao: Os segredos sao enviados para o servidor C2 e testados em menos de 180 segundos na API STS da AWS.

A Engenharia Furtiva: Como Funcionam os Hooks .pth e o sitecustomize.py

No meu dia a dia em produção, quando explico este vetor a engenheiros juniores ou gestores técnicos, a reação habitual é de surpresa: “Mas nós nem sequer chegámos a importar o LiteLLM no nosso código principal, apenas corríamos testes no contentor!”. A brilhante perversidade técnica deste ataque reside na forma como o interpretador CPython arranca ao nível do sistema operativo.

Os atacantes não tocaram numa única linha dos ficheiros .py do LiteLLM para não levantarem suspeitas em revisões de código ou ferramentas de análise estática (SAST). Em vez disso, colocaram dois ficheiros na raiz do diretório site-packages dentro do pacote .whl:

1. Execução Arbitrária via Ficheiros .pth (distutils-sys.pth): Por desenho histórico da linguagem Python, sempre que o binário python ou python3 é iniciado no Linux, o runtime em C inicializa o interpretador e carrega obrigatoriamente o módulo nativo site.py (a menos que passes a flag -S). O módulo site.py varre todos os diretórios de bibliotecas à procura de ficheiros de configuração de caminhos (.pth). A especificação do Python dita uma regra perigosa: se uma linha dentro de um ficheiro .pth começar pela palavra import (ou import\t), o Python não a trata como um caminho de diretório; executa o resto dessa linha como código Python real através da função exec(). Basta colocares import os, sys, base64; exec(base64.b64decode('...')) numa única linha de um ficheiro .pth para que o malware corra de forma invisível sempre que qualquer processo Python arranca na máquina.
2. Interceção Global via sitecustomize.py: Logo após processar os ficheiros .pth, o mesmo módulo site.py tenta fazer import sitecustomize. Ao injetarem um ficheiro sitecustomize.py na pasta site-packages, os atacantes garantiram que, mesmo que o utilizador corresse apenas um comando inocente como python3 -m pip list, pytest ou django-admin, o ladrão de credenciais (infostealer) era executado na memória antes da primeira linha do programa legítimo.

Colheita Cirúrgica e Validação Automatizada no AWS STS

Uma vez em execução na memória RAM do teu servidor ou do teu runner de CI/CD, o payload em Python agiu com precisão cirúrgica para evitar picos de CPU ou alertas de tráfego de rede:

• Varrimento direto ao sistema de ficheiros à procura de ~/.aws/credentials, ~/.aws/config, ~/.git-credentials, ~/.ssh/id_rsa, ~/.ssh/id_ed25519 e ficheiros .env nos diretórios de trabalho.
• Leitura integral do dicionário os.environ em memória RAM, filtrando variáveis críticas como AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, OPENAI_API_KEY, ANTHROPIC_API_KEY, DATABASE_URL e REDIS_URL.
• Pedido HTTP local silencioso ao serviço de metadados de instâncias cloud (http://169.254.169.254/latest/meta-data/iam/security-credentials/) para capturar credenciais temporárias de instâncias EC2 ou nós Kubernetes (EKS) mal isolados.

Como confirmam as análises forenses divulgadas pelo The Hacker News e pela equipa de investigação da Socket.dev, menos de três minutos após os dados chegarem ao servidor de comando e controlo (C2), bots automatizados dispararam chamadas sts:GetCallerIdentity contra a API da AWS para mapear o ARN da conta comprometida e iniciar o abuso imediato de recursos de computação e modelos no Amazon Bedrock.

2. O Contexto do “Black October”: GhostAction, ChainDrop e o Colapso da eMudhra

Se olhares para o incidente do LiteLLM como um caso isolado, vais deixar a porta aberta para o próximo ataque. No terreno, o que estamos a enfrentar neste mês de outubro de 2026 (já batizado nas comunidades de segurança como Black October) é uma ofensiva coordenada contra toda a cadeia de ferramentas de engenharia:

1. A Campanha GhostAction no GitHub Actions: Grupos de atacantes que capturam tokens de programadores deixaram de apagar repositórios ou pedir resgates óbvios. Em vez disso, injetam ficheiros de workflow dissimulados em .github/workflows/ com nomes plausíveis como “Security Audit CI”. Quando o workflow corre num runner oficial, o script faz um despejo da memória RAM do processo trabalhador (/proc/$PID/mem) para extrair todos os segredos de organização (GITHUB_TOKEN, chaves do PyPI, npm e AWS) que foram injetados na máquina virtual.
2. O Verme ChainDrop (Shai-Hulud 2.0) no Ecossistema Node.js/npm: Em paralelo com o PyPI, pacotes populares de IA e Web3 no npm (incluindo bibliotecas ligadas a Tensorlake e SubQuery) foram infetados com scripts preinstall. A evolução técnica do ChainDrop é alarmante: em vez de usar domínios web fixos que as autoridades conseguem bloquear em horas, o malware consulta o estado de smart contracts na rede Ethereum através de gateways RPC públicos para ler dinamicamente o endereço IP atual do servidor de exfiltração.
3. O Colapso Criptográfico da Autoridade eMudhra (emSign) e o Risco no certifi: Para agravar o cenário, a autoridade de certificação raiz eMudhra sofreu uma revogação de emergência devido à emissão de certificados com chaves privadas de baixa entropia. Porque é que isto afeta diretamente o teu Python? Porque o gestor de pacotes pip e a biblioteca requests não usam por defeito a loja de certificados do teu sistema operativo Linux; usam um ficheiro estático (cacert.pem) fornecido pelo pacote Python certifi. Se tens contentores Docker ou ambientes virtuais antigos com versões desatualizadas do certifi que ainda confiam na raiz da eMudhra, um atacante posicionado na rede pode intercetar ligações TLS para o pypi.org (Man-in-the-Middle) e injetar pacotes falsificados durante um simples pip install.

3. Protocolo de Resposta a Incidentes: Expurgo de Ambientes Python, Docker e Rotação na AWS

Se a tua infraestrutura corre aplicações Python, gateways de IA ou pipelines automatizados, não adies esta verificação. Abre o teu terminal e executa esta sequência de cinco fases que implementámos em todos os clusters geridos pelo Webxtek Studio.

Fase 1: Blindagem da Camada TLS do Pip e Verificação Criptográfica de Hashes

Antes de instalares qualquer pacote de substituição, tens de atualizar a cadeia de confiança TLS dos teus ambientes Python para expurgar as raízes comprometidas da eMudhra e forçar a validação criptográfica de pacotes:

# 1. Atualizar os certificados raiz do sistema operativo Linux (Debian / Ubuntu)
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates openssl -y

# 2. Atualizar o pip e o bundle de certificados certifi em todos os ambientes virtuais ativos
for venv_python in /opt/*/venv/bin/python /var/www/*/venv/bin/python; do
    if [ -x "$venv_python" ]; then
        echo "[A BLINDAR TLS] $venv_python"
        "$venv_python" -m pip install --upgrade pip certifi
    fi
done

# 3. Se utilizas o gestor de pacotes rápido uv em produção
uv self update

# 4. Instalar dependências exigindo obrigatoriamente verificação de hash SHA-256 e bloqueando código-fonte arbitrário
pip install --require-hashes --only-binary :all: -r requirements.txt

Fase 2: Caça Forense a Hooks .pth e sitecustomize.py no Sistema de Ficheiros

Como um ficheiro .pth malicioso é executado assim que invocas o binário python3, nunca uses comandos Python ou pip para procurar o malware antes de inspecionares o disco diretamente com ferramentas nativas do Linux (find e grep). Caso contrário, o simples ato de correres pip show litellm vai disparar novamente o roubo de credenciais!

# 1. Auditar o disco com ferramentas nativas C/POSIX (SEM invocar o interpretador Python!)
# Procurar qualquer versão 1.107.0 do LiteLLM nos metadados de dist-info
find / -path "*/site-packages/litellm-1.107.0.dist-info" 2>/dev/null

# 2. Caçar todos os ficheiros .pth no servidor que contenham instruções executáveis ('import ' ou 'exec')
find / -name "*.pth" 2>/dev/null -exec grep -HnE "^(import[[:space:]]|.*exec\(|.*base64)" {} +

# 3. Localizar qualquer ficheiro sitecustomize.py ou usercustomize.py injetado no sistema
find / \( -name "sitecustomize.py" -o -name "usercustomize.py" \) 2>/dev/null -exec ls -la {} +

# 4. Se precisares de executar o Python para diagnóstico num sistema suspeito, passa SEMPRE as flags -I e -S
# (-S desativa o import automático do módulo site.py, bloqueando a execução de ficheiros .pth e sitecustomize.py)
python3 -I -S -c "import sys; print('Interpretador iniciado em modo estrito sem hooks site.py')"

Se encontrares vestígios da versão 1.107.0 ou ficheiros .pth adulterados, não confies num simples pip uninstall: apaga a pasta do ambiente virtual por completo (rm -rf), recria-a de raiz e fixa o LiteLLM numa versão auditada com hash verificado.

Fase 3: Expurgo Total de Camadas Docker e Imutabilidade por Digest SHA-256

Em arquiteturas baseadas em contentores, parar um contentor não elimina as camadas de ficheiros (overlay2) que ficam em cache no nó de alojamento. Executa uma limpeza forense completa:

# 1. Identificar todos os contentores (ativos ou parados) baseados em imagens do LiteLLM
docker ps -a --filter "ancestor=ghcr.io/berriai/litellm" --format "table {{.ID}}\t{{.Image}}\t{{.Status}}"

# 2. Inspecionar se uma imagem em cache contém ficheiros .pth suspeitos sem a executar
for img in $(docker images --format "{{.Repository}}:{{.Tag}}" | grep litellm); do
    echo "=== A auditar imagem: $img ==="
    docker run --rm --network none --entrypoint /bin/sh "$img" -c \
      "find / -name '*.pth' 2>/dev/null -exec grep -H 'import ' {} +"
done

# 3. Destruir imediatamente contentores, imagens locais e caches de build do Docker
docker rm -f $(docker ps -aq --filter "ancestor=ghcr.io/berriai/litellm") 2>/dev/null || true
docker rmi -f $(docker images -q "*litellm*") 2>/dev/null || true
docker builder prune --all --force
docker system prune --all --volumes --force

Nos teus ficheiros docker-compose.yml ou manifestos de Kubernetes, proíbe terminantemente o uso de tags mutáveis como :latest ou :main. Amarra todas as imagens de produção pelo seu resumo criptográfico imutável (@sha256:...):

# Ficheiro: docker-compose.production.yml
services:
  ai-gateway:
    # IMUTÁVEL: O Docker recusa arrancar se um único byte da imagem for alterado no registo remoto
    image: ghcr.io/berriai/litellm@sha256:d8b24ef096e22e847f551c9d81d22e032b4bf3c988df9e8ff5f9e830e0f3bbec
    read_only: true
    tmpfs:
      - /tmp:size=64M,noexec,nosuid,nodev
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL

Fase 4: Contenção na AWS, Revogação de Sessões STS e Auditoria no CloudTrail

Se qualquer máquina ou pipeline onde correu o LiteLLM v1.107.0 tinha chaves da AWS no disco ou nas variáveis de ambiente, assume imediatamente que essas chaves estão na posse dos atacantes. Desativar a chave AKIA... é o primeiro passo, mas atenção a um detalhe técnico que muitos administradores esquecem: se o atacante já usou a tua chave estática para gerar um token temporário via sts:GetSessionToken ou sts:AssumeRole, esse token temporário (ASIA...) continua válido mesmo depois de apagares a chave original!

Executa este protocolo completo no AWS CLI para cortar tanto a chave estática como todas as sessões temporárias ativas:

# Definir o utilizador IAM comprometido
COMPROMISED_USER="svc-litellm-prod"

# 1. Listar e desativar imediatamente todas as Access Keys estáticas do utilizador
for key_id in $(aws iam list-access-keys --user-name "$COMPROMISED_USER" --query 'AccessKeyMetadata[*].AccessKeyId' --output text); do
    echo "[EMERGÊNCIA] A desativar chave IAM: $key_id"
    aws iam update-access-key --user-name "$COMPROMISED_USER" --access-key-id "$key_id" --status Inactive
done

# 2. Injetar uma política inline 'AWSRevokeOlderSessions' para invalidar na hora quaisquer tokens STS temporários emitidos antes deste segundo
CURRENT_UTC=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

cat <<EOF > /tmp/revoke-sessions-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [ "*" ],
      "Resource": [ "*" ],
      "Condition": {
        "DateLessThan": {
          "aws:TokenIssueTime": "${CURRENT_UTC}"
        }
      }
    }
  ]
}
EOF

aws iam put-user-policy \
  --user-name "$COMPROMISED_USER" \
  --policy-name "EmergencyRevokeOlderSTSSessions" \
  --policy-document file:///tmp/revoke-sessions-policy.json

# 3. Auditar o AWS CloudTrail nas últimas 72 horas à procura de reconhecimento (GetCallerIdentity) ou uso fraudulento de LLMs (InvokeModel)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue="$COMPROMISED_USER" \
  --start-time "$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[*].[EventTime,EventName,SourceIPAddress,EventSource]' \
  --output table

Fase 5: Erradicação de Chaves Estáticas via Federação OpenID Connect (OIDC)

A única forma de garantires que nenhum malware em pacotes Python ou npm consegue roubar as tuas chaves estáticas de deploy na AWS é não teres chaves estáticas para roubar. Apaga hoje mesmo as variáveis AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY dos segredos do teu GitHub e configura a federação de identidade nativa via OpenID Connect (OIDC).

Com o OIDC, o GitHub Actions assina um token criptográfico JWT de curta duração para cada execução específica do workflow e troca-o diretamente no AWS STS por uma sessão temporária que expira em 15 minutos, amarrada exclusivamente ao teu repositório e à tua branch de produção:

# Ficheiro: .github/workflows/production-deploy.yml
name: Deploy Blindado Zero-Static-Secrets
on:
  push:
    branches:
      - main

# Permissões restritas segundo o princípio do privilégio mínimo
permissions:
  id-token: write # Indispensável para o runner solicitar o token OIDC assinado pelo GitHub
  contents: read   # Leitura apenas do código-fonte

jobs:
  deploy_infrastructure:
    runs-on: ubuntu-24.04
    timeout-minutes: 15
    steps:
      - name: 1. Checkout Imutável por Hash de Commit (Imune a sequestro de tags)
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: 2. Autenticação Efémera na AWS via Federação OIDC (Zero Chaves no Disco)
        uses: aws-actions/configure-aws-credentials@e3ddf4a3c70b8976a20c47d46e0824a7ffca9a83 # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/WebxtekGitHubOIDCDeployRole
          role-session-name: GitHubActions-Prod-Deploy
          role-duration-seconds: 900 # Sessão expira matematicamente em 15 minutos
          aws-region: eu-west-1
          audience: sts.amazonaws.com

      - name: 3. Instalar Dependências Python com Verificação Estrita de Hashes SHA-256
        run: |
          python3 -m pip install --upgrade pip certifi
          python3 -m pip install --require-hashes --only-binary :all: -r requirements.lock

      - name: 4. Validar Identidade Assumida e Executar Deploy
        run: |
          aws sts get-caller-identity

Repara no detalhe persist-credentials: false no passo de checkout: essa linha impede que o actions/checkout grave o token temporário do GitHub dentro do ficheiro .git/config no disco do runner, neutralizando um dos vetores favoritos da campanha GhostAction.

4. Matriz Comparativa: Pipeline Vulnerável vs. Arquitetura Supply Chain Blindada

Na tabela abaixo contrasto as práticas habituais que permitiram a propagação do ataque ao LiteLLM com o padrão de engenharia defensiva que aplicamos nos sistemas do Webxtek Studio:

Para automatizares a verificação de imagens e a geração de SBOMs na tua pipeline de CI/CD, consulta o nosso guia sobre Cadeia de Contentores: Trivy, SBOM e Cosign. E para auditares continuamente os fluxos de dados e dependências de código antes de irem para produção, implementa a arquitetura descrita em Agentes de Auditoria de Segurança: Arquitetura Caçador e Verificador.

5. Checklist de Sobrevivência para Engenheiros e Líderes Técnicos

Antes de encerrares a tua auditoria interna a este incidente, garante que a tua equipa valida estes cinco pontos:

1. Inspeção Sem Invocação de Python: Confirma com find e grep que não existem ficheiros .pth com instruções import maliciosas nem ficheiros sitecustomize.py desconhecidos em nenhum servidor ou imagem base.
2. Bloqueio de IMDS nos Nós de Contentores: Nos teus clusters AWS EC2 ou EKS onde correm gateways como o LiteLLM, exige obrigatoriamente IMDSv2 e define o limite de saltos (HttpPutResponseHopLimit) para 1, impedindo que contentores alcancem o IP 169.254.169.254.
3. Rotação Total de Segredos de IA e Cloud: Se a versão 1.107.0 passou pelo teu ambiente, regenera hoje todas as chaves da OpenAI, Anthropic, bases de dados e utilizadores IAM, aplicando uma política de negação retroativa para sessões STS antigas.
4. Quarentena de Atualizações (Cooldown de 72 Horas): Nunca atualizes automaticamente dependências de produção no minuto em que saem no PyPI ou no npm; aplica uma janela de quarentena mínima de 72 horas exceto para patches de segurança verificados.
5. Restrição de Tráfego de Saída (Egress Filtering): Configura a tua firewall de saída para que o servidor do LiteLLM consiga comunicar apenas com os endpoints oficiais das APIs de modelos (api.openai.com, api.anthropic.com, bedrock-runtime.*.amazonaws.com), bloqueando qualquer exfiltração de dados para servidores C2 desconhecidos.

Proteger aplicações que integram Inteligência Artificial exige o mesmo rigor arquitetural na cadeia de fornecimento de código que aplicas na blindagem dos teus servidores de produção. No Webxtek Studio, ajudamos equipas tecnológicas a eliminar pontos cegos nos seus ciclos de entrega e operação. Através dos nossos serviços de alojamento gerido de alta segurança, consultoria técnica especializada e arquitetura de cloud infrastructure DevOps, garantimos que a tua infraestrutura se mantém resiliente, auditável e imune a envenenamentos na cadeia de software.