Pacotes falsos no AUR instalam malware com permissões de root

Instalar pacotes do AUR como se fossem oficiais voltou a sair caro. De acordo com o BleepingComputer, um atacante carregou para o Arch User Repository pacotes maliciosos que se faziam passar pelos populares helpers yay e paru, com nomes quase idênticos, e que acabavam a executar código remoto com permissões de root.

O AUR é o repositório mantido pela comunidade onde vivem milhares de PKGBUILDs para software de terceiros, versões beta e aplicações que não passam pelos canais oficiais da distribuição. É precisamente esta mistura de utilidade extrema com ausência de garantias que o torna um alvo apetecível. O repositório já tinha sofrido em junho uma campanha em que mais de 400 pacotes espalharam malware com capacidades de rootkit. Em julho, a enxurrada de lixo obrigou até a suspender temporariamente a adoção de pacotes.

O novo ataque, detetado a 13 de outubro, usou um utilizador com o nome “marchos1as” que publicou pacotes com nomes typosquatted, a imitar os comandos yay e paru. Uma thread na mailing list de Arch Linux com o título sintomático “hundreds of aur packages were mass uploaded with malware” deu o alerta. Em poucos minutos, membros da comunidade confirmaram que os pacotes combinavam código legítimo a partir do upstream com um script de instalação malicioso que ia buscar um shell script remoto e o executava como root. Um dos mantenedores do AUR, Andreas Reichel, descreveu o pacote “yyay” como uma simples reembalagem do helper legítimo, mascarada para se confundir no meio dos resultados e com o trojan escondido no scriptlet de instalação.

Outro mantenedor, Emiliano Gandini Outeda, identificou vários destes pacotes suspeitos com regras na sua ferramenta de segurança de aplicações TrustSight. A equipa do AUR acabou por banir a conta de “marchos1as” e remover os pacotes afetados, mas numa distribuição rolling e com utilizadores que atualizam tudo em segundos, a limpeza nunca é instantânea. Quem tiver instalado clones estranhos de yay ou paru nos últimos dias deve partir do princípio de que o sistema está comprometido e agir em conformidade, não só com um simples “pacman -R” mas com auditoria séria e, idealmente, reinstalação.

O BleepingComputer sublinha ainda um detalhe que liga esta campanha a outra, no ecossistema npm. O payload era descarregado através de um URL da Wayback Machine que apontava para um repositório pessoal “hellscripter/install-scripts” alojado no serviço russo GitFlic. A SafeDep tinha documentado recentemente uma operação em npm batizada “DirtyBlanket” que também ia buscar código a um repositório “hellscripter/install-scripts” noutro alojador, o Codeberg. Nessa investigação foi encontrado um worm Linux que implantava o trojan de acesso remoto CHAOS disfarçado de serviço de fontes e que, curiosamente, também injetava um loader em pacotes AUR. Uma entrada na base OSV sobre a atividade DirtyBlanket cita as mesmas referências à Wayback Machine e ao domínio GitFlic. As peças encaixam demasiado bem para ser coincidência, mas até agora não há confirmação formal de que tudo faça parte da mesma operação.

Para quem usa Arch, isto não devia ser surpresa. O AUR nunca prometeu segurança, apenas conveniência. O problema é que muitos utilizadores já tratam helpers como yay ou paru quase como um apt para tudo e aceitam PKGBUILDs vindos de desconhecidos sem sequer abrir o ficheiro numa janela de texto. A cultura de “audita antes de instalar” falha no minuto em que se automatiza o processo. Depois de ataques a repositórios de npm, PyPI ou mesmo a infraestruturas de firmware, como no caso dos frigoríficos de supermercados comprometidos que já aqui contámos, fica claro que o alvo deixou há muito de ser o sistema operativo em si. É a cadeia de supply chain inteira. Em Arch, isso começa em não confiar em pacotes com nomes quase iguais aos que já se conhece e em aceitar que, se não se quer ler PKGBUILDs, talvez uma distribuição menos exposta seja a escolha mais saudável.

Fonte: BleepingComputer