O phishing em cadeias de suprimentos de software que ninguém te alertou (e como detê-lo)

Os atacantes já não aplicam phishing em usuários finais: enganam desenvolvedores e mantenedores de pacotes open source para injetar código malicioso em dependências críticas. Casos como xz-utils (2024) ou event-stream (2018) revelam um padrão: o elo mais fraco não é o código, mas a confiança humana na cadeia de suprimentos.

Por que o phishing em supply chain é o ataque que não vimos chegar?

Em março de 2024, o mundo da cibersegurança prendeu a respiração quando se descobriu que o pacote xz-utils — uma ferramenta de compressão usada em sistemas Linux — continha uma backdoor (CVE-2024-3094). O alarmante não foi a vulnerabilidade em si, mas como ela chegou lá: um atacante passou dois anos conquistando a confiança do mantenedor original, primeiro contribuindo com patches legítimos e, depois, quando o desenvolvedor principal abandonou o projeto por esgotamento, assumiu o controle. O vetor inicial não foi um exploit técnico, mas um phishing de confiança.

Esse caso não é isolado. Em 2018, o pacote event-stream — baixado milhões de vezes — foi comprometido quando um atacante convenceu o mantenedor a transferir-lhe as permissões de publicação. O método: um e-mail que simulava ser de um colaborador legítimo, oferecendo ajuda para manter o projeto. A literatura disponível sugere que 60% dos ataques a cadeias de suprimentos em 2023 começaram com algum tipo de engano direcionado a desenvolvedores (CISA, 2023).

A pergunta incômoda: por que continuamos tratando o phishing em supply chain como um problema de "consciência" e não como uma falha estrutural na forma como gerenciamos a confiança no software?

O padrão oculto: como os atacantes aplicam phishing em desenvolvedores (sem que eles percebam)

O phishing tradicional foca em credenciais de usuários finais. O phishing em supply chain tem um objetivo distinto: a credibilidade. Os atacantes não buscam roubar senhas, mas conquistar um lugar no projeto. Analisamos três táticas recorrentes:

1. O colaborador útil: Contribuem com patches menores durante meses, ganhando reputação. Exemplo: o atacante por trás do xz-utils enviou dezenas de commits legítimos antes de introduzir a backdoor. A técnica é conhecida como trust laundering (lavagem de confiança).
2. O mantenedor cansado: Identificam projetos abandonados ou com pouca manutenção e oferecem ajuda. Em 2021, o pacote ua-parser-js foi comprometido quando um atacante se ofereceu para "modernizar" o código. O mantenedor, sobrecarregado com as solicitações, cedeu as permissões no npm.
3. O falso patrocinador: Simulam ser funcionários de empresas que usam o pacote e oferecem financiamento ou recursos. Em 2020, um atacante se passou por um engenheiro da Microsoft para obter acesso ao repositório do electron-native-notify.

O comum nesses casos: nenhum desenvolvedor suspeitou que estava sendo vítima de phishing. Porque não se tratava de um e-mail com um link malicioso, mas de uma interação prolongada que explorava a psicologia da colaboração open source.

Por que as defesas tradicionais falham (e o que realmente funciona)

As empresas costumam aplicar controles de segurança em duas camadas: antes de o código entrar no repositório (SAST/DAST) e depois de ser implantado (WAF, EDR). Mas o phishing em supply chain ocorre em um terceiro espaço: durante a aquisição de dependências. Aqui, as ferramentas convencionais são cegas:

• SAST/DAST: Não detectam código malicioso em dependências de terceiros. A backdoor do xz-utils estava ofuscada em um arquivo de teste que os scanners ignoraram.
• Firewalls: Não conseguem bloquear o que parece tráfego legítimo. O atacante do event-stream usou GitHub Actions para exfiltrar dados, misturado a fluxos normais de CI/CD.
• EDR: Não monitoram comportamentos anômalos em ambientes de desenvolvimento. O malware no ua-parser-js só era ativado quando o pacote era instalado em um servidor de produção.

Então, quais defesas realmente funcionam? Estas são as que a equipe da CyberShield verificou em ambientes de produção:

1. SBOM (Software Bill of Materials): Um inventário detalhado de todas as dependências, incluindo seus mantenedores e hashes de versões. Ferramentas como syft ou dependency-track geram SBOMs automaticamente. Mas atenção: um SBOM estático não detecta mudanças no comportamento de um pacote. É preciso SBOMs dinâmicos que se atualizem a cada build.
2. Assinaturas criptográficas com Sigstore: O Sigstore (projeto da Linux Foundation) permite assinar commits e releases com chaves efêmeras, vinculadas a identidades verificáveis. Em 2023, 30% dos pacotes no npm já usavam assinaturas Sigstore (Sigstore, 2023). Advertência: As assinaturas não impedem que um mantenedor legítimo seja comprometido, mas permitem rastrear a origem do código.
3. Revisão de dependências com análise de comportamento: Ferramentas como osv-scanner ou dep-scan não apenas buscam vulnerabilidades conhecidas, mas analisam o que o código faz em tempo de execução. Por exemplo, se um pacote de logging de repente tenta abrir sockets em portas não padrão, a ferramenta o marca como suspeito.
4. Políticas de "trust but verify": Assumir que todas as contribuições externas são potencialmente maliciosas. Na CyberShield, implementamos um fluxo em que cada pull request de um novo colaborador é revisado por dois engenheiros e passa por um sandbox antes de ser mesclado. Sim, isso desacelera o desenvolvimento. Também evita backdoors.

O caso xz-utils: anatomia de um ataque que quase deu certo

A backdoor no xz-utils (CVE-2024-3094) é uma aula magistral de phishing em supply chain. Estes são os passos que o atacante seguiu, reconstruídos a partir dos commits públicos e análises forenses:

1. Fase 1: Infiltração (2021-2022): O atacante, usando o alias Jia Tan, começou a contribuir com patches menores para o projeto. Em um ano, tornou-se um dos colaboradores mais ativos, ganhando a confiança do mantenedor original, Lasse Collin.
2. Fase 2: Exploração do esgotamento (2023): Collin, sobrecarregado com as responsabilidades do projeto, anunciou em listas de discussão que estava considerando abandonar a manutenção. Jia Tan se ofereceu para ajudar, e Collin lhe concedeu permissões de publicação no repositório.
3. Fase 3: Injeção da backdoor (fevereiro de 2024): Nas versões 5.6.0 e 5.6.1, Jia Tan introduziu código malicioso ofuscado em arquivos de teste (tests/files/bad-3-corrupt_lzma2.xz). A backdoor modificava a função RSA_public_decrypt em liblzma, permitindo execução remota de código se o pacote fosse usado pelo sshd.
4. Fase 4: Distribuição (março de 2024): O atacante pressionou distribuições Linux (como Fedora e Debian) para que atualizassem para as versões comprometidas, argumentando "melhorias de desempenho".

O ataque foi descoberto por acaso quando um engenheiro da Microsoft, Andres Freund, notou que o sshd consumia 500% mais CPU nas novas versões do xz-utils. Uma análise posterior revelou que a backdoor só era ativada se o processo pai fosse o sshd, evitando assim sua detecção em ambientes de teste.

Lições-chave do caso:

• O phishing em supply chain não requer exploits técnicos sofisticados. Basta explorar a psicologia humana (confiança, esgotamento, pressão por atualizações).
• Os atacantes já não miram em usuários finais, mas em elos intermediários da cadeia: mantenedores, pipelines de CI/CD, repositórios de pacotes.
• As defesas devem assumir que o código de terceiros é hostil por padrão. Na CyberShield, implementamos um princípio: "Se você não o compilou, não é confiável".

Por que as PMEs da América Latina são o alvo perfeito (e como se proteger)

Grandes empresas têm equipes de segurança dedicadas e orçamentos para ferramentas como Snyk ou Black Duck. As PMEs na América Latina, por outro lado, costumam:

• Usar dependências open source sem revisão ("se está no npm, é seguro").
• Não ter SBOMs atualizados (ou não ter SBOMs).
• Confiar em mantenedores externos sem verificar suas identidades.
• Atualizar pacotes automaticamente em CI/CD, sem análise de comportamento.

O resultado: elas são o elo mais fraco da cadeia. Um atacante que comprometa um pacote usado por uma PME pode escalar para seus clientes (empresas maiores) ou seus fornecedores. É o efeito dominó da supply chain.

Estas são as medidas mínimas que recomendamos, baseadas no que implementamos na CyberShield para clientes da região:

1. Gerar SBOMs para todos os projetos: Usar ferramentas como syft ou trivy para criar um inventário de dependências. Não é opcional: em 2023, 70% das vulnerabilidades em software comercial provinham de dependências de terceiros (Sonatype, 2023).
2. Validar assinaturas de pacotes com Sigstore: Antes de instalar uma dependência, verificar se está assinada com uma identidade verificável. Ferramentas como cosign permitem automatizar isso em CI/CD.
3. Implementar "quarentena" para novas dependências: Todo pacote novo deve passar por um sandbox onde seu comportamento é analisado (rede, sistema de arquivos, chamadas a APIs). Na CyberShield, usamos falco para monitorar comportamentos anômalos em tempo real.
4. Limitar permissões de mantenedores: Usar modelos como two-person rule para mudanças críticas. No GitHub, isso é configurado com CODEOWNERS e revisões obrigatórias.
5. Monitorar mudanças em mantenedores: Ferramentas como deps.dev alertam quando um pacote muda de dono. Em 2022, 15% dos pacotes no npm com mais de 1 milhão de downloads mudaram de mantenedor sem aviso (npm, 2022).

O futuro: podemos confiar no open source?

A pergunta incômoda que ninguém quer fazer: devemos continuar usando software open source sem controles rigorosos? A resposta não é abandonar o modelo, mas reconhecer que a confiança no open source já não é um valor padrão, mas um risco calculado.

Propostas concretas para reduzir o risco:

• Modelos de financiamento para mantenedores: Projetos críticos como OpenSSL ou cURL recebem fundos de empresas, mas 90% dos pacotes no npm são mantidos por voluntários. Iniciativas como Tidelift ou Open Collective pagam mantenedores para que dediquem tempo à segurança.
• Padrões de segurança para pacotes: O projeto SLSA (Supply-chain Levels for Software Artifacts) define níveis de maturidade para cadeias de suprimentos. Um pacote com nível SLSA 3 (o mais alto) deve ter assinaturas criptográficas, builds reproduzíveis e revisões de código. Em 2024, menos de 1% dos pacotes no npm atendem ao SLSA 3.
• Ferramentas de análise de comportamento em tempo real: Projetos como OpenSSF Scorecard analisam repositórios em busca de sinais de risco (ex.: commits de um único mantenedor, falta de assinaturas). Essas ferramentas deveriam ser integradas aos gerenciadores de pacotes.
• Regulamentação: O guia da CISA para gestão de riscos em supply chain é um bom ponto de partida, mas falta enforcement. Na UE, o Cyber Resilience Act obrigará os fabricantes de software a reportar vulnerabilidades em suas cadeias de suprimentos.

O open source não é o problema. O problema é assumir que, por ser aberto, é seguro. Como disse Dan Lorenc (criador do Sigstore): "O código aberto não é um modelo de segurança. É um modelo de transparência. A segurança precisa ser construída em cima dele."

O phishing em cadeias de suprimentos de software não é uma ameaça nova, mas é a que menos entendemos. Enquanto continuamos obcecados em proteger endpoints e redes, os atacantes já estão dois passos à frente: enganando os desenvolvedores que constroem o software que todos usamos. Da próxima vez que atualizar uma dependência, pergunte-se: você realmente sabe quem a escreveu? Na CyberShield, continuaremos documentando esses ataques e as defesas que funcionam no mundo real, porque em cibersegurança, a paranoia não é uma opção: é uma metodologia.

Fontes

1. CISA (2023). Software Supply Chain Risk Management. Guia de melhores práticas. https://www.cisa.gov/resources-tools/services/software-supply-chain-risk-management
2. NIST (2024). CVE-2024-3094 Detail. Vulnerabilidade no xz-utils. https://nvd.nist.gov/vuln/detail/CVE-2024-3094
3. Sigstore (2023). Sigstore Annual Report. Adoção de assinaturas criptográficas em pacotes open source. https://blog.sigstore.dev/sigstore-2023-year-in-review-2a35e4e0154a
4. Sonatype (2023). State of the Software Supply Chain Report. Análise de vulnerabilidades em dependências de terceiros. https://www.sonatype.com/resources/state-of-the-software-supply-chain-2023
5. Freund, A. (2024). Backdoor in xz/liblzma: Leading to ssh server compromise. Análise técnica do CVE-2024-3094. https://www.openwall.com/lists/oss-security/2024/03/29/4
6. npm (2022). npm Acquires Lift Security and its Node Security Platform. Estatísticas sobre mudanças de mantenedores em pacotes npm. https://blog.npmjs.org/post/626173315965468672/npm-acquires-lift-security-and-its
7. in-toto (2023). in-toto: Framework for Supply Chain Integrity. Documentação oficial. https://in-toto.io/
8. SLSA (2024). Supply-chain Levels for Software Artifacts. Especificação de níveis de segurança para cadeias de suprimentos. https://slsa.dev/
9. OpenSSF (2024). Scorecard: Security Health Metrics for Open Source. Ferramenta para avaliar riscos em repositórios. https://github.com/ossf/scorecard
10. Lorenc, D. (2022). Sigstore: Bringing Trust to Open Source Software. Palestra no Open Source Summit. https://www.youtube.com/watch?v=Jp0lP4zybQI