Arch Linux considera incidente de malware sob controle: mais de 1.500 pacotes afetados

• No repositório de contribuições de usuários AUR do Arch Linux, os pacotes infectados por malware, inicialmente confirmados em mais de 400, acabaram passando de 1.500
• Em uma atualização de algumas horas atrás, estimava-se que cerca de 900 pacotes haviam sido infectados no incidente desta semana
• Depois disso, os desenvolvedores do Arch Linux removeram todos os commits maliciosos identificados, e o número de pacotes afetados foi contabilizado em 1.579
• A lista com 1.579 também é indicada como uma lista extensa, mas não completa, dos pacotes afetados, então o alcance total pode ser ainda maior
• Muitos softwares no repositório mantido por usuários foram afetados por este incidente de segurança, e uma atualização separada relata uma nova onda de ataques de malware mais sofisticados

---

Visão geral do incidente

• O incidente começou quando mais de 400 pacotes infectados por malware foram encontrados no repositório de contribuições de usuários AUR para usuários do Arch Linux
• Perto do fim do dia, o Arch Linux concluiu que todos os commits afetados haviam sido tratados, mas o número de pacotes impactados subiu para mais de 1.500
• Este foi um incidente de segurança que afetou muitos softwares no repositório do Arch Linux mantido por usuários

Mudança no alcance do impacto

• Em uma atualização de algumas horas antes, estimava-se que cerca de 900 pacotes haviam sido infectados por malware no incidente desta semana
• Depois disso, segundo a última mensagem na thread do incidente de segurança, os desenvolvedores do Arch Linux removeram todos os commits maliciosos identificados
• A lista citada indica o número de pacotes afetados pelo malware em 1.579

Incertezas restantes

• A lista com 1.579 pacotes também é descrita como “uma lista extensa, mas não completa, dos pacotes afetados”
• Portanto, o número divulgado mostra um impacto confirmado em larga escala, mas a própria lista não cobre todos os pacotes

Atualização posterior

• Uma atualização separada informa que o AUR do Arch Linux enfrentou outra onda de ataques de malware mais sofisticados

[GN⁺]

Comentários no Hacker News

• Fico me perguntando se a equipe do AUR já publicou uma análise pós-incidente
  A resposta desta vez foi impressionantemente rápida, mas, honestamente, parece que tanto a política do AUR quanto os wrappers precisam mudar
  Deveria ser possível definir uma idade mínima para pacotes, como no pnpm, e pacotes órfãos não deveriam poder ser adotados por qualquer pessoa
  Também daria para colocar um limite global de velocidade nas adoções e usá-lo como sinal de ataque, e, como várias empresas fazem no NPM, também seria necessário fazer varredura de vulnerabilidades no momento da publicação
  Dito isso, a maior parte dessas mudanças parece ser mais responsabilidade dos helpers de empacotamento e de terceiros do que dos mantenedores do AUR

  • Seria melhor dividir os pacotes do AUR em namespaces
    Assim a propriedade não desapareceria, e o processo de órfão deixaria de ser necessário
  • Não existe uma ferramenta oficial para baixar repositórios do AUR, então essa parte depende da forma como cada um usa
  • Recentemente fiz um patch para o pakku, inspirado no pnpm, para definir uma idade mínima do AUR [1]
    [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
    [2] https://github.com/zqqw/pakku
  • Se dificultarem demais a adoção de pacotes órfãos, alguns que poderiam ser mantidos adequadamente podem acabar abandonados
    Restrições são necessárias, mas algo como limitar a 1 adoção por mês para usuários cadastrados antes de um certo período parece razoável
    De qualquer forma, ninguém aplica atualizações automáticas e sem revisão a pacotes do AUR instalados localmente, então a superfície de ataque já é bem pequena
  • Uma simples varredura de vulnerabilidades provavelmente não teria detectado isso
    O ponto central do worm miasma é justamente que as assinaturas e os métodos dos helpers mudam rápido demais
    O implante malicioso criptografado descriptografa o payload com chaves AES-128-GCM diferentes para cada localização enviada ao GitHub, os nomes de métodos no código também mudam dinamicamente, e offsets de símbolos criptografados também são misturados e reutilizados
    Por ser um malware polimórfico, é um adversário péssimo para ferramentas baseadas em assinatura
    APT28/29 aparentemente depende, em certa medida, da lentidão com que a Microsoft bloqueia automaticamente usuários e repositórios usados como infraestrutura de C2 no GitHub
    Vale pensar no que isso significa para a estratégia de segurança
    Quando já dá para fazer varredura por assinaturas ou strings, você já entrou num jogo de gato e rato com uma botnet totalmente automatizada, e não tem como vencer
    Na última semana, a socket.dev foi praticamente a única ferramenta de supply chain que acompanhou essas mudanças no implante; as demais redescobriram o Miasma como se fosse uma nova campanha sem nem saber do que se tratava
    Faltou pessoal e toolchain para fazer engenharia reversa dos payloads rápido o bastante para acompanhar o ritmo de novos adaptadores para ecossistemas aparecendo a cada 24 horas
    Aqui, totalmente automatizado significa que credenciais roubadas em outros ecossistemas de pacotes já estavam sendo usadas em menos de 48 horas
    Endereços de e-mail e nomes continuam aparecendo, e parecem ser de pessoas que muito provavelmente não entenderam o impacto desse worm autorreplicante
    Por exemplo, procurar indicadores de comprometimento em pacotes que dependem de bun também não ajuda muito
    O malware pode simplesmente ser baixado de novo por meios externos
    Na segunda campanha no PyPI, depois que a primeira onda de droppers maliciosos da campanha da RedHat foi sinalizada aos mantenedores do PyPI, o método mudou para baixar o dropper por meio de arquivos WHL compactados e de um arquivo setup.pth executado automaticamente
    A menos que os gerenciadores de pacotes desses ecossistemas sejam reescritos do zero com chroot, sandbox, logs de rede e domínio e listas de permissão por item como premissas, a estratégia de distribuir malware por ataques à cadeia de suprimentos continuará sendo viável
    O repositório com ferramentas de mitigação é [1], e os detalhes técnicos estão no post do blog [2]
    Composer, Rubygems, NPM, PyPI e Go também foram afetados; é um problema que atravessa todos os gerenciadores de pacotes
    Precisamos discutir mais abertamente o quanto de descuido e confiança externa estamos colocando em gerenciadores de pacotes, porque isso realmente precisa mudar
    [1] https://github.com/cookiengineer/antimiasma
    [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

• Quando começaram a aparecer wrappers do pacman que instalam direto do AUR, isso me incomodou bastante
  Já instalei coisas do AUR, mas na maioria dos casos prefiro pular essa etapa intermediária e ir direto ao site do projeto
  Um PKGBUILD pronto não é conveniente o bastante para justificar o risco de typosquatting ou abuso de dependências npm·pip

  • Wrappers como yay mostram o diff do PKGBUILD a cada atualização
    Na instalação inicial, você confere a URL e vê se o script de instalação faz sentido, e depois as atualizações normalmente só mudam o número da versão e o checksum
    Um ataque de typosquatting ficaria bem evidente
    A primeira instalação é um pouco mais vulnerável, mas ir ao site do projeto e clicar em download também é
  • O Arch continua recebendo críticas por ser elitista ou por afastar usuários comuns, mas claramente existe uma vantagem em não tornar coisas perigosas fáceis
    Isso vale para vários aspectos da vida
    Depois de usar Void Linux, também migrei no Arch para aurutils para ter uma separação parecida
    Assim consigo fazer builds manualmente, manter com facilidade um repositório AUR local e instalar e gerenciar tudo com pacman, o que melhora o processo de upgrade completo
  • Para mim, esse compromisso não vale a pena
    Um dos motivos de eu ter migrado para Linux não foi perder tempo como usuário de Windows indo a sites e clicando em “download” para atualizar programas
    Dito isso, os wrappers do pacman mencionados parecem perigosos
  • O AUR e repositórios parecidos em outras distros realmente me assustam
    Existem tantos tutoriais usando esses repositórios que chega a parecer que eu sou a pessoa estranha por não querer dar acesso root indefinido a um desconhecido quase sem nenhuma revisão por pares
    Tudo isso para instalar uma versão de um pacote que talvez nem precise de atualização ou só raramente precise

• Lendo rapidamente, parece que instalaram atomic-lockfile, js-digest e lockfile-js via npm
  A lista de pacotes afetados está em [1]
  Não achei de imediato uma forma de verificar o sistema, então rodei pacman -Qmi para procurar informações relacionadas a pacotes externos e datas
  Depois é só comparar a saída com a lista de pacotes afetados
  Também dá para procurar arquivos assim em vários lugares
  grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
  Não sei se o pacote se apaga sozinho depois de ser executado
  Como as outras informações não ajudaram muito, quis pelo menos compartilhar os comandos básicos
  [1] https://md.archlinux.org/s/SxbqukK6IA

  • Foi assim que eu fiz
    Peguei com yay a lista de pacotes instalados vindos do AUR: yay -Qam > packages_aur.last
    Baixei a lista em https://md.archlinux.org/s/SxbqukK6IA#: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
    Depois, ao rodar grep -wFf compromised.txt packages_aur.last, devem aparecer os pacotes presentes nos dois arquivos, ou seja, os que foram comprometidos em algum momento
  • O atacante usou pelo menos três dependências Node, então não basta verificar só atomic-lockfile
js-digest e lockfile-js também foram usados, e em algum momento trocaram npm por bun
  • Isto também pode ser útil: https://github.com/lenucksi/aur-malware-check
  • É engraçado que, mesmo numa situação em que tentam colocar malware no Arch Linux AUR, o malware ainda seja distribuído via NPM
    Plataforma lendária
  • Não entendo como emacs-magit foi afetado
    Pelo que eu sei, não tem JavaScript nenhum

• Isso serve como mais um lembrete justo de sempre: não instale pacotes, bibliotecas ou aplicativos aleatórios de terceiros sem revisão
  Felizmente, desta vez ficou restrito ao AUR, que é basicamente um repositório onde qualquer pessoa pode enviar pacotes e, ao contrário dos repositórios oficiais, há muitos avisos de que a revisão antes da instalação é obrigatória
  Ferramentas de linha de comando como rua facilitam revisar pacotes antes de instalá-los do AUR
  Se você faz operações bancárias no mesmo computador, não há desculpa para não revisar o software do qual depende
  Manter o número de pacotes baixo e usar só o necessário também torna as atualizações muito mais simples

  • Como exatamente alguém deve fazer essa “revisão”?
    Quer dizer ler cada linha de código antes de instalar?
    E se for um pacote binário?
    A ideia é criar builds reproduzíveis para tudo o que se instala, ou migrar para uma distro baseada em código-fonte?
    Jogar essa responsabilidade no usuário não é uma solução sustentável
    Há espaço para bom senso, mas culpar o usuário por isso não faz sentido
  • Parece razoável, mas no fim é um conselho impraticável e, por isso, mais do que inútil, acaba sendo prejudicial
    Existe muito mais código no mundo do que uma pessoa conseguiria ler ao longo da vida
    Provavelmente você mesmo não leu nem 1% do código-fonte que está rodando no seu computador agora
    Então você parou de usar computador?
    Como pode confiar no que acontece dentro dele?
  • Acho que a posição de “é obrigatório revisar antes de instalar” precisa ser reavaliada
    Os desenvolvedores do Arch Linux fazem um ótimo trabalho e eu sou grato por isso, mas hoje, com tantos ataques à cadeia de suprimentos, sinto que avisos ao usuário sozinhos já bateram no limite faz tempo
    Não vejo uma solução fácil, mas controles como revisão por pares antes da publicação ou um período de carência poderiam ao menos mitigar um pouco o problema
  • O AUR sempre foi muito valorizado como uma grande vantagem do Arch, mas essa conveniência sempre teve um custo
    É absurdo que alguém possa marcar um pacote como órfão, esperar duas semanas e, se o mantenedor original estiver de férias e não responder, um atacante possa ser designado como mantenedor e distribuir uma atualização maliciosa
  • Vejo isso como um forte argumento a favor da combinação de arquivos de sistema imutáveis, instalações locais de usuário por padrão e concessão de privilégios mínimos a componentes e programas
    Distros imutáveis, Wayland e Flatpak têm algumas peças disso, mas ainda existem lacunas importantes
    O maior problema é que o sandbox está atrelado ao formato do pacote, e acho isso um erro
    Sandbox e permissões de acesso deveriam ser recursos do sistema, para que nem binários arbitrários consigam escapar facilmente pelas brechas
    Isso não resolveria completamente o problema, mas reduziria muito o raio do dano e tornaria os usuários da distro alvos menos atraentes

• Para quem está preocupado, encontrei um repositório que reúne scripts atualizados e a lista de pacotes para ajudar a verificar se houve infecção: https://github.com/lenucksi/aur-malware-check

  • Dei a mesma lista (https://md.archlinux.org/s/SxbqukK6IA) para o Claude e pedi uma verificação de malware, e ele fez essencialmente a mesma checagem que esse script faz
    Qualquer um dos dois deve ser suficiente, eu acho)

• Não sou usuário do Arch Linux, mas uso bastante NodeJS, e esse tipo de ataque também acontece com frequência por lá
  Hoje em dia, fico me perguntando onde de fato fazem gerenciamento de pacotes de forma correta e segura

  • O AUR é baseado em suporte da comunidade, então malware às vezes acaba entrando misturado nos pacotes
    Não era em escala tão grande quanto desta vez, mas já era claro desde o início que não era algo seguro, e havia alertas de risco por toda parte
  • As distribuições Linux estão fazendo um bom trabalho
    Todas têm mantenedores que revisam os pacotes e se responsabilizam por eles
    Com o Arch Linux é a mesma coisa
    A falta de confiabilidade inerente do AUR sempre foi explicitamente apontada na Arch Wiki e na cultura ao redor dele, e isso é diferente de gerenciadores de pacotes de linguagens de programação como npm ou pip
  • Se você não usa o AUR, o Arch é tranquilo
    Se usar o AUR, precisa verificar tudo
    A maioria das distribuições também é tranquila, e as grandes têm um histórico bem bom
  • Parece haver algo no ecossistema do Node que o torna especialmente vulnerável
    Pode ser por causa da cultura excessiva de DRY, ou por algum outro motivo
    Não vi nada parecido com esse pesadelo de árvore de dependências em nada que já usei

• Existem 15 mil pacotes órfãos no AUR
  Hoje de manhã, ordenei por popularidade e adotei e compilei 3 que quase não eram atualizados
  Se você usa pacotes órfãos, talvez valha considerar adotá-los você mesmo antes que gente mal-intencionada os pegue

• Posso estar errado, mas esta situação parece um sinal de maior adoção do Linux no desktop

• Nunca precisei do AUR
  Se preciso de um pacote que não está no repositório oficial, eu mesmo compilo ou, se houver um release binário, faço o download
  Assim não preciso usar root na hora de compilar, e posso fazer uma instalação local só para um usuário, o que na verdade combina melhor com a maioria dos casos de uso em desktop
  Pelo menos, em comparação com o caminho desenvolvedor → usuário, isso elimina uma etapa desenvolvedor → mantenedor → usuário em que haveria possibilidade de inserção de código malicioso

  • O makepkg se recusa ativamente a rodar como root
    Ele não executa como root a menos que você force um desvio como env EUID=123 makepkg ...
    Ainda assim, seria bom se o pacman suportasse instalação em nível de usuário
    Hoje ele se recusa a instalar sem root, embora dê para contornar isso mapeando a si mesmo como root com namespaces de usuário

• Entendo que desta vez foi no AUR
  Independentemente de ser AUR ou não, seria bom se vocês compartilhassem quais etapas seguem ao instalar pacotes e como garantem que o pacote e as dependências que pretendem instalar não são malware
  Depois de instalar um pacote malicioso, realmente parece muito difícil voltar atrás