Właściciele popularnych pakietów w języku Rust dostają zaproszenia na rozmowy wideo o pracę, które służą do przejmowania ich kont i urządzeń. Ostrzeżenie w tej sprawie opublikował 17 września zespół crates.io razem z grupą roboczą reagowania na incydenty. Miesiąc wcześniej podobny atak dał konkretny skutek. Pakiet arrayref przez 86 minut ciągnął za sobą zależność ze skryptem pobierającym obcy ładunek, a wgrało go konto samego autora.
Zaproszenie na rozmowę wideo, kodek do zainstalowania, przejęte konto
Zespół pisze, że według niego trwa kampania wymierzona w członków projektu rust-lang i właścicieli popularnych pakietów. Celem jest przejęcie kont i urządzeń po to, żeby opublikować z nich złośliwe oprogramowanie. Ostrożne sformułowanie nie jest przypadkowe: projekt opisuje to jako swoje przekonanie, a nie jako ustalenie śledztwa.
Scenariusz zaczyna się od czegoś dobrego. Ktoś umawia rozmowę wideo w sprawie pracy, projektu albo kontraktu. W trakcie rozmowy ofiara zostaje nakłoniona, żeby coś zainstalować. Projekt podaje przykład rzekomo brakującego kodeka audio. Drugi wariant to wykonanie polecenia, na przykład podrzuconego wcześniej do schowka.
Atakujący zakładają nowe, ale wiarygodnie wyglądające profile firm, razem z obecnością na LinkedInie. Rust pisze wprost, po co: żeby przejść pobieżną weryfikację. Ktoś, kto szybko sprawdza, czy firma istnieje, znajdzie stronę, profil i pracowników.
Osobnego zdania wymaga przypisanie. Projekt pisze, że ten styl ataku jest znany z działań Korei Północnej i widywano go również poza społecznością Rusta. Zdanie dotyczy metody, a nie tej konkretnej kampanii. O samych zdarzeniach zespół mówi ostrożniej: czerwcowy atak na znanych deweloperów Rusta, sierpniowa sprawa arrayref i obecne próby mogą, ale nie muszą być jedną sprawą. Liczby nie padają żadne.
Co się stało z pakietem arrayref w sierpniu
20 sierpnia o 7:15 czasu uniwersalnego zespół dostał zgłoszenie, że pakiet proc-macro1 jest złośliwy. Sprawdzenie potwierdziło zgłoszenie. Pakiet miał skrypt budujący, który pobierał obcy ładunek. Skrypt budujący wykonuje się automatycznie przy kompilacji projektu, więc wystarczy zbudować własny kod, żeby go uruchomić.
Problem nie kończył się na jednym podejrzanym pakiecie. Popularny arrayref został tuż wcześniej opublikowany w nowej wersji i uzależniony właśnie od tamtego. Ta sama historia dotknęła dwa inne pakiety tego samego autora, internment i append-only-vec. Zespół usunął złośliwe wersje, przywrócił te wycofane w złej wierze i zapobiegawczo zablokował konto.
| Pakiet | Złośliwa wersja | Ile minut była dostępna |
|---|---|---|
arrayref | 0.3.10 | 86 |
internment | 0.8.7 | 90 |
append-only-vec | 0.1.9 | 107 |
Najważniejsze zdanie komunikatu o tej sprawie dotyczy jednak człowieka, a nie kodu. Zespół napisał, że nie uważa autora arrayref za działającego w złej wierze. Jego komputer albo dane logowania są prawdopodobnie przejęte, a projekt próbował się z nim skontaktować.
Dlaczego atak na łańcuch dostaw oprogramowania przez konto opiekuna jest tak skuteczny
Podrobiony pakiet o łudząco podobnej nazwie da się wyłapać. Wystarczy uważnie przeczytać, co się instaluje. Nowa wersja pakietu, którego używasz od lat, nie wywołuje żadnego odruchu sprawdzania. Przechodzi przez zaufanie zbudowane przez lata pracy prawdziwego opiekuna.
Ratunkiem okazał się mechanizm, o którym mało kto myśli jak o zabezpieczeniu. Według wpisu w bazie RustSec złośliwą wersję arrayref pobrano 2 285 razy. To mniej niż jedna dziesiąta ruchu pobrań tego pakietu, bo większość projektów miała w pliku blokady zależności starszą wersję. Plik blokady zapisuje dokładne numery wersji i nie podnosi ich sam z siebie.
Wniosek jest praktyczny i dotyczy każdego menedżera pakietów, nie tylko Rusta. Plik blokady w repozytorium i świadome podnoszenie wersji kupują czas, którego w takiej sytuacji potrzeba najbardziej. Tu wystarczyło go półtorej godziny. Ten sam mechanizm zadziałałby przy złośliwych pakietach w RubyGems, gdzie atakujący też liczyli na automatyczne pobranie najnowszej wersji.
Jak rozpoznać taki kontakt, zanim cokolwiek zainstalujesz
Zalecenia projektu mieszczą się w czterech zdaniach i żadne z nich nie wymaga narzędzi. Traktuj nieoczekiwany kontakt z rezerwą. Rozmowę umawiaj sam, na platformie, której już używasz. Sprawdź, czy na twoich kontach włączone jest uwierzytelnianie wieloskładnikowe. Przejrzyj historię logowań tam, gdzie serwis ją pokazuje.
Do tego dochodzi jeden odruch wart wyrobienia. Instalowanie czegokolwiek w trakcie rozmowy rekrutacyjnej jest momentem, w którym warto się rozłączyć. Brakujący kodek, wtyczka do spotkania, polecenie do wklejenia w terminal: każde z nich można sprawdzić po rozmowie, a prawdziwy rozmówca to zrozumie. Krok po kroku opisaliśmy taką rozmowę przy backdoorze z fałszywej oferty pracy na LinkedInie, gdzie zadanie rekrutacyjne było nośnikiem złośliwego kodu.
Jeśli coś już kliknąłeś, projekt podaje dwa adresy. Sprawy kont w rejestrze pakietów idą na help@crates.io, pozostałe na security@rust-lang.org.
Co sprawdzić we własnych zależnościach
Przy sierpniowej sprawie zespół podał gotowy sposób na sprawdzenie, czy złośliwe wersje w ogóle trafiły na dysk. Wystarczy przeszukać lokalną pamięć podręczną menedżera pakietów, czyli katalog ~/.cargo/registry/cache, pod kątem nazw usuniętych pakietów. Usunięto wtedy proc-macro1, proc-macro-en, aovine, arone, aronenao i tinymember w każdej wersji.
Znalezienie takiego pliku nie kończy sprawy, tylko ją zaczyna. Skrypt budujący uruchamiał się przy kompilacji z uprawnieniami użytkownika, który ją zlecił. Jeśli pobrany ładunek również się uruchomił, miał dostęp do wszystkiego, co ten użytkownik miał pod ręką. Klucze SSH, żetony dostępu do repozytoriów i zmienne środowiskowe z hasłami trzeba wtedy wymienić, a nie tylko usunąć pakiet. To samo dotyczy maszyny budującej w serwerze ciągłej integracji, która zwykle trzyma sekrety o szerszym zasięgu.
Warto przy tym pamiętać o podziale ról. Rejestr pakietów usuwa złośliwą wersję i blokuje konto, ale nie odwiedzi twojego komputera. Skutki kodu, który zdążył się uruchomić w trakcie kompilacji, zostają po twojej stronie. Sprawę zgłosił zespół badawczy firmy Nextron Systems, a nie automat rejestru, więc reakcja mierzona w minutach była tu zasługą czyjejś uwagi.
Polska rekomendacja opisuje to samo zjawisko od drugiej strony
W Polsce rekrutacja jako droga ataku ma już oficjalny dokument, tyle że o odwróconym kierunku. Pod koniec kwietnia 2026 Pełnomocnik Rządu do spraw Cyberbezpieczeństwa wydał pilną rekomendację dla podmiotów krajowego systemu cyberbezpieczeństwa. Według relacji prasowych ostrzega ona przed grupami APT, które biorą udział w procesach zatrudniania po to, żeby wejść do organizacji i wykradać z niej dane.
Rozróżnienie warto trzymać, bo zaciera się w nagłówkach. Tamten dokument chroni pracodawcę przed fałszywym kandydatem. Sprawa Rusta dotyczy sytuacji odwrotnej, w której fałszywy pracodawca bierze na cel konkretnego programistę. Dla opiekuna pakietu w projekcie otwartoźródłowym żadna procedura kadrowa nie zadziała, bo po jego stronie nie ma działu HR ani weryfikacji kandydata.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie, ale czy robisz to dobrze?
Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia na żywym modelu, gamifikacja i certyfikat.
Sprawdź program kursu →
Najczęstsze pytania
Czy dotyczy to tylko języka Rust?
Nie. Rust opisał własne podwórko, bo za nie odpowiada, ale sam zaznacza, że ten styl ataku widywano również poza jego społecznością. Mechanizm jest niezależny od ekosystemu: wszędzie tam, gdzie jedna osoba może opublikować nową wersję biblioteki, jej konto jest wartościowym celem. Dotyczy to npm, PyPI, RubyGems i każdego innego rejestru pakietów.
Skąd mam wiedzieć, czy moje projekty pobrały złośliwą wersję?
Sprawdź plik blokady zależności w każdym projekcie i porównaj numery wersji z listą usuniętych pakietów. Drugim miejscem jest lokalna pamięć podręczna menedżera pakietów, w której leżą pobrane pliki. Cargo sprząta ją jednak samo i kasuje pliki z sieci nieużywane od trzech miesięcy, więc brak wpisu niczego nie przesądza. Jeśli projekt budował się w tym czasie na serwerze ciągłej integracji, sprawdź także ten dziennik, bo skrypt budujący uruchamia się również tam.
Podsumowanie
Łańcuch dostaw oprogramowania nie pęka dziś od włamania do rejestru pakietów, tylko od rozmowy o pracę z człowiekiem, który ma prawo publikować. Zespół crates.io ostrzegł 17 września, że według niego trwa kampania wymierzona w opiekunów popularnych pakietów w Ruście. Opisał schemat prób: umówiona rozmowa wideo, prośba o instalację rzekomo brakującego składnika, przejęte konto. Sierpniowa sprawa arrayref, która mogła, ale nie musiała należeć do tej samej kampanii, pokazała możliwy skutek. Złośliwą wersję pobrano 2 285 razy w ciągu 86 minut, czyli mniej niż jedną dziesiątą ruchu pobrań tego pakietu. Większość projektów miała starszą wersję zapisaną w pliku blokady zależności. Autora pakietu projekt uznaje za ofiarę, nie za sprawcę. Dla zespołu, który dziś aktualizuje zależności, wniosek sprowadza się do dwóch rzeczy: plik blokady w repozytorium i świadoma decyzja przy każdym podniesieniu wersji.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
