Cosa è successo: l’attacco all’AUR in sintesi
Il team di sicurezza di Arch Linux ha disabilitato le nuove registrazioni all’Arch User Repository (AUR) a seguito di una compromissione su larga scala. Tra il 13 e il 15 giugno 2026 gli attaccanti hanno dirottato o creato ex novo oltre 1.500 pacchetti gestiti dalla community per distribuire payload malevoli: information stealer e rootkit basati su eBPF. I repository ufficiali di Arch (core, extra, multilib) non sono stati colpiti grazie ai processi di review più stringenti dei maintainer ufficiali.
L’attacco si è sviluppato in due ondate distinte, entrambe basate su dipendenze JavaScript malevole inserite nei PKGBUILD:
- Prima ondata: uso di un pacchetto denominato
atomic-lockfileper eseguire binari ostili al momento del build - Seconda ondata (più sofisticata): introduzione di un binario separato tramite il pacchetto
js-digest, con tecniche di evasion più avanzate
Gli script malevoli erano progettati per scaricare e installare silenziosamente il malware sui sistemi degli utenti che avevano compilato i pacchetti compromessi dal sorgente.
Perché l’AUR è strutturalmente vulnerabile agli attacchi supply chain
L’AUR è un repository non ufficiale e non supportato di build script (PKGBUILD) contribuiti dalla community. Chiunque può creare un account e pubblicare un pacchetto; non esiste una review obbligatoria da parte del team Arch prima della pubblicazione. Questo modello “aperto” ha permesso all’ecosistema AUR di crescere fino a oltre 80.000 pacchetti, ma lo rende intrinsecamente più esposto rispetto ai repository ufficiali.
I vettori tipici di compromissione dell’AUR sono:
- Account hijacking: un attaccante prende controllo di un account maintainer inattivo (o con credenziali deboli) e pubblica commit malevoli su pacchetti legittimi e popolari
- Pacchetti typosquatting: creazione di nuovi pacchetti con nomi simili a quelli legittimi, sfruttando errori di battitura o la confusione tra nomi simili
- Dependency confusion: sostituzione di dipendenze interne con versioni malevole omonime pubblicate su registri pubblici
In questo caso l’attacco ha sfruttato principalmente l’account hijacking, con l’aggravante della catena di dipendenze JavaScript — un vettore sempre più usato in attacchi supply chain anche su ecosistemi npm e PyPI.
I payload: information stealer e rootkit eBPF
La scelta dei payload è tecnicament rilevante e vale la pena approfondirla.
Information Stealer
Gli information stealer raccolti in questa campagna erano progettati per estrarre credenziali, cookie di sessione browser, chiavi SSH, wallet di criptovalute e dati di configurazione da macchine Linux. Il targeting di sistemi Arch Linux (tipicamente macchine di sviluppatori, sysadmin e power user) massimizza il valore dei dati sottratti.
Rootkit eBPF
La componente più preoccupante è il rootkit basato su eBPF (Extended Berkeley Packet Filter). eBPF è una tecnologia del kernel Linux che consente l’esecuzione di programmi sandboxati direttamente nel kernel, originariamente pensata per networking e observability (usata da strumenti come Cilium, Falco, bpftrace). Abusata per scopi malevoli, permette di:
- Intercettare chiamate di sistema senza modificare file sul disco
- Nascondere processi, file e connessioni di rete agli strumenti di monitoring tradizionali
- Esfiltrare dati a livello di kernel, bypassando molti EDR
- Mantenere la persistenza in modo difficile da rilevare, dato che i programmi eBPF non appaiono nei normali listing dei processi
Un rootkit eBPF richiede privilegi elevati per essere caricato, ma una volta in esecuzione è significativamente più difficile da rilevare rispetto a un rootkit tradizionale basato su moduli kernel (LKM). Strumenti come bpftool permettono di enumerare i programmi eBPF caricati, ma un rootkit sofisticato può nascondere anche se stesso da questa enumerazione.
Come verificare se il proprio sistema è compromesso
Se si utilizza Arch Linux con pacchetti AUR installati nel periodo della compromissione, seguire questa procedura:
1. Verificare la presenza dei binari malevoli identificati
# Cercare i file associati alle due ondate dell'attacco
find / -name "atomic-lockfile" -o -name "js-digest" 2>/dev/null
# Cercare processi insoliti
ps aux | grep -E "(\.tmp|/tmp/\.|hidden)"2. Enumerare i programmi eBPF caricati
# Listare tutti i programmi eBPF attivi
sudo bpftool prog list
# Listare le mappe eBPF
sudo bpftool map list
# Ispezionare un programma specifico (sostituire ID con quello trovato)
sudo bpftool prog dump xlated id <ID>Programmi eBPF con nomi generici o vuoti, o di tipo kprobe/tracepoint non associati a tool di sistema noti, meritano approfondimento.
3. Controllare i pacchetti AUR installati recentemente
# Pacchetti installati nelle ultime 72 ore
grep -E "^\[ALPM\] installed" /var/log/pacman.log | tail -50
# Verificare l'integrità dei file installati
pacman -Qkk 2>&1 | grep -v "0 altered"4. Seguire le indicazioni ufficiali del team Arch
Il team di sicurezza Arch ha pubblicato checklist ufficiali per gli utenti colpiti, disponibili sul portale di sicurezza Arch Linux. Le azioni di cleanup includono la rimozione dei pacchetti compromessi, la revoca delle chiavi SSH potenzialmente esfiltrate e il cambio delle credenziali esposte.
Best practice per chi usa l’AUR
Questo attacco è un promemoria di regole che esistono da anni ma vengono spesso ignorate per comodità:
- Leggere sempre i PKGBUILD prima di installare. È la prima difesa. Un PKGBUILD malevolo è spesso riconoscibile da download di binari da URL non ufficiali, pipe a shell, o dipendenze insolite.
- Usare helper AUR con revisione esplicita. Tool come
parumostrano il diff del PKGBUILD prima di procedere. Non ignorare questo step. - Preferire pacchetti con molti voti e maintainer attivi. Non è una garanzia assoluta, ma riduce il rischio.
- Usare ambienti isolati per il build. Tool come
aurutilsconmakechrootpkgcompilano i pacchetti in un chroot pulito, limitando l’impatto di un PKGBUILD malevolo. - Monitorare le dipendenze JavaScript nei PKGBUILD. Pacchetti che scaricano moduli npm o yarn durante il build meritano attenzione extra, soprattutto se le dipendenze non sono verificate tramite hash.
- Abilitare audit di sistema.
auditdcon regole appropriate può rilevare comportamenti anomali durante e dopo l’installazione di pacchetti.
Implicazioni più ampie per la sicurezza della supply chain Linux
L’attacco all’AUR si inserisce in un trend preoccupante di compromissioni della supply chain su piattaforme open source. Nell’ultimo anno abbiamo visto attacchi analoghi su npm, PyPI, RubyGems e GitHub Actions. La peculiarità dell’ecosistema Linux è che molti degli utenti AUR sono sviluppatori e sysadmin con accesso privilegiato a infrastrutture aziendali: la compromissione di una workstation di uno sviluppatore può trasformarsi rapidamente in un punto di ingresso laterale verso sistemi di produzione.
La risposta del team Arch — blocco delle registrazioni, revert dei commit malevoli, ban degli account — è stata rapida ma reattiva. Il dibattito nella community si concentra ora su misure preventive: firma obbligatoria dei PKGBUILD, review automatizzata tramite analisi statica, e requisiti più stringenti per l’acquisizione di pacchetti esistenti. Nessuna di queste misure è banale da implementare mantenendo la natura aperta dell’AUR, ma l’attacco ha reso evidente il costo del modello attuale.
Fonti: 4sysops · The Hacker News · The Register