Atomic Arch: Jak 1900 pakietów Arch Linux zostało zamienionych w broń

W czerwcu 2026 roku doszło do systematycznego ataku na łańcuch dostaw repozytorium Arch User Repository (AUR), który skompromitował prawie 1900 pakietów utrzymywanych przez społeczność. Był to jeden z największych incydentów w historii tego repozytorium. Kampania, nazwana przez badaczy z firmy Sonatype Atomic Arch i śledzona jako Sonatype-2026-003775 z wynikiem CVSS 8.7, wykorzystała legalny mechanizm zaufania, aby po cichu wdrożyć na stacjach roboczych deweloperów złośliwe oprogramowanie wykradające dane uwierzytelniające oraz rootkit działający na poziomie jądra systemu .

Skala i harmonogram ataku

To, co początkowo wydawało się ograniczonym incydentem, w ciągu jednego weekendu przekształciło się w ogromną kompromitację.

• 11 czerwca 2026 (Pierwsza fala): Firma Sonatype zidentyfikowała pierwszą falę ataku, potwierdzając kompromitację około 408 pakietów .
• 12 czerwca 2026 (Druga fala): Druga fala rozszerzyła zasięg ataku. Zestawienia społeczności i badacze z PrivacyGuides poinformowali, że liczba zainfekowanych pakietów przekroczyła 1500 .
• 14-15 czerwca 2026 (Eskalacja): Dalsza analiza przeprowadzona przez Corgea Research potwierdziła co najmniej 1619 unikalnych nazw złośliwych pakietów, podczas gdy serwis Risky.biz podał, że ostateczna liczba przekroczyła 1900 .

Strona kampanii SafeDep oraz skonsolidowane listy społeczności ostatecznie wyliczyły 1937 zainfekowanych nazw pakietów AUR, co podkreśla ogromny zasięg ataku . Co ważne, oficjalne repozytoria Arch Linux (core, extra, community) nie zostały naruszone – był to incydent dotyczący wyłącznie AUR .

Metoda ataku: Wykorzystanie przepływu pracy opartego na zaufaniu

Atomic Arch nie był włamaniem do infrastruktury Arch Linux. Zamiast tego było to precyzyjne wykorzystanie procedury przejmowania osieroconych pakietów w AUR, która pozwala każdemu członkowi społeczności na przejęcie własności nad porzuconymi pakietami .

Atak przebiegał w dwóch odrębnych falach, a sprawcy udoskonalali swoje podejście, aby uniknąć wykrycia.

Fala 1: Hak przez npm (11 czerwca)

Atakujący systematycznie przejmowali osierocone pakiety. Po uzyskaniu uprawnień opiekuna nie zmieniali samego kodu źródłowego oprogramowania – co naruszyłoby sumy kontrolne i uruchomiło alarmy. Zamiast tego modyfikowali skrypty budowania PKGBUILD, aby wstrzykiwać złośliwe zależności npm: atomic-lockfile (wersja 1.4.2) i js-digest (wersja 4.2.2) . Pakiety te były skonfigurowane tak, aby uruchamiały się automatycznie podczas procesu makepkg. Aby lepiej ukryć złośliwą aktywność, kod był osadzany w skryptach .install i maskowany za pomocą dzielenia ciągów znaków powłoki, mieszanego cytowania i szesnastkowych sekwencji escape .

Fala 2: Zwrot ku Bun (12 czerwca)

Zaledwie dzień później pojawiła się druga fala. Tym razem atakujący zastąpili ścieżkę instalacji npm procesem opartym na środowisku uruchomieniowym Bun, wykorzystując inny złośliwy pakiet o nazwie lockfile-js (wersja 1.4.2) . Ta zmiana utrudniła wykrycie, ponieważ wiele wczesnych wskaźników kompromitacji (IoC) koncentrowało się na rejestrze npm, a narzędzia bezpieczeństwa musiały zostać zaktualizowane, aby monitorować nowe środowisko uruchomieniowe i zależności .

Zatruwając jedynie instrukcje budowania, a nie samo oprogramowanie, atakujący ominęli tradycyjne mechanizmy kontroli integralności. Kod źródłowy wydawał się czysty, a złośliwe oprogramowanie było pobierane i uruchamiane dopiero na etapie budowania, co czyniło je niewidocznym dla użytkowników, którzy nie przeglądali ręcznie skryptów PKGBUILD .

Złośliwe ładunki: Narzędzie do kradzieży danych i rootkit

Maszyny, które zbudowały skompromitowane pakiety, otrzymywały dwustopniowy ładunek zaprojektowany do szpiegostwa i zapewnienia trwałości w systemie.

• Narzędzie do kradzieży danych uwierzytelniających napisane w Rust: Wyspecjalizowany plik binarny, który wykradał sekrety dewelopera, w tym sesje przeglądarki, klucze SSH, tokeny GitHub, tokeny npm, sesje Slack/Teams, tokeny Vault, dane logowania Docker/Podman oraz klucze dostępu do chmury .
• Rootkit eBPF (tylko przy uprawnieniach roota): Jeśli pakiet był budowany z uprawnieniami administratora, złośliwe oprogramowanie wdrażało rootkit eBPF zdolny do ukrywania własnych plików, procesów i aktywności sieciowej przed standardowymi narzędziami wykrywającymi, takimi jak ps i htop. Rootkit wykorzystywał katalog /sys/fs/bpf/ do zapewnienia trwałości, co czyniło go wyjątkowo trudnym do usunięcia .

Połączenie narzędzia do kradzieży danych uwierzytelniających i rootkita na poziomie jądra stanowiło poważne zagrożenie, szczególnie dla deweloperów, których stacje robocze często przechowują uprzywilejowane klucze dostępu i wrażliwe dane.

Reakcja społeczności i deweloperów

Społeczność Arch Linux i branża bezpieczeństwa zareagowały szybko, ale skala ataku utrudniła działania.

• Działania zespołu Arch: Współtwórcy Arch otworzyli skonsolidowany wątek raportowania w AUR 11 czerwca i rozpoczęli proces przywracania złośliwych commitów, banowania kont atakujących i czyszczenia puli osieroconych pakietów. Arch Linux zawiesił również w następny poniedziałek rejestrację nowych kont w AUR, aby zapobiec dalszym nadużyciom . Opiekun pakietów Arch, Jonathan Grotelüschen, potwierdził, że zespół pracuje nad „przywróceniem lub usunięciem wszystkich złośliwych commitów i zbanowaniem odpowiedzialnych kont” .
• Konflikt w społeczności: Atak wywołał intensywną debatę. Gorące dyskusje na platformach takich jak forum PrivacyGuides doprowadziły do tego, że niektórzy członkowie społeczności wzywali do całkowitego zamknięcia AUR, argumentując, że jego model oparty na zaufaniu jest fundamentalnie wadliwy w obliczu kompromitacji na taką skalę .
• Reakcja firm trzecich: Firmy bezpieczeństwa, w tym Sonatype, Corgea, Cloud Security Alliance (CSA) i TrueSec, opublikowały szczegółowe analizy, wskaźniki kompromitacji (IoC) i społecznościowe skrypty wykrywające (takie jak aur-malware-check), aby pomóc użytkownikom w audycie ich systemów .

Kluczowym źródłem nieporozumień było to, że oficjalny zespół Arch nie opublikował natychmiast jednej, kanonicznej listy wszystkich zafałszowanych pakietów, co zmusiło użytkowników do polegania na zewnętrznych wykazach ze źródeł takich jak SafeDep i Corgea .

Lekcje dla ekosystemu Linux

Atak Atomic Arch obnaża strukturalne słabości repozytoriów społecznościowych opartych na zaufaniu, które polegają na dobrowolnym utrzymaniu pakietów.

• Pułapka osieroconych pakietów jest ryzykiem systemowym: Możliwość natychmiastowego przejęcia i modyfikacji porzuconego pakietu przez dowolnego użytkownika, bez weryfikacji tożsamości czy obowiązkowego przeglądu kodu, przekształciła wygodną funkcję w wektor ataku o wysokim wpływie .
• Wstrzykiwanie kodu na etapie budowania omija kontrolę integralności: Tradycyjne mechanizmy obronne opierają się na weryfikacji integralności archiwów kodu źródłowego. Ponieważ Atomic Arch zatruwał skrypty budowania, a nie kod źródłowy, standardowe sumy kontrolne nie zapewniały żadnej ochrony .
• Międzyekosystemowe łańcuchy dostaw to nowa granica ataków: Atak wykorzystał rejestry npm i Bun do dystrybucji złośliwego oprogramowania w ekosystemie Linux, udowadniając, że pojedynczy skompromitowany pakiet w jednym rejestrze może mieć kaskadowe skutki na różnych platformach .

Co muszą teraz zrobić poszkodowani użytkownicy

Badacze bezpieczeństwa i wytyczne społeczności Arch są jednomyślne: samo usunięcie pakietu nie jest wystarczające.

1. Załóż pełną kompromitację: Traktuj każdy host, który zbudował lub zaktualizował pakiet AUR między 9 a 12 czerwca 2026 r., jako w pełni skompromitowany .
2. Przeprowadź ponowną instalację z czystego nośnika: Proste skanowanie antywirusowe jest niewiarygodne, ponieważ rootkit eBPF jest zaprojektowany tak, aby ukrywać się przed narzędziami wykrywającymi. Jedynym gwarantowanym środkiem zaradczym jest przebudowa zaatakowanego systemu z zaufanego nośnika instalacyjnego .
3. Natychmiast zmień wszystkie dane uwierzytelniające: Załóż, że narzędzie do kradzieży danych wykradło każdy sekret dostępny na komputerze: klucze SSH, tokeny GitHub i npm, tokeny Vault, klucze dostępu do chmury, sesje przeglądarki oraz dane logowania Docker/Podman .
4. Przeprowadź audyt historii AUR: Uruchom polecenie

   pacman -Qm

   , aby wyświetlić wszystkie pakiety zewnętrzne zainstalowane w systemie i porównaj je z listami złośliwych pakietów opublikowanymi przez społeczność .
5. Sprawdź wskaźniki kompromitacji: Przeszukaj pamięć podręczną budowania w poszukiwaniu śladów atomic-lockfile, lockfile-js lub js-digest, a także podejrzanych wpisów w katalogu /sys/fs/bpf/ .
6. Potraktuj to jako zdarzenie wymagające reakcji na incydent bezpieczeństwa: Firmy nie powinny traktować tego jako prostego ćwiczenia skanowania. Każda deweloperska stacja robocza z Arch Linux lub serwer CI/build, który pobierał pakiety z AUR w oknie ataku, powinien być traktowany jako incydent bezpieczeństwa wymagający pełnej reakcji .