Arch Linux wyłączył przejmowanie pakietów AUR po fali malware

Projekt Arch Linux czasowo wyłączył adopcję osieroconych pakietów w Arch User Repository, a następnie także możliwość wykonywania pushów. Powodem była fala złośliwych przejęć i kolejnych commitów rozprowadzających wieloetapowe malware dla Linuksa.

AUR jest społecznościowym repozytorium instrukcji budowania pakietów, nie oficjalnym repozytorium binariów Arch. Ta różnica nie zmniejsza ryzyka: PKGBUILD i powiązane skrypty są kodem wykonywanym na maszynie użytkownika podczas budowania lub instalacji.

Co potwierdził Arch Linux

W komunikacie na oficjalnej liście aur-general zespół DevOps napisał o napływie złośliwych adopcji oraz commitów. Najpierw wyłączono samą adopcję pakietów, a następnie wszystkie pushe, aby opanować sytuację.

To potwierdza problem procesu publikacji. Oficjalny komunikat nie podaje pełnej liczby pakietów, wszystkich nazw ani zakresu infekcji użytkowników. Doniesienia o ponad 200 paczkach pozostawały niezweryfikowaną publicznie estymacją, więc nie należy przedstawiać ich jako liczby potwierdzonej przez Arch.

Jak działa adopcja w AUR

Pakiet może zostać porzucony przez maintenera. Inny użytkownik może go przejąć i kontynuować utrzymanie. Mechanizm jest potrzebny, bo społecznościowe projekty tracą opiekunów, a popularne narzędzia nie powinny pozostać bez aktualizacji.

Napastnik może jednak:

1. wyszukać osierocony, nadal popularny pakiet;
2. przejąć rolę maintenera;
3. dodać pozornie uzasadnioną aktualizację;
4. zmienić źródło, sumę kontrolną lub skrypt;
5. wykorzystać zaufanie użytkowników do istniejącej nazwy.

To przejęcie reputacji pakietu, nie typosquatting nowej nazwy.

Dwustopniowy łańcuch

Niezależna analiza techniczna opisywana przez media wskazuje kampanię zaczynającą się 29 lipca od openconnect-sso. Pierwszy etap sprawdzał debuggery, sandboxy, maszyny wirtualne i środowiska CI/CD, a następnie tworzył trwałość przez systemd i cron.

Loader uruchamiał klienta Tor udającego dbus-daemon i pobierał drugi etap z usługi .onion. Payload Rust łączył funkcje:

• infostealera;
• zdalnego dostępu;
• wykonywania poleceń przez Tor;
• robaka rozprzestrzeniającego się przez skradzione klucze SSH.

Cele obejmowały poświadczenia przeglądarek, portfele kryptowalut, dane menedżerów haseł, sekrety chmurowe i deweloperskie, klucze API usług AI, klucze SSH oraz tokeny komunikatorów.

Dlaczego klucz SSH zmienia skalę

Stacja dewelopera często ma dostęp do Git, serwerów, CI/CD i środowisk testowych. Kradzież prywatnego klucza może więc przenieść incydent z laptopa do infrastruktury.

Robak nie potrzebuje podatności sieciowej, jeśli:

• agent SSH ma załadowany klucz;
• plik klucza nie wymaga dodatkowego uwierzytelnienia;
• serwery ufają temu samemu kontu;
• dostęp nie jest ograniczony źródłem i komendą;
• brak centralnego logowania użycia klucza.

Dlatego reakcja na złośliwy pakiet musi objąć tożsamości, a nie tylko usunięcie paczki.

Co powinien zrobić użytkownik AUR

Jeżeli instalowałeś lub aktualizowałeś AUR w czasie kampanii:

1. sprawdź historię użytego helpera i cache źródeł;
2. porównaj PKGBUILD, .SRCINFO i historię commitów;
3. zweryfikuj adresy źródeł i sumy kontrolne;
4. przejrzyj nowe jednostki systemd użytkownika i systemu;
5. sprawdź crontab, autostart i procesy udające usługi systemowe;
6. przeanalizuj połączenia do Tor i nietypowe trwałe sesje;
7. unieważnij tokeny oraz klucze dostępne na podejrzanym hoście;
8. sprawdź logi SSH serwerów osiągalnych ze stacji;
9. wykonaj analizę offline przed ponownym użyciem urządzenia;
10. przy potwierdzonej infekcji odbuduj system z zaufanego obrazu.

Nie rotuj wyłącznie hasła użytkownika. Sekrety przeglądarek, chmury, repozytoriów, AI i SSH mają oddzielne cykle unieważniania.

Jak bezpieczniej korzystać z AUR

• czytaj zmiany przed budowaniem;
• nie aktualizuj AUR bez nadzoru w produkcji;
• buduj w izolowanym użytkowniku lub kontenerze bez sekretów;
• nie montuj agenta SSH i katalogów chmurowych do środowiska budowania;
• preferuj reprodukowalne, podpisane źródła;
• alarmuj na zmianę maintenera lub domeny pobierania;
• utrzymuj proxy artefaktów dla organizacji;
• dopuszczaj pakiety przez wewnętrzny przegląd;
• zapisuj dokładną wersję i hash użytego źródła.

Sandbox nie eliminuje ryzyka, jeśli zbudowany artefakt trafi później do produkcji. Potrzebne są także pochodzenie, review i kontrola promocji.

Lekcja dla innych ekosystemów

Problem dotyczy npm, PyPI, RubyGems, Homebrew i rozszerzeń IDE. Popularna nazwa jest aktywem, a zmiana właściciela jest zdarzeniem bezpieczeństwa. Rejestr powinien stosować opóźnienie, dodatkową weryfikację, powiadomienie obserwujących i analizę różnic po przejęciu.

Więcej opisujemy w przewodniku ataki na łańcuch dostaw oprogramowania oraz materiale o SBOM, CycloneDX i VEX.

Fakty a wnioski Breachroad

Arch potwierdził złośliwe adopcje, wyłączył adopcję i czasowo zablokował pushe. Szczegóły malware pochodzą z niezależnej analizy, a liczba „ponad 200” nie została potwierdzona przez projekt.

Wniosek Breachroad: przejęcie utrzymywanego pakietu jest groźniejsze od wielu nowych fałszywek, bo dziedziczy instalacje, reputację i automatyczne aktualizacje. Kontrolą krytyczną jest wykrywanie zmiany właściciela i zachowania procesu budowania.

Szkolenia cyberbezpieczeństwa dla deweloperów pomagają rozpoznawać ryzyko zależności i reagować bez niszczenia dowodów. Audyt bezpieczeństwa IT może objąć stacje deweloperskie, proxy pakietów, SSH i CI/CD.