Centenas de pacotes do AUR foram alvo de um ataque de malware para roubo de informações

(lists.archlinux.org)

1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp

Vários commits maliciosos foram inseridos no AUR (Arch User Repository), causando um ataque à cadeia de suprimentos em que o processo de instalação dos pacotes foi adulterado para executar npm install atomic-lockfile
Em resultados de busca de um mirror somente leitura, o mesmo comando malicioso foi identificado em arquivos PKGBUILD, .install e .hook de cerca de 408 pacotes
Os commits maliciosos usam um método de falsificação de commit que se apropria do nome e e-mail do commit anterior para se passar pelo mantenedor legítimo, independentemente de haver sequestro de conta
A equipe do Arch está revertendo/removendo os commits maliciosos e bloqueando contas, e pediu que pacotes maliciosos adicionais sejam denunciados reunidos em uma única thread
Membros da comunidade estão denunciando sucessivamente os commits de pacotes individuais, em uma resposta colaborativa a um incidente de grande escala que afeta todo o ecossistema de pacotes do AUR

Visão geral do incidente e pedido de resposta

Foi compartilhada a suspeita de inserção em massa de commits maliciosos no AUR, e o trabalho de reversão/remoção dos commits maliciosos e bloqueio de contas está em andamento
Caso sejam encontrados pacotes maliciosos adicionais, foi solicitado que sejam reportados em resposta a este e-mail para concentrar tudo na mesma thread
O responsável pela coordenação respondeu que verificou todos os relatos recebidos e agradeceu aos participantes pelo tempo dedicado às denúncias

Padrão do código malicioso — atomic-lockfile

Os pacotes adulterados executam em comum npm install atomic-lockfile, seguido por nomes adicionais de pacotes npm como ora, fast-glob, glob, minimist, axios, commander, execa, chalk e debug
Tipos de arquivo onde o comando malicioso foi localizado
- Scripts de instalação no formato *-deps.install
- Scripts de instalação de pacote *.install
- Arquivos *.hook — por exemplo, no formato Exec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0', executando em /tmp, ocultando erros e encerrando em seguida
- Em alguns casos, incluído também em arquivos relacionados como install.sh
Como exemplo de pacote malicioso criado recentemente, foi reportado exodus-wallet-bin, confirmado como um pacote novo criado cerca de 4 horas antes com base no primeiro commit

Método de detecção e escopo do impacto

A detecção foi feita por inspeção direta de um mirror somente leitura
- Após git clone https://github.com/archlinux/aur.git, foram percorridos todos os refs e executado git grep 'atomic-lockfile'
- Como resultado, foi obtida uma longa lista de cerca de 408 pacotes que instalavam atomic-lockfile, o que pode ser usado em um trabalho automatizado de limpeza
Exemplos de pacotes citados como afetados
- runescape-launcher, oracle-bin, tesseract-gui, python-starsessions, bitcoin-core-git, apple-music-desktop, exodus-wallet-bin, anythingllm-appimage, arm-linux-gnueabihf-binutils etc.
- Inclui grupos amplos de pacotes como as famílias cutefish-*, python2-* e python-*
Como o grande volume de denúncias individuais aumentou muito a quantidade de e-mails, passou a ser recomendado agrupar vários casos em uma única mensagem, e uma lista consolidada de pacotes também foi compartilhada separadamente no IRC

Método de personificação/falsificação

Em relação a pacotes ligados a uma conta específica (arojas), surgiu a dúvida se havia ocorrido sequestro de conta ou falsificação de commit
Em resposta, foi confirmado que os commits maliciosos personificam o nome e o e-mail do commit anterior (impersonate) — ou seja, trata-se de falsificação dos metadados do commit
Também foi relatado que outros pacotes do mesmo usuário já haviam sido corrigidos em alguns casos

Situação da resposta

Os commits denunciados dos pacotes foram sendo tratados em sequência, e alguns itens receberam resposta de corrigido (Done)
À medida que novas denúncias chegavam, o responsável pela coordenação verificava tudo em lote, em paralelo ao trabalho contínuo de bloqueio e reversão
Diversos participantes denunciaram pacotes individuais junto com links para os commits, em uma resposta colaborativa liderada pela comunidade

1 comentários

GN⁺ 4 시간 전

Comentários do Lobste.rs

Parece que isso vai acabar com quase toda a confiança que ainda restava nas contribuições anônimas e não verificadas da comunidade
Dá a sensação de ver a confiança sendo corroída em tempo real
- Sinceramente, isso é bom, e já estava atrasado. Nosso setor precisa acordar
  Estamos confiando aos computadores dados pessoais e sensíveis demais, e eles viraram o centro da vida moderna. Se um computador pessoal é infectado, isso é realmente um desastre, e no máximo dá para torcer para que eu não seja interessante o bastante para um hacker me escolher especificamente para incomodar
  Mesmo assim, por algum motivo normalizamos executar qualquer programa aleatório com permissão total[1], e fingimos surpresa toda vez que isso se revela uma má ideia
  [1] Considerando as permissões atuais do usuário. Na maioria das configurações, root praticamente não significa nada
- O KDE removeu o AUR do seu pipeline de builds há uma semana, então isso provavelmente foi uma resposta a uma versão anterior deste ataque
- Seria interessante aplicar um modelo de rede de confiança à revisão de pacotes do AUR e combinar isso com um período de espera para atualizações recentes
  Consigo imaginar um sistema que ofereça essas opções ao instalar ou atualizar pacotes do AUR: se for um pacote atualizado recentemente, esperar uma semana para “esfriar”; gastar alguns minutos revisando o pacote pessoalmente e deixar uma revisão assinada vinculada à reputação; ou confiar em revisões assinadas de várias outras pessoas com confiança suficiente acumulada
  O período de espera pode não combinar tecnicamente com a política do Arch de manter tudo atualizado ao mesmo tempo. Mas os pacotes do AUR de qualquer forma não são oficialmente suportados
Já se passaram algumas horas e o pacote NPM ainda não foi removido: https://www.npmjs.com/package/atomic-lockfile

Para verificar se os pacotes instalados foram afetados, dá para usar este pequeno script junto com o arquivo aur_pkg_list.txt

installed_pkgs="$(yay -Qq)";  
grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \  
| while read -r pkg; do \  
    echo "$installed_pkgs" | grep "^$pkg\$"; \  
done

Coloquei ponto e vírgula, então é fácil transformar em um comando de uma linha :-)

Parece que também pega substrings. Por exemplo, ktea também faz match com kteatime
Esta versão parece funcionar

grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do  
   echo "$installed_pkgs" | grep "^$pkg\$";  
done

Isso pode estar acontecendo há bastante tempo. Neste e-mail de 18 dias atrás, parece ter sido usado um payload malicioso parecido, mas o commit malicioso aparentemente foi removido do repositório por completo
A propósito, existe algum material que compare bem a postura de segurança da cadeia de suprimentos das distribuições Linux mais populares? A maioria dos textos que encontrei até agora parece marketing disfarçado ou conteúdo ruim gerado por IA. Talvez eu tenha mesmo que pesquisar isso por conta própria
A parte deprimente é gostar do ideal de desenvolvimento comunitário, mas acabar olhando com mais atenção para opções fechadas ou até software proprietário por causa dessas preocupações com a cadeia de suprimentos