Arch Linux a dezactivat adoptarea de pachete în AUR ca să oprească un val de malware

Arch Linux a dezactivat temporar adoptarea de pachete în Arch User Repository (AUR) după un val de preluări malițioase. Atacatorii au adoptat pachete orfane și au injectat cod malițios în fișierele de build, ajungând la peste 200 de pachete. E un atac de supply-chain manual: nu au spart utilizatorii, ci sursa de la care aceștia instalau. Mai jos, cum a funcționat și ce înveți dacă depinzi de depozite comunitare.

Pe scurt

• Contributorul Arch Robin Candau a anunțat: „din cauza influxului actual de adoptări malițioase de pachete și de commit-uri ulterioare prin AUR, adoptarea de pachete e momentan dezactivată“.
• Atacatorii au adoptat pachete orfane sau au compromis conturi de mentenor, apoi au injectat cod în fișierele de build.
• Campania a început pe 29 iulie 2026 (primul pachet: openconnect-sso) și s-a extins la peste 200 de pachete.
• Malware în două etape: un loader anti-analiză + un infostealer scris în Rust, livrat prin Tor.
• Ținte: chei SSH, secrete cloud/dev, API key-uri (inclusiv de servicii AI), portofele crypto, parole.
• Măsura e temporară, până la o soluție permanentă (fără termen anunțat).

Cum au abuzat AUR-ul

AUR e întreținut de comunitate: utilizatorii pot adopta pachete orfane (abandonate de mentenorul original) sau prelua pachete existente. E util — și e exact vectorul. Atacatorii au preluat pachete orfane sau au compromis conturi de mentenor, apoi au modificat fișierele de build (PKGBUILD). Din acel moment, oricine instala pachetul își rula singur codul atacatorului, cu drepturile propriei sesiuni.

Pachete identificate ca afectate: boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin, openconnect-sso, arduino-language-server-noclang-bin, pgadmin4-server.

Ce face malware-ul

Lanțul are două etape:

• Etapa 1 — loader anti-analiză. Verifică dacă rulează sub debugger, sandbox, mașină virtuală sau CI/CD (ca să nu se demaște în laboratoarele de analiză). Își face persistență prin servicii systemd și cron, apoi descarcă un client Tor deghizat în „dbus-daemon“ ca să ia etapa a doua de pe un server .onion.
• Etapa 2 — infostealer în Rust. Fură credențiale din browser, portofele crypto, parole din manageri, secrete cloud/dev, API key-uri de servicii AI, chei SSH și tokenuri de mesagerie. Oferă execuție de comenzi la distanță prin Tor criptat și mișcare laterală folosind cheile SSH furate.

Detaliul care contează: nu e un atac oportunist de suprafață. E anti-analiză, persistent, criptat prin Tor, și vânează exact ce ține o echipă de development — chei, secrete, acces la infrastructură.

Nu e primul val

Analiza IFIN notează asemănări cu o campanie anterioară: în iunie 2026, peste 400 de pachete AUR fuseseră compromise pentru a distribui un rootkit și un infostealer, cu aceleași tactici, inclusiv folosirea rețelei Tor pentru staging. Modelul se repetă — depozitele comunitare rămân o suprafață de atac atractivă.

Ce înveți din asta

• Comunitar ≠ verificat. AUR (ca și npm, PyPI, extensii de browser/IDE) e supply-chain neverificat. „Adopția“ de pachete orfane e un mecanism util pe care atacatorii îl folosesc ca poartă.
• Citește ce instalezi. Pentru AUR, fișierul de build (PKGBUILD) e vizibil — citește-l înainte de a construi. Fixează versiunile și evită binarele opace (-bin) când poți.
• Stația de development e o țintă. Infostealer-ul vânează chei SSH, secrete cloud și API key-uri. Least privilege, rotația secretelor și separarea mediilor limitează ce poate fura o singură compromitere.
• Detecția e la comportament, nu la semnătură. Loader-ul evită sandbox-urile și folosește Tor către .onion. Monitorizarea egress-ului și a comportamentului prinde ce antivirusul pe semnături ratează.

Recomandările noastre

Dacă echipa ta depinde de pachete externe și dezvoltatorii rulează cod de la terți, de aici am începe noi:

• Audit de supply-chain și de secrete. Inventariem de unde îți iei dependențele, cum sunt fixate și verificate, și cât de expuse sunt cheile și secretele pe stațiile și în pipeline-urile de development. Parte din auditul de securitate.
• Testare de securitate. Un test de penetrare verifică nu doar aplicația, ci și lanțul de build și livrare — exact unde intră un pachet compromis.
• Securitate continuă. Un mentenor upstream se poate compromite oricând; monitorizarea și revizuirea periodică prind execuția neobișnuită și egress-ul suspect când se întâmplă.

Vrei să știi cât de expus e lanțul tău de dependențe și ce ar putea fura o singură stație compromisă? Scrie-ne și pornim de la un audit.