Pacotes do AUR são comprometidos com infostealer e rootkit

 (discourse.ifin.network)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O repositório de pacotes AUR tem uma estrutura em que qualquer pessoa pode adotar pacotes sem mantenedor e enviar mudanças no PKGBUILD e em arquivos relacionados; neste incidente, há indícios de que mais de 408 pacotes foram infectados
  • Um novo maintainer de pacotes do AUR se passou por um maintainer confiável, adotou os pacotes, e outros maintainers do AUR estão trabalhando para remover os pacotes infectados
  • Os pacotes inicialmente infectados foram alterados para executar npm em um script de preinstall e instalar o payload malicioso atomic-lockfile
  • Depois, a infecção passou a instalar o malicioso js-digest com Bun, e o NPM removeu esse pacote
  • A maioria dos pacotes é pouco usada, mas a escala é grande, e o ponto importante é que se trata de um ataque à cadeia de suprimentos que, além de roubo de informações, inclui até um rootkit eBPF

Situação do incidente

  • O que aconteceu

    • Há indícios de que um novo maintainer de pacotes do AUR se passou por um maintainer confiável, adotou e infectou mais de 408 pacotes
    • Depois que a invasão foi reportada, outros maintainers do AUR passaram a trabalhar na remoção dos pacotes infectados
    • Até 2026-06-12T17:30:00Z, os maintainers do AUR relataram que removeram todos os commits maliciosos
    • Os maintainers do AUR decidiram aplicar controles e restrições a alguns recursos, incluindo a função de adoção de pacotes
    • O Arch Linux publicou o aviso Active AUR malicious packages incident

  • Dependências maliciosas

    • O ataque inclui pelo menos duas dependências maliciosas distintas
    • Os pacotes afetados inicialmente foram modificados para usar npm em um script de preinstall para instalar o payload malicioso atomic-lockfile
    • O pacote premake-git tem um commit de exemplo dessa mudança
    • Mais tarde, a infecção passou a usar Bun para instalar o malicioso js-digest, e o NPM removeu js-digest
    • A análise do ataque traz detalhes em Preliminary analysis of AUR malware

Resposta e indicadores de comprometimento

  • Ações recomendadas

    • Se você não usa Arch, não é alvo direto desta invasão dos pacotes do AUR
    • Usuários de Arch devem revisar a lista de pacotes afetados e verificar seus sistemas com o script de checagem de exposição
    • O aur_check.sh vinculado no texto original está desatualizado, e a verificação mais recente deve seguir as instruções desse Gist
    • Se forem encontrados indicadores de comprometimento, o sistema deve ser preservado para uma investigação forense adequada
    • Se forem encontrados pacotes infectados, deve-se seguir os procedimentos normais de resposta a incidentes, trocar todas as credenciais e considerar reinstalar o Arch
    • Devido à possibilidade de rootkit, já não é possível garantir a confiabilidade do sistema
    • Todos os usuários devem adotar medidas para bloquear tráfego de saída para a rede Tor

  • Indicadores de comprometimento

    • O SHA256 do executável Linux malicioso embutido em js-digest é 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • É possível detectar eBPF Maps suspeitos com bpftool map list
    • Nomes de map suspeitos incluem hidden_pids, hidden_names, hidden_inodes

  • Pontos adicionais de verificação

    • Não foi uma conta de maintainer existente que realizou os commits maliciosos; houve falsificação da identidade de um maintainer conhecido
    • A maioria dos pacotes é pouco usada, mas a escala da infecção, com mais de 408 pacotes, é grande
    • Um ataque à cadeia de suprimentos que inclui, além de roubo de informações, um rootkit eBPF é um caso raro
    • A página de atomic-lockfile no Socket.dev mostra 134 downloads do pacote NPM malicioso
    • O pacote NPM é mantido pelo usuário herbsobering
    • Ao pesquisar o nome de usuário herbsobering no GitHub, há uma única imagem de contêiner que parece ser uma ferramenta de reverse shell/proxy: herbsobering430
    • No repositório de pacotes AUR, quando um pacote é marcado como sem mantenedor, qualquer pessoa pode adotá-lo e enviar mudanças no PKGBUILD e em arquivos relacionados
    • Encontrar e adotar automaticamente pacotes abandonados não é algo incomum, e o contexto relacionado está nesta thread no Mastodon

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • É preciso aceitar que o AUR é apenas uma coleção de PKGBUILDs feitos por usuários
    Você deve sempre revisar a fonte de todo PKGBUILD que instalar do AUR, e atualizações não são exceção. Esse é um pressuposto discutido há mais de 10 anos, e é também por isso que não existe um helper oficial de AUR como o yay
    Muita gente reclama que o Arch Linux é elitista, mas na prática ele é uma distribuição para quem sabe o que está fazendo e não quer ser conduzido pela mão em cada etapa. Isso também significa que, se você instalar um pacote aleatório do AUR e quebrar ou comprometer seu sistema, a responsabilidade é sua
    Dito isso, talvez esteja chegando ao fim a era em que qualquer pessoa pode assumir um pacote do AUR. Só o custo de reverter os pacotes afetados toda vez já é alto demais. Como alternativa, revisar todos os pedidos de adoção seria trabalhoso demais e não há garantia de que ajudaria sempre

    • Se é preciso revisar a fonte de todo PKGBUILD instalado do AUR, então isso não deveria se aplicar da mesma forma a extensões de navegador, extensões do VSCode, pacotes NuGet, crates do Cargo, pacotes Python, pacotes npm etc.?
      Acho que sim, a menos que você só execute essas coisas em ambientes sem acesso à internet ou que só possam acessar dados públicos
      Talvez não no AUR, mas outros ecossistemas ao menos podem melhorar isso em teoria com modelos de permissão ou sandboxing. Extensões de navegador já têm essa opção, mas usuários “comuns” quase nunca a usam
      Infelizmente, 99,99% das pessoas não conseguem revisar tudo ou não têm tempo para isso. O mais seguro parece ser usar pacotes de distribuições com mantenedores confiáveis, ou algo como a App Store do iOS, com permissões e algum nível de revisão
    • Não acho que isso seja uma solução real. O fluxo comum desses ataques sempre foi esconder o payload em algum ponto da cadeia de dependências
      Este caso é um pouco incomum porque foi um npm install bem grosseiro dentro do PKGBUILD. A essa altura, quase todo repositório de pacotes fora do AUR também sofre do mesmo problema, e auditar manualmente toda a cadeia de dependências não é realista
      Claro, eu também não tenho uma solução
    • Acreditar que mesmo uma pequena parte dos usuários realmente faz isso é uma ideia profundamente desconectada da realidade
    • Fico pensando o quanto o fato de o AUR ser uma coleção de PKGBUILDs criados por usuários é realmente diferente de todo o ecossistema do PyPI, npm ou Docker Hub
      As pessoas desativam o SELinux, --privileged desativa seccomp e AppArmor, e CVEs de escape de sandbox também existem
    • O fato de qualquer pessoa poder assumir um pacote do AUR nunca deveria ter existido
      No fim, eu gostaria que isso virasse algo como username/packagename-bin|git. Assim ficaria muito mais claro o que exatamente as pessoas estão instalando e de quem

  • Esta campanha ainda está em andamento. Acabei de receber um e-mail dizendo que um dos meus pacotes antigos foi adotado; ele não funcionava fazia anos e já estava órfão havia um bom tempo. Logo depois da adoção, entrou um commit malicioso
    Agora parece que estão usando bun em vez de npm, então é provável que soluções de contorno baseadas em npm não funcionem
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • A esta altura, fico me perguntando se o próprio conceito de adoção de pacote órfão não está quebrado e se não deveria simplesmente ser removido
      Seria inconveniente, mas talvez fosse melhor o AUR exigir um novo envio em vez de permitir que alguém assuma um pacote abandonado por outra pessoa, e apagar periodicamente pacotes órfãos depois de certo tempo
    • Eu também acabei de receber um aviso de que um pacote do AUR que eu acompanhava foi passado para alguém que eu não conheço por estar órfão

  • É óbvio que se deve ter cuidado ao instalar qualquer coisa do AUR, e no passado sempre houve pacotes suspeitos, isto é, mal construídos ou mal empacotados, mas ver uma injeção maliciosa ativa é preocupante
    Acho que o AUR tem dois grandes problemas. Primeiro, ele é um resquício de uma era mais igualitária do open source, quando em geral ainda dava para confiar em código de terceiros. Segundo, qualquer pessoa pode assumir pacotes órfãos mantendo intactos o histórico existente e o histórico de verificação
    A primeira era já acabou, e a segunda pode ser mitigada com controles mais rígidos nas contas do AUR ou com proteções extras nos helpers de AUR. Por exemplo, mostrar um alerta grande e assustador quando o pacote teve mudança recente de proprietário. Ainda assim, sempre vai ter gente que só aperta y e segue em frente, mas ainda é melhor do que não ter nada
    Ou então dá para evitar helpers de AUR por completo e revisar e compilar diretamente o pacote de que você precisa a partir do PKGBUILD

    • A política de adoção de pacotes nunca fez sentido em época nenhuma
    • Na verdade, acho que os helpers de AUR facilitam integrar a etapa de revisão ao fluxo de trabalho
      Eles perguntam ativamente se você quer revisar e também avisam se houve mudanças depois que você aceitou o risco pela última vez
      Dito isso, a visão de que “o AUR é prejudicial” não é nova. Quem usa AUR precisa entender os riscos envolvidos, e no fundo ele é só um passo melhor do que fazer curl | bash com algo encontrado no StackOverflow

  • Mesmo depois de mais de 7 horas, ainda não há nenhuma menção em archlinux.org nem em aur.archlinux.org. Não sei por quê. Deveriam ter bloqueado o AUR até tomar alguma medida que provasse que os usuários estão cientes disso
    Por exemplo, poderiam alterar levemente a URL da API do AUR para fazer usuários do yay/yaourt irem descobrir o que aconteceu. A nova API deveria ter uma infraestrutura para avisar o usuário e confirmar que ele leu a mensagem antes de prosseguir. Isso é ainda mais necessário quando nem sequer está claro se todos os malwares já foram encontrados
    Também deveria existir um banco de dados de commits do AUR revogados ou comprometidos, além de um mecanismo para alertar o usuário se ele já tiver instalado esse pacote

    • Gostando ou não, esse aviso sempre existiu no AUR
      Está até no nome, e a documentação da wiki deixa bem claro que o AUR é um repositório de usuários e não deve ser confiado cegamente
      Está escrito literalmente na grande caixa vermelha logo no começo: https://wiki.archlinux.org/title/Arch_User_Repository
      Há muitas coisas no AUR que eu jamais instalaria, e não acho que a melhor solução seja disparar tudo isso para a mailing list
      Não desgosto da ideia de alertar usuários que instalaram pacotes maliciosos, mas a viabilidade de implementação é baixa. O AUR não tem rastreamento de instalação como ferramentas comerciais. Como você saberia quem instalou quais pacotes? O AUR é basicamente mais parecido com uma lista telefônica de localizações de pacotes, e nem exige login ou credenciais
      Portanto, o alerta precisa vir das ferramentas que o usuário executa se estiver prestando atenção, e de fato exige que ele preste atenção. Ex.: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • Não deveria. Não se deve quebrar o fluxo de trabalho de todo mundo porque algumas pessoas não levam a sério conselhos básicos de segurança
      E como exatamente essa nova API deveria funcionar para avisar o usuário e confirmar que ele leu? Pacotes do AUR são só repositórios git, e os mantenedores do Arch não têm como controlar o que os AUR helpers fazem ou deixam de fazer
    • Acho correto publicar um aviso na página inicial do AUR. Pessoalmente, também acho que uma nota curta no site do Arch com link para o aviso na página do AUR ajudaria
      Se não quiserem listar todos os pacotes sabidamente afetados, deveriam ao menos recomendar como posição oficial que qualquer pessoa que use pacotes do AUR precisa ler todos os arquivos de todos os pacotes que usa
    • Agora saiu o aviso: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Se os números da Socket.dev forem confiáveis, felizmente o impacto parece ser bem pequeno
      Isso também faz sentido. Conheço alguns dos pacotes da lista de afetados, e eles são extremamente antigos, com projetos upstream que já nem são mais mantidos
      Não sei qual é o total de vítimas, mas é bem provável que a equipe do AUR tenha os números exatos. Imagino que estejam lidando com isso da melhor forma possível, proporcionalmente ao impacto

  • No fim das contas, esse tipo de coisa se tornou inevitável e, sem mudanças, provavelmente vai acontecer com mais frequência. Gosto muito do sistema PKGBUILD do AUR e uso bastante, inclusive ao escrever meus próprios pacotes
    O problema mais sério e ao mesmo tempo mais fácil de corrigir é que qualquer pessoa pode assumir um pacote órfão, e isso não é comunicado de forma nenhuma ao usuário final
    Fazer um pacote ser removido dá muito trabalho para pouco retorno, então a forma ideal de abrir mão do controle acaba sendo torná-lo órfão. Na minha opinião, deveria ser o contrário. No mínimo, o usuário deveria ser claramente informado de que o pacote ficou órfão
    Esse ônus talvez recaia mais sobre AUR helpers como paru ou yay, e eu incentivaria esse tipo de mudança

  • Há um script simples para verificar pacotes comprometidos
    https://cscs.pastes.sh/aurvulntest20260611.sh
    Não é meu script, mas é fácil de ler e entender. Você nunca deve simplesmente fazer pipe de um script direto para o bash

    • Também há uma alternativa mais rápida
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      Nunca é má hora para aprender comm(1)
    • Isso só verifica se o pacote foi instalado, não se a versão instalada estava infectada
      Talvez, se você for como eu e não tiver executado yay -Syu por um bom tempo, por alguns meses, então esteja tudo bem? …né?
      Droga, não me façam reinstalar o Arch. Da última vez levou uma semana
      Atualização: archinstall é bom. Recuperei tudo em uns 15 minutos
    • Não há garantia de que essa lista esteja completa
      Você sempre precisa verificar o PKGBUILD e as fontes. Em geral, o AUR não é algo em que se deva confiar. Na verdade, é mais surpreendente que esse tipo de comprometimento não tenha acontecido antes
    • O pacman oferece suporte a locale de data, então procurar por 9 Jun só funciona em locale em inglês ou em locales com formato parecido
      Depois de ajustar para o meu ambiente, apareceu jd-gui, mas na prática eu tinha instalado jd-gui-bin cerca de duas horas antes do comprometimento. Acho que tive sorte porque naquela noite fui preguiçoso e escolhi o pacote -bin em vez de esperar compilar o código-fonte

  • A comunidade Arch está disponibilizando rapidamente scripts e ferramentas
    No momento, este é o utilitário integrado mais atualizado para verificar se há infecção:
    https://github.com/lenucksi/aur-malware-check
    Além disso, na lista de e-mails aur-request estão aparecendo muitos pedidos de remoção e de orfandade para reverter commits maliciosos:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Pergunta de iniciante: como dá para saber se isso é confiável, já que não veio do Arch nem de uma fonte oficial?
      Há muita coisa difícil de entender nesse script, então não é fácil julgar se ele é seguro só lendo o código
      Isso faz a gente esperar uma resposta ou solução do lado dos desenvolvedores oficiais do Arch
    • Gostei do gráfico de estrelas na parte de baixo do README do repositório
      Ele transmite bem a urgência e a importância envolvidas em um grande ataque de malware como este

  • Lembro de ter instalado no Arch Linux, há uns 10 anos, o emulador Mednafen. O programa não rodava porque estava linkado a uma biblioteca que não existia no meu sistema
    Descobri que o mantenedor tinha compilado o software no próprio sistema, e uma biblioteca presente ali acabou sendo usada, mas não foi listada nas dependências
    Era um pacote mantido oficialmente, e eu sempre achei que esse tipo de coisa fosse gerado em servidores de build dedicados, não por voluntários aleatórios ou em computadores domésticos. Não sei se o Arch ainda compila desse jeito, mas aquilo foi assustador o bastante para me fazer trocar de distribuição

    • Isso também pode acontecer usando pkgctl build. É o caso em que makedepends= trouxe transitivamente bibliotecas compartilhadas para o ambiente de build, mas elas ficaram de fora de depends=
      Há um aviso quando dependências .so são detectadas, mas cabe ao mantenedor olhar isso e tomar providências
      Em termos de integridade e segurança, o Arch Linux tem sido um dos pilares do projeto de builds reproduzíveis, e uma parte considerável do sistema operacional pode ser verificada independentemente para confirmar que esses binários realmente foram gerados a partir do código-fonte. O esquema de auditoria dos pacotes oficiais é mais forte que o do NixOS e está em nível parecido com o do Debian:
      https://reproducible.archlinux.org/
      Mas tudo isso é totalmente separado deste incidente do AUR
    • Existem ferramentas para pegar esse tipo de problema compilando e instalando o pacote a partir de uma imagem limpa. Um exemplo é o pkgctl
      Se você é mantenedor, deveria usar esse tipo de ferramenta antes de publicar
    • Até relativamente pouco tempo atrás, isso era comum. O Debian também operou assim por muito tempo e só proibiu isso completamente em 2019

  • Qual seria a solução para isso? Esses pacotes deveriam ser instalados dentro de contêineres Docker sem acesso à rede? Não acho que dá para presumir que isso se limita ao AUR
    Em 2026, é preciso desconfiar de toda fonte de software. Ainda mais com a popularização do vibe coding, e software fechado é uma caixa-preta, então a situação é ainda mais caótica do que no open source

    • “App stores” não confiáveis, incluindo AUR, Flatpak etc., deveriam ficar dentro de um sandbox. Como padrão ou opção, no mínimo uma máquina virtual parece necessária
    • Não gosto de dizer isso, mas o pessoal do Qubes OS estava certo. A solução é isolar agressivamente os apps em máquinas virtuais
      Alguém sabe o quanto a bateria piora se a pessoa decidir migrar de vez?
    • É preciso adotar SLSA
    • Flatpak

  • Estão saindo mais notícias relacionadas
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    Já pensei na ideia de criar um binário canário que, quando executado, simplesmente envia um e-mail ou exibe uma notificação, e chamá-lo de npm
    A esta altura, não mudar o nome do binário npm é um risco enorme