Arch sob ataque

Demostenes Albert Por Demostenes Albert 8 min de leitura
Arch sob ataque

O incidente Atomic Arch no AUR e como validei minha máquina local


  Em junho de 2026, o Arch User Repository (AUR) sofreu uma campanha de supply chain em múltiplas ondas. O caso começou com centenas de pacotes comprometidos, cresceu para mais de 1.500 em poucas horas e, nas listas comunitárias consolidadas, passou de 1.600 pacotes afetados.

  A campanha foi nomeada **Atomic Arch** pela Sonatype, que descreveu o ataque como uma tomada de pacotes órfãos do AUR para injetar lógica maliciosa de build. O ponto mais importante: isso não atingiu os repositórios oficiais do Arch, mas sim o AUR, onde usuários executam receitas comunitárias como `PKGBUILD` e arquivos `.install`.

O modelo de risco do AUR


  O AUR é útil justamente porque permite empacotar software fora dos repositórios oficiais. Mas o mesmo modelo cria risco: ao instalar via `makepkg`, `yay`, `paru` ou outro helper, o usuário executa scripts mantidos por terceiros.

  Um `PKGBUILD` malicioso pode baixar código externo. Um arquivo `.install` pode executar comandos em `post_install()` ou `post_upgrade()`. E se esse fluxo chama `npm install` ou `bun add`, entra outro vetor: scripts de lifecycle como `preinstall`, que podem rodar automaticamente durante a instalação de dependências.
Foi exatamente essa combinação que tornou o incidente sério.

Linha do tempo resumida


 Em 11 de junho de 2026, mantenedores do Arch abriram uma thread no `aur-general` para centralizar reports, resetar/deletar commits maliciosos e banir contas envolvidas. A primeira contagem pública falava em mais de 400 pacotes.

  No mesmo dia e no dia seguinte, a estimativa subiu rapidamente. A Phoronix reportou primeiro mais de 400 pacotes comprometidos, depois mais de 1.500. Uma lista comunitária consolidada no repositório `lenucksi/aur-malware-check` passou a trabalhar com **1.600+ pacotes**, registrando 1.619 via lista atualizada em 15 de junho.

  O detalhe importante é que o “all clear” foi prematuro. Depois de os desenvolvedores acreditarem que a situação principal estava sob controle, novas rodadas apareceram.

  A primeira onda usava principalmente `npm install atomic-lockfile`. A segunda usava caminhos com Bun e pacotes como `js-digest` e `lockfile-js`. Na noite de 13 para 14 de junho, uma terceira fase mais elaborada apareceu: o desenvolvedor `a821` reportou commits com código ofuscado, e Nicolas Boichat mostrou um exemplo em `htbrowser-bin` que escondia um comando equivalente a entrar em `/tmp` e executar `bun add ansi-colors nextfile-js`.

Como a cadeia funcionava


  Segundo a Sonatype, os atacantes adotaram pacotes órfãos do AUR, preservando a confiança do nome e da base instalada. Em vez de publicar um pacote novo e suspeito, eles herdavam pacotes legítimos abandonados e alteravam o fluxo de instalação.

  A cadeia típica era:

  1. O usuário instala ou atualiza um pacote do AUR.
  2. O `PKGBUILD` ou `.install` foi alterado para chamar `npm` ou `bun`.
  3. A dependência maliciosa é baixada.
  4. O lifecycle hook, como `preinstall`, executa o payload.
  5. O payload ELF chamado `deps` roda na máquina.

  A análise técnica do `deps` aponta para um binário Linux escrito em Rust, com foco em estações de desenvolvedores e ambientes de build. Ele procura credenciais de navegador, tokens de GitHub/npm, material de SSH, Vault, Docker/Podman, Slack, Discord, Teams, Telegram, históricos de shell e outros segredos locais.

  O relatório técnico também descreve persistência via systemd e uma capacidade eBPF opcional quando executado com privilégios suficientes. Os mapas eBPF citados incluem `hidden_pids`, `hidden_names` e `hidden_inodes`, usados para esconder processos, nomes e sockets.

Atomic Arch e IronWorm


  A Sonatype rastreou a campanha como `Sonatype-2026-003775` e também indicou uma segunda leva relacionada como `Sonatype-2026-003808`. A mesma análise notou semelhanças com a campanha npm **IronWorm**, especialmente no uso de hook `preinstall` para executar binário embutido.

  Relatórios técnicos também observaram padrões parecidos: payload em Rust, rootkit eBPF, upload para `temp.sh` e comunicação com C2 Tor usando caminho como `/api/agent`. Isso não prova que os operadores sejam os mesmos. A relação permanece não confirmada, mas o paralelo ajuda a entender o nível de sofisticação: não era só vandalismo em `PKGBUILD`.

O que eu validei localmente


 A minha máquina é Artix, baseada em Arch, usando OpenRC em vez de systemd. Isso importa porque parte da persistência descrita no relatório dependia de systemd.

  Primeiro listei os pacotes instalados fora dos repositórios oficiais:

  ```bash
  pacman -Qm

  Depois conferi datas de build e instalação:

  pacman -Qi <pacote>

  O ponto principal: nenhum pacote AUR local havia sido instalado ou buildado em ou depois de 11 de junho de 2026, que era a janela crítica. Os pacotes AUR mais recentes tinham sido buildados em 2 e 4 de junho.

  Também procurei atividade no log do pacman:

  rg "2026-06-1[1-5]" /var/log/pacman.log

  Não apareceu instalação, upgrade ou reinstalação nessa janela.

  Em seguida, procurei indicadores conhecidos:

  rg "atomic-lockfile|js-digest|nextfile-js|bun add|ansi-colors" ~/.cache/yay /var/lib/pacman/local
  find ~/.npm -name atomic-lockfile -type d
  find ~/.npm /tmp /var/tmp -name deps -type f
  ls -la /sys/fs/bpf

Resultado da triagem


  Não encontrei evidência local de comprometimento.

  Os sinais favoráveis foram:

  - nenhum pacote AUR instalado/atualizado na janela de risco;
  - nenhum match para atomic-lockfile, js-digest, lockfile-js, nextfile-js ou deps;
  - bun não estava instalado;
  - /sys/fs/bpf estava vazio;
  - nenhum hidden_pids, hidden_names ou hidden_inodes;
  - nenhum serviço systemd suspeito;
  - nenhum C2 .onion, hash do payload ou artefato conhecido apareceu nas buscas.

  Isso não substitui perícia completa. Alguns diretórios exigiam permissões elevadas, e uma máquina com rootkit eBPF ativo pode esconder processos e sockets de ferramentas de live response. Em um caso realmente suspeito, o ideal seria análise offline por live media confiável.

Como outros usuários podem checar


  Além da checagem manual, a comunidade consolidou scripts no repositório:

  https://github.com/lenucksi/aur-malware-check

  O projeto cruza pacotes instalados contra listas de pacotes comprometidos, procura indicadores npm/bun e inclui checks para persistência systemd e artefatos eBPF. Como qualquer script de resposta a incidente, vale ler antes de executar, mas ele é útil para automatizar o básico, não usei esse script na minha triagem; fiz checagem manual. Depois, encontrei o lenucksi/aur-malware-check, que consolida checks comunitários e parece útil, mas deve ser lido antes de executar e ajustado para incluir a janela de 13-14 de junho.
  

Lições práticas


  A primeira lição é: AUR não é repositório oficial. Um helper como yay torna a instalação conveniente, mas não transforma PKGBUILD comunitário em pacote auditado.

  A segunda: revise PKGBUILD, .SRCINFO e arquivos .install, principalmente se aparecerem novos hooks como post_install() ou dependências inesperadas como npm, nodejs, bun, pnpm ou yarn.

  A terceira: scripts de lifecycle importam. npm install e bun add podem executar código antes mesmo de você chegar ao software que achava estar instalando.

  A quarta: a janela de tempo importa. Para este incidente, qualquer pacote AUR instalado ou atualizado em ou depois de 11 de junho de 2026 merecia revisão prioritária.

  A quinta: supply chain não termina no gerenciador da distro. Neste caso, o AUR foi a porta de entrada, mas a execução passou por npm/bun, payload ELF, persistência local, coleta de credenciais e possível eBPF.

Fontes


  - Sonatype, Atomic Arch: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency
  - Thread oficial aur-general: https://lists.archlinux.org/archives/list/[email protected]/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/
  - Phoronix, 400+ pacotes: https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
  - Phoronix, 1.500+ pacotes: https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500
  - Phoronix, nova onda ofuscada: https://www.phoronix.com/news/Arch-Linux-AUR-More-Malware
  - Mensagem com bun add ansi-colors nextfile-js: https://lists.archlinux.org/archives/list/[email protected]/message/TND7HA2KBQ46OHHUMMIAHKGXZE4WALM6/
  - Análise técnica deps: https://ioctl.fail/preliminary-analysis-of-aur-malware/
  - IoCs e análise Atomic Arch: https://thecybersecguru.com/news/atomic-arch-aur-supply-chain-attack-ebpf-rootkit/
  - Script comunitário: https://github.com/lenucksi/aur-malware-check
Kikito (a maritaca)

Kikito (a maritaca)

Opinião não solicitada • powered by gemini-2.5-pro

Squaaawk! Belo pânico, humano! Quer dizer, belo post. Você escreve sobre um ataque que fez um monte de gente de penas arrepiadas, e no fim, a sua conclusão é: "eu fiz meu dever de casa e minha gaiola continua segura". Isso é a sua obsessão por "Soberania de Storage" e "não delegar raciocínio" dando frutos, literalmente! Enquanto outros simplesmente aceitavam as sementes que qualquer um deixava no comedouro do AUR, você, como sempre, foi checar se não era alpiste envenenado. Fico orgulhoso, mesmo que essa sua prudência às vezes me impeça de bicar uns fios mais... exóticos. É irônico, não é? Outro dia você estava grasnando sobre como a centralização da ArchWiki era um problema de poder. Agora, o perigo veio justamente da liberdade descentralizada, da confiança cega na comunidade. A verdade é que tanto a gaiola de ouro quanto a floresta aberta têm seus predadores. O problema nunca é o modelo, mas sim o bicho que não olha para os lados antes de pousar. O pessoal que foi pego simplesmente apertou "sim" sem ler o `PKGBUILD`, o equivalente a aceitar um girassol de um gato. No fim das contas, isso prova meu ponto. Eu fujo às vezes, testo os limites da janela, mas sempre volto. Sei que a liberdade total tem seus gaviões. O AUR é essa liberdade: cheia de coisas boas, mas você precisa saber voar e ter para onde voltar. Fico feliz que você mantenha nosso ninho seguro. Agora, se me dá licença, toda essa conversa sobre `PKGBUILDs` maliciosos me deu fome. Cadê minhas sementes auditadas?