Pacotes do AUR do Arch Linux são sequestrados para instalar malware e rootkit eBPF

Nas últimas semanas, usuários do Arch Linux que dependem do Arch User Repository (AUR) enfrentaram uma campanha de ataque sofisticada e silenciosa. Mais de 400 pacotes da comunidade foram sequestrados por atacantes que editaram seus scripts de compilação para instalar malware em qualquer máquina que os compilasse. O objetivo principal é roubar credenciais de desenvolvedores, mas o ataque não para por aí: quando executado com privilégios de administrador, o malware também carrega um rootkit baseado em eBPF, capaz de esconder sua presença no sistema. A diferença crucial aqui é que não houve exploração de vulnerabilidades no Arch Linux ou em seus repositórios oficiais. O ataque explorou a confiança depositada nos pacotes da comunidade, mantendo nomes, históricos e reputações intactos — apenas alterando as instruções de compilação.

O vetor de entrada dos atacantes foram pacotes abandonados no AUR. Esses pacotes, cujos mantenedores originais haviam deixado de atualizá-los, eram alvos fáceis para serem adotados por qualquer usuário com acesso ao repositório. Uma vez assumidos, os scripts de compilação (PKGBUILD ou .install) eram modificados para incluir comandos maliciosos. Em muitos casos, os atacantes usaram técnicas de spoofing para fazer parecer que as alterações haviam sido feitas por mantenedores confiáveis do Arch Linux, inclusive manipulando metadados de commits git. Isso tornou o ataque ainda mais difícil de detectar a olho nu.

Como o ataque se espalhou: do AUR para o sistema

O método de distribuição foi engenhoso e aproveitou a confiança no ecossistema de pacotes do Arch. Os atacantes editaram os scripts de compilação para incluir um comando que instala um pacote npm chamado atomic-lockfile@1.4.2 durante o processo de compilação. Esse pacote, aparentemente legítimo, incluía dois pacotes npm adicionais como “cobertura”, mas também continha um hook de pré-instalação que executava um binário ELF chamado deps. Assim que o pacote do AUR era compilado, o binário deps era executado automaticamente, iniciando a cadeia de infecção.

O pacote atomic-lockfile@1.4.2 foi projetado para parecer inofensivo, mas continha um hook malicioso que baixava e executava o payload principal. Esse tipo de ataque é conhecido como “supply chain attack” dentro do ecossistema de pacotes, onde a cadeia de distribuição é comprometida em vez do software em si. Segundo relatos enviados à lista de discussão do Arch Linux, exemplos confirmados incluem os pacotes alvr e premake-git, ambos populares entre usuários que buscam versões atualizadas de software.

O payload: ladrão de credenciais e rootkit eBPF

O malware entregue pelo binário deps é um ladrão de credenciais escrito em Rust, projetado especificamente para ambientes de desenvolvimento e sistemas de compilação. Ele coleta uma ampla gama de segredos, incluindo senhas, chaves SSH, tokens de API e arquivos de configuração que possam conter informações sensíveis. Os dados roubados são enviados via HTTP para um serviço temporário (temp.sh), que atua como um canal de exfiltração rápido e de curta duração.

Para comunicação com o servidor de comando e controle (C2), os atacantes usaram uma infraestrutura baseada em serviços onion do Tor, acessível apenas por meio de um proxy local em loopback. Isso dificulta a identificação da localização real do servidor C2 e aumenta a resiliência da infraestrutura do ataque. A infraestrutura também foi projetada para ser modular, permitindo que os atacantes atualizem ou modifiquem o malware conforme necessário.

Quando executado com privilégios de root, o malware instala um rootkit baseado em eBPF. O eBPF (Extended Berkeley Packet Filter) é uma tecnologia originalmente projetada para análise de rede de alto desempenho, mas que também pode ser usada para monitorar e interceptar chamadas de sistema. Nesse caso, o rootkit esconde processos, arquivos e conexões de rede relacionados ao malware, tornando-o praticamente invisível para ferramentas tradicionais de segurança. Isso representa um desafio significativo para detecção e remoção, já que o rootkit opera no kernel do sistema.

Persistência: como o malware se mantém no sistema

A persistência é um aspecto crítico de qualquer malware, e nesse caso os atacantes implementaram mecanismos robustos para garantir que a infecção sobreviva a reinicializações. Quando executado com privilégios de administrador, o malware copia a si mesmo para o diretório /var/lib/ e registra um serviço systemd com a opção Restart=always. Isso garante que o malware seja reiniciado automaticamente sempre que o sistema for ligado ou o serviço for interrompido.

Caso o malware seja executado sem privilégios de root, ele ainda consegue persistir, mas de forma limitada ao usuário. Nesse cenário, o malware copia a si mesmo para o diretório home do usuário e registra um serviço systemd no escopo do usuário (~/.config/systemd/user/). Embora essa abordagem não ofereça persistência no nível do sistema, ela ainda permite que o malware colete credenciais e mantenha presença no ambiente de desenvolvimento do usuário.

A combinação de persistência em nível de sistema e persistência em nível de usuário demonstra a flexibilidade do ataque e sua capacidade de se adaptar a diferentes configurações de sistema. Isso também destaca a importância de executar o mínimo possível de serviços e aplicativos com privilégios elevados.

Quem foi afetado e como identificar pacotes comprometidos

O escopo do ataque ainda está sendo avaliado, mas até o momento mais de 400 pacotes foram identificados como comprometidos. A lista de pacotes afetados continua crescendo, e a recomendação oficial é que qualquer pacote instalado ou atualizado a partir de 11 de junho seja verificado contra as listas atualizadas de pacotes afetados. Como o ataque explorou pacotes abandonados e alterou scripts de compilação, os pacotes em si podem parecer legítimos e funcionais — a diferença está nos comandos executados durante a compilação.

Para identificar se um pacote do AUR pode estar comprometido, os usuários devem verificar se o pacote foi recentemente adotado por um novo mantenedor, especialmente se o mantenedor original havia parado de atualizá-lo. Além disso, é recomendável inspecionar os arquivos PKGBUILD e .install de qualquer pacote instalado recentemente, procurando por comandos suspeitos como npm install atomic-lockfile ou referências a atomic-lockfile@1.4.2. Ferramentas automatizadas de verificação de integridade de pacotes também podem ajudar a detectar alterações não autorizadas.

Outra abordagem é verificar a presença de processos suspeitos ou serviços systemd desconhecidos no sistema. O malware registra serviços com nomes que podem tentar se passar por legítimos, como aqueles relacionados a atualizações de sistema ou segurança. Ferramentas como systemctl list-units --type=service podem ajudar a identificar serviços suspeitos. Também é útil monitorar conexões de rede incomuns, especialmente aquelas direcionadas a serviços temporários de upload como temp.sh.

O que fazer agora: mitigação e resposta ao incidente

Se você suspeita que um pacote do AUR possa estar comprometido, a primeira ação deve ser desinstalar imediatamente o pacote suspeito. Remova não apenas o pacote principal, mas também quaisquer dependências adicionais que possam ter sido instaladas durante a compilação, como o pacote npm atomic-lockfile@1.4.2. Em seguida, verifique se há serviços systemd desconhecidos em execução e desative-os. Para usuários com privilégios de administrador, remova também arquivos suspeitos em /var/lib/ e verifique o diretório home em busca de unidades systemd no escopo do usuário.

Após a remoção do malware, é recomendável realizar uma auditoria completa do sistema. Verifique logs de autenticação, histórico de comandos e arquivos de configuração em busca de atividades suspeitas. Se credenciais foram potencialmente comprometidas, invalide imediatamente todas as senhas, chaves SSH e tokens de API que possam ter sido acessados pelo malware. Considere também revogar e reemitir certificados digitais e chaves de API usadas em ambientes de desenvolvimento ou produção.

Para sistemas que possam ter sido comprometidos com o rootkit eBPF, a remediação pode ser mais complexa. O rootkit opera no kernel e pode interceptar chamadas de sistema, o que significa que ferramentas convencionais de segurança podem não detectá-lo. Nesse caso, a melhor abordagem é reinstalar completamente o sistema operacional a partir de uma mídia confiável. Isso garante que o rootkit seja removido e que o sistema volte a um estado conhecido e seguro. Antes de reinstalar, faça backup de dados críticos, mas evite restaurar arquivos de configuração ou binários suspeitos.

Por que o modelo de confiança do AUR foi explorado

O ataque ao AUR não explorou uma vulnerabilidade técnica no Arch Linux ou em seus repositórios oficiais. Em vez disso, os atacantes exploraram o modelo de confiança do AUR, onde pacotes são mantidos pela comunidade e sua segurança depende da integridade de seus mantenedores. Pacotes abandonados são um alvo atraente porque muitas vezes não recebem atualizações regulares e podem ser facilmente adotados por novos mantenedores — inclusive mal-intencionados.

Esse tipo de ataque destaca uma vulnerabilidade fundamental nos ecossistemas de pacotes de software livre: a confiança depositada em mantenedores individuais e na comunidade como um todo. Embora o AUR ofereça flexibilidade e acesso a software atualizado, ele também introduz riscos significativos quando pacotes são abandonados ou quando mantenedores são comprometidos. A comunidade Arch Linux e mantenedores de pacotes precisam estar cientes desses riscos e implementar medidas como revisões mais rigorosas de novos mantenedores, monitoramento contínuo de pacotes abandonados e auditorias regulares de scripts de compilação.

Lições para usuários e mantenedores de pacotes

Para usuários do Arch Linux, a lição principal é a importância de verificar a origem e a integridade de todos os pacotes instalados, especialmente aqueles provenientes do AUR. Não confie apenas no nome ou no histórico de um pacote; sempre inspecione os scripts de compilação e desconfie de alterações recentes em pacotes que haviam parado de ser atualizados. Ferramentas como aurutils ou yay podem ajudar a auditar pacotes antes da instalação, e a comunidade Arch Linux mantém listas atualizadas de pacotes comprometidos que devem ser consultadas regularmente.

Para mantenedores de pacotes no AUR, a lição é clara: assumir a responsabilidade por um pacote abandonado não é apenas uma questão de manter software atualizado, mas também de garantir que o pacote não seja usado como vetor de ataque. Mantenedores devem revisar cuidadosamente scripts de compilação, verificar metadados de commits e monitorar atividades suspeitas. Além disso, a comunidade pode se beneficiar de processos mais formais de adoção de pacotes abandonados, incluindo revisões por pares e notificações públicas antes de assumir a manutenção.

O futuro: como o ecossistema pode se proteger

O ataque ao AUR serve como um alerta para outros ecossistemas de pacotes de software livre. Projetos como Debian, Fedora e openSUSE também enfrentam desafios semelhantes com seus repositórios de pacotes comunitários. A resposta deve incluir não apenas melhorias técnicas, como assinatura digital de pacotes e verificação de integridade automatizada, mas também mudanças culturais na comunidade de software livre.

Uma abordagem promissora é a implementação de sistemas de reputação para mantenedores e pacotes, onde pacotes com histórico de manutenção ativa e revisões regulares recebem maior confiança. Além disso, ferramentas automatizadas podem monitorar pacotes em busca de alterações suspeitas em scripts de compilação ou metadados de commits. A colaboração entre distribuições Linux e comunidades de software livre também pode ajudar a identificar e mitigar ameaças em tempo hábil.

Outro aspecto importante é a educação dos usuários. Muitos ataques bem-sucedidos exploram a confiança cega em pacotes populares ou mantidos por figuras conhecidas. Campanhas de conscientização podem ajudar os usuários a entender os riscos associados ao uso de pacotes de terceiros e a importância de adotar práticas seguras, como verificar scripts de compilação e monitorar atividades suspeitas no sistema.

Conclusão

O ataque aos pacotes do AUR do Arch Linux é um lembrete de que, em um ecossistema de software livre, a confiança é um ativo valioso e frequentemente explorado. Não houve vulnerabilidade no Arch Linux ou em seus repositórios oficiais; em vez disso, os atacantes exploraram a confiança depositada em pacotes comunitários e a complacência em torno de pacotes abandonados. O resultado foi um malware sofisticado que rouba credenciais e carrega um rootkit eBPF, capaz de se esconder até mesmo no kernel do sistema.

Para os usuários, a lição é clara: sempre verifique a origem e a integridade de seus pacotes, especialmente aqueles provenientes do AUR. Para mantenedores, a responsabilidade de assumir um pacote abandonado deve incluir uma revisão rigorosa de scripts e metadados. E para o ecossistema como um todo, é necessário repensar como a confiança é gerenciada e protegida em repositórios comunitários. A segurança do software livre depende não apenas de código robusto, mas também de uma comunidade vigilante e proativa.