A traição da AUR: como um ataque à cadeia de fornecimento tornou pacotes órfãos em roubo de credenciais e persistência oculta

A última onda contra o Arch User Repository (AUR) obriga a reconsiderar como confiamos em pacotes comunitários: atacantes tomaram controle de centenas de pacotes "huérfanos", modificaram apenas suas instruções de construção (PKGBUILD/.install) e conseguiram que máquinas de desenvolvimento executassem um binário em Rust projetado para roubar credenciais. A peça chave do ataque não foi uma falha no Arch nem um zero-day, mas a exploração do modelo de confiança da AUR: nome e histórico intactos, mantenedor alterado.

O que aconteceu em termos técnicos: os adversários adotaram pacotes abandonados, inseriram chamadas como npm install atomic-lockfile ou bun install js-digest durante a compilação e assim arrastaram um pacote npm malicioso que executa um ELF chamado deps no processo de build. Esse binário recolhe tokens de navegadores e apps Electron, chaves SSH, credenciais de contêineres, dados de Vault e até material de OpenAI/ChatGPT, e exfiltra para serviços públicos (temp.sh). Se correr com privilégios root, você pode instalar um serviço persistente e opcionalmente carregar um módulo eBPF que oculta processos, nomes e sockets; o rootkit-eBPF é acessório mas eleva a gravidade porque complica a limpeza. Para análise técnica e conjuntos de indicadores, veja o relatório comunitário e a análise forense da amostra: Sonatype — Atomic Arch e ioctl.fail — análise e sinais.

Implicações práticas: se você construiu ou atualizaru qualquer pacote da AUR a partir de 11 de junho, não basta confiar em que apagar o pacote do gestor deixa o sistema limpo. Uma vez que o payload é executado com privilégios suficientes, o atacante pode deixar persistência, roubar segredos e, no pior caso, ocultar sua presença com eBPF. Os valores iniciais de pacotes comprometidos chegaram a centenas e continuam a flutuar: a via de exposição não era a descarga direta do pacote npm (atomic-lockfile tinha muito poucas descargas semanais), mas o canal de build na AUR.

O que verificar imediatamente em uma equipe suspeita: verifique os logs e caches de makepkg/build (busque traços de npm install atomic-lockfile, bun install js-digest ou rotas como src/hooks/deps), inspeccione unidades systemd tanto a nível de sistema como de usuário em busca de serviços desconhecidos, explore /var/lib/ por artefatos e /sys/fs/bpf/ por mapas nomeados como hidden_pids, hidden_names ou hidden_inodes. Monitorize conexões salientes invulgares, especialmente para nós Tor ou serviços de subida, e compare binários suspeitos com os hashes publicados pelos pesquisadores. Se o binário correu com o root, o prudente é assumir compromisso da máquina e reinstalar de meios de confiança. A AUR e os repos oficiais do Arch são diferentes; os repos oficiais não foram afetados, mas isso não limpa um sistema local comprometido.

Ações de contenção e recuperação: se uma compilação executou algum dos payloads, rote imediatamente qualquer segredo que o malware pudesse ter lido: sessões e cookies de navegadores, tokens do GitHub e npm, chaves SSH, credenciais de Vault, credenciais de Docker/Podman, perfis VPN e chaves cloud. Revoque e regenere chaves e tokens de outra máquina conhecida limpa. Procure e remova serviços systemd desconhecidos e arquivos em locais persistentes; no entanto, lembre-se de que um rootkit com capacidade para se esconder pode evitar uma detecção confiável. Por isso, quando há sinal de execução com privilégios, a única forma segura de recuperar a confiança é reinstalar o sistema a partir de meios verificados e restaurar dados a partir de backups anteriores e examinados.

Prevenção a médio e longo prazo: trate os pacotes aprovados recentemente ou que tenham permanecido adormecidos como potencialmente arriscados. Não construa AUR às cegas: leia o PKGBUILD e os hooks .install antes de executar o makepkg, e se não compreender os passos de build abs pare. Valore construir pacotes em ambientes isolados: máquinas virtuais efímeras, contentores ou chroots sem acesso a credenciais sensíveis. Para projetos mantidos pela comunidade, observe o histórico de manutenção e os sinais de adoção recente; os atacantes exploram precisamente essa janela de confiança. Recursos oficiais e guias de segurança em AUR podem ser consultados na documentação do Arch: AUR e a Wiki do Arch sobre políticas e segurança de pacotes.

Finalmente, a lição é estrutural: as cadeias de fornecimento que delegam confiança em nomes e história sem validar a identidade e a intenção do mantenedor são frágeis. As equipes devem incorporar controles que reduzam o blast radius de builds não confiáveis: separação de papéis, ambientes de compilação dedicados, revisão humana de scripts de build e rotação frequente de segredos. Para indicadores técnicos, hashes e a lista consolidada de pacotes afetados siga as pesquisas públicas (a análise e o conjunto de IOCs estão coletados pela comunidade e por pesquisadores como os ligados acima).