Rust: compromisso da cadeia de abastecimento com arrayref, internment e append-only-vec

O ecossistema de pacotes Rust sofreu uma tentativa de compromisso da cadeia de fornecimento em 20 de agosto de 2026: três versões maliciosas de crates populares foram publicadas e eliminadas em questão de horas após a intervenção da equipe de resposta de segurança de Rust. Crates afetados: arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9, todas publicadas da mesma conta de manutenção e retiradas entre 86 e 107 minutos após sua publicação, segundo os registros oficiais citados pela Rust Security Response Team (RSRT) e o aviso de segurança RUSTSEC-2026-0260.

O que fez especialmente perigosa esta campanha foi o vetor técnico: não foi introduzido código maligno visível nas bibliotecas alvo, mas no programa de compilação de uma dependência typosquatted chamada proc-macro1(imitando a amplamente usada proc-macro2). A livraria em si era uma cópia legítima de proc-macro2 para evitar falhas, mas o seu build script reconstruía um endereço de servidor a partir de fragmentos codificados em base64, desabilitava a verificação TLS instalando um validador que sempre devolve sucesso, descarregava um binário específico por plataforma e o executava durante a fase de compilação. Esse comportamento implica que bastava que Cargo resolvesse e compilara a dependência (por exemplo, com cargo build, cargo check ou cargo teste) para executar o malware, sem necessidade de o código das crates comprometidas ser invocado em tempo de execução.

Os fatos confirmados incluem as marcas de tempo de publicação e eliminação (publicadas pelo RSRT), a presença do build script com o downloadr e o mecanismo de desativação TLS (verificado pelo RSRT e atribuído inicialmente pela Research Team de Nextron Systems GmbH), e os vetores de persistência e comandos do payload em sua segunda etapa (análise pública de Wiz que documenta persistência por Registry Run key no Windows, LaunchAgent no macOS e systemd user service em Linux, e roubo de credenciais de navegadores na amostra Windows). CVE não foi atribuído e, segundo RustSec, não há evidência pública de que as versões maliciosas chegassem a ser amplamente usadas.

Há elementos ainda incertos ou não divulgados: a conta do autor principal - identificada publicamente como droundy em crates.io - parece comprometida e a equipe de segurança tenta contactar o proprietário, mas não foi publicada como ocorreu o compromisso de credenciais. Também não foram fornecidos números oficiais sobre quantas transferências específicas corresponderam às versões eliminadas; The Hacker News consultou a RSRT sobre esses números sem resposta no momento do relatório. Por contraste, os totais históricos de arrayref (suministrados através da API de crates.io) mostram que a crate tem um uso massivo a longo prazo, com dezenas de milhões de downloads em meses recentes, o que sublinha o potencial de impacto se uma versão maliciosa tivesse sido instalada por dependências populares.

Tecnicamente, a entrega combinou duas técnicas conhecidas: typosquatting (proc-macro1 ≈ proc-macro2) e manipulação de versões e Yanks para forçar que Cargo considere atualizar a uma versão não Yanked. Um pesquisador relatou que o autor do pacote havia marcado como Yanked várias versões prévias (0.3.5–0.3.9) no mesmo minuto da publicação maliciosa, de forma que a nova 0.3.10 ficava momentânea como a única versão sem aviso de Yanked para os usuários que recebessem a sugestão de "consider updating". Essa jogada facilitou que projetos com faixas de versão caret em 0.3.x (que aceitariam 0.3.10) resolvessem a versão maliciosa durante a compilação.

Conseqüências práticas: se um projeto —directa ou transitivamente— resolveu a versão maliciosa e se compilou na equipe de desenvolvimento ou na CI, o build script pôde executar o segundo estágio do ataque. O payload documentado realiza persistência, comunicação com um C2 (indicadores públicos apontam para 23.254.165.112:443 e outros portos), e funções de roubo de credenciais de navegadores no Windows. Mesmo que rust-crates não seja executado posteriormente em produção, a execução durante a compilação concede ao atacante controle efetivo sobre o host que compilou a dependência.

O que você deve fazer — verificações e medidas concretas

1) Verifique se o seu ambiente pôde ter compilado as versões envolvidas. Procure na cache local de Cargo por artefatos correspondentes às datas de 20 de agosto de 2026: normalmente em ~/.cargo/registry/cache (Unix/macOS) ou %USERPROFILE%\\.cargo\\registry\\cache (Windows). A equipe de resposta recomenda remover qualquer arquivo de crate removido e voltar a reconstruir dependências de versões seguras. Veja também a página pública do pacote em crates.io para confirmar versões e proprietários: https://crates.io/crates/arrayref.

2) Aísle e elimine artefatos suspeitos. Indicadores de compromisso públicos incluem nomes e rotas como /tmp/rust-setup (Unix/macOS),%TEMP%\\\rust-setup.ps1 e%TEMP%\\rust-setup- launch.vbs (Windows). Se encontrar estes ficheiros, não os execute; preserve cópias para análise se necessário e proceda a uma limpeza e digitalização com ferramentas de EDR/AV.

3) Procure persistência. No Windows, verifique as chaves Run/RunOnce no registo do utilizador e do sistema; no macOS, verifique ~/Library/LaunchAgents e /Library/LaunchDaemons/LaunchAgents; no Linux, enumere unidades systemd --user e ficheiros em ~/.config/systemd/user. Se detectar serviços ou chaves ligados a nomes indicados nos IoC publicados, faça resposta a incidentes completos (se necessário, reimaging).

4) Revise logs de CI e build servers. Se as suas pipelines compilam dependências automaticamente ou runners compartilhados, procure sinais de compilações nas faixas horárias do ataque e URLs/IPs de comunicação (por exemplo, 23.254.165.112). Revise também artefatos gerados em runners e borre caches remotos do registrador de packages se aplicar.

5) Pinnee dependências até versões seguras. RustSec e a comunidade sugerem fixar arrayref a 0.3.9 ou anterior (por exemplo, em Cargo.toml use arrayref = "0.3.9" ou modificar Cargo.lock para evitar resolver a 0.3.10). Se o seu projecto aceitar faixas caret, confirme que o resolved lockfile não contém 0.3.10.

6) Mude credenciais e verifique acessos. Se você mantém crates, rotar tokens de publicação, revisar atividade de conta em crates.io e contatar as equipes de resposta pode impedir a reutilização do acesso. Se sua organização usa tokens em CI, revoque e reemplace tokens que poderiam ter ficado expostos.

7) Mantenha as ferramentas de CI e dependabot com cooldowns e controles. Avaliar políticas que impeçam a compilação automática de pacotes recentemente publicados e a utilização de bloqueio temporário para atualizações automáticas (por exemplo, janelas de arrefecimento ou revisão manual) reduz o risco de execuções de código não auditado. Cargo não tem defeito um cooldown equivalente; há um PR de longa data para opções de publicação mínimas que ainda estava pendente.

Contexto e risco para o futuro: este incidente repete padrões observados em compromissos de outros ecossistemas (npm, etc.), onde typosquatting e publicação rápida produzem execução em ambientes de desenvolvimento e CI. Embora RustSec declara que não há evidência de uso amplo dessas versões, a combinação de uma crate com grande número de dependentes e a capacidade de executar em fase de build torna o risco real para projetos que compilem dependências em ambientes sensíveis.

Para mais detalhes técnicos e o aviso oficial consulte a entrada correspondente na base de dados de RustSec: https://rustsec.org/advisories/RUSTSEC-2026-0260.html, e a documentação de Cargo sobre o mecanismo de yanking que aparece na publicação de crates: https://doc.rust-lang.org/cargo/reference/publishing.html#yanking. Fique atento a comunicados do Rust Security Response Team e a análises técnicas adicionais publicadas por grupos de resposta (Nextron, Wiz e outros) para indicadores e amostras que permitam uma limpeza e detecção mais precisa.