Według CERT Polska 14 maja, po przejęciu konta opiekuna, w npm opublikowano zmodyfikowane wersje biblioteki node-ipc. Szkodliwy kod miał kraść między innymi poświadczenia programistów, tokeny CI/CD, klucze SSH i dane chmurowe. Dla firm tworzących oprogramowanie poniedziałek 18 maja zaczyna się więc od pytania, gdzie ten pakiet działał i jakie sekrety miał wtedy w zasięgu.
Co załatwia usunięcie zmodyfikowanej wersji node-ipc z projektu? Kusząca odpowiedź to „wszystko”, bo pakiet zniknął, a build znów jest czysty. Taka odpowiedź myli stan obecny z historią. Według opisu CERT Polska celem szkodliwego kodu były poświadczenia, a poświadczenie odczytane przez taki kod nie przestaje działać tylko dlatego, że w repozytorium zmieniono wersję zależności. Usunięcie pakietu zamyka drogę na przyszłość. Nie mówi nic o tym, co pakiet mógł zabrać, zanim go usunięto. Proponujemy więc odwrócić kolejność pytań. Najpierw ustalmy, gdzie zmodyfikowana wersja była instalowana i uruchamiana: na stacji roboczej programisty, w potoku CI/CD, na serwerze. Potem spiszmy sekrety dostępne w tych miejscach. Dopiero na końcu oceńmy, czy sama aktualizacja wystarczy.
Przejęte konto opiekuna zamieniło aktualizację w kanał ataku
Jak podaje CERT Polska w komunikacie z 15 maja, zmodyfikowane wersje node-ipc trafiły do npm 14 maja w wyniku przejęcia konta opiekuna. Ten szczegół zmienia ocenę zdarzenia. Zespół korzystający z biblioteki nie musiał popełnić żadnego błędu ani sięgać po podejrzane źródło. Wystarczyło, że jego proces pobrał z npm nową wersję, opublikowaną z konta, któremu ufał, i z niej skorzystał.
Stąd napięcie zawarte w tytule. Aktualizacja zależności zwykle uchodzi za czynność higieniczną: usuwa błędy i zamyka podatności. Tu ta sama czynność mogła wprowadzić do środowiska kod, którego zadaniem według CERT Polska była kradzież poświadczeń programistów, tokenów CI/CD, kluczy SSH i danych chmurowych. Atak wykorzystał zaufanie do konta opiekuna, a tego zaufania nie zweryfikuje żaden przegląd numeru wersji.
Fakty, którymi dysponujemy, nie mówią, jak długo zmodyfikowane wersje pozostawały dostępne ani ile instalacji objęły. Nie ma też podstaw, by zakładać, że każda instalacja skończyła się wyciekiem. Data 14 maja wystarcza jednak, żeby wyznaczyć początek okresu, który trzeba sprawdzić w każdym projekcie korzystającym z node-ipc.
Wersja pakietu mówi, co zainstalowano. O skali incydentu decyduje to, gdzie pakiet działał i jakie sekrety mógł tam przeczytać.
Historia wykonania pokazuje, które sekrety były w zasięgu
Procedura, która przy problematycznej zależności kończy się aktualizacją i zamknięciem zgłoszenia, przy node-ipc sprawdza niewłaściwą rzecz. Wymienione przez CERT Polska cele szkodliwego kodu układają się w mapę miejsc do odwiedzenia. Poświadczenia programistów prowadzą do stacji roboczych. Tokeny CI/CD prowadzą do potoków budowania i wdrażania. Klucze SSH mogą leżeć na laptopach i w agentach budujących. Dane chmurowe wskazują konta, na które te potoki wdrażają kod.
Każde z tych miejsc ma własną historię wykonania. Pakiet zainstalowany od 14 maja na komputerze jednego programisty to inny problem niż pakiet uruchamiany w potoku, który może publikować w repozytorium i wdrażać do chmury. Dlatego spis zależności nie wystarczy. Potrzebne jest zestawienie, które dla każdego środowiska podaje, kiedy zmodyfikowana wersja mogła się tam uruchomić i jakie poświadczenia były wtedy dostępne dla procesu.
Część tych danych może już nie istnieć. Agenty CI bywają tworzone na jedno zadanie i usuwane po nim, a logi budowania bywają przechowywane krótko. To powód, by zabezpieczyć dostępne zapisy od 14 maja, zanim rutynowe czyszczenie je usunie.
Jeśli nie da się wykazać, że sekret był poza zasięgiem zmodyfikowanego pakietu, trzeba go traktować jak ujawniony.
Decyzja o wymianie poświadczeń należy do kierownictwa
Wymiana tokenów CI/CD i kluczy SSH ma swój koszt: przerwane wdrożenia, ręczna zmiana integracji, czas kilku zespołów. Pozostawienie ich bez zmian ma koszt innego rodzaju. Jeśli wyciekły, ktoś może korzystać z uprawnień potoku albo konta chmurowego, a firma dowie się o tym po fakcie. Z faktów dotyczących node-ipc nie wynikają kwoty ani liczba poszkodowanych, więc porównanie finansowe byłoby zgadywaniem. Decyzję trzeba oprzeć na mapie środowisk i sekretów z poprzedniego kroku.
Odpowiedzialność przypiszmy jawnie, bo sekrety w CI/CD rzadko mają jednego właściciela. Token do repozytorium zakłada jeden zespół, konto chmurowe utrzymuje drugi, a pochodzenie klucza SSH do serwera wdrożeniowego zna często tylko osoba, która dawno przeszła do innego projektu. Bez wskazanego właściciela rotacja utknie na etapie ustalania, kogo zapytać.
Kierownictwo nie musi znać szczegółów publikacji pakietów w npm. Powinno natomiast zadać trzy pytania: które środowiska instalowały lub uruchamiały node-ipc od 14 maja, jakie poświadczenia tam były i kto zdecyduje o ich wymianie. Odpowiedź „zaktualizowaliśmy bibliotekę” nie odpowiada na żadne z nich.
Komunikat CERT Polska wyznacza ramy przeglądu w polskich zespołach
Dla polskich zespołów punktem odniesienia jest komunikat CERT Polska z 15 maja, opublikowany dzień po wprowadzeniu zmodyfikowanych wersji do npm. Do poniedziałku 18 maja minęły trzy dni, w tym weekend. Jeśli w tym czasie działały automatyczne buildy, przegląd powinien objąć także je.
W wewnętrznej notatce proponujemy rozdzielić trzy warstwy: co podał CERT Polska, co ustalono we własnych repozytoriach i potokach oraz czego nadal nie wiadomo. Opisane fakty nie mówią, ile polskich firm pobrało zmodyfikowaną wersję ani czy u którejkolwiek doszło do kradzieży danych. Tę lukę wypełni wyłącznie własny przegląd.
Nie dopisujmy też skali, której nie znamy. Raport dla zarządu powinien podawać zakres sprawdzenia (repozytoria, potoki CI/CD, stacje robocze, konta chmurowe) i jego granice. Brak śladów w logach przechowywanych tylko kilka dni oznacza brak danych i nie potwierdza, że sekrety pozostały bezpieczne.
Co z tym zrobić w poniedziałek
Każde działanie ogranicz do 30 minut i zapisz wynik razem z tym, czego nie udało się ustalić.
- Znajdź node-ipc w swoich projektach. Przeszukaj pliki blokady wersji (lockfile) w repozytoriach i logi buildów od 14 maja. Zestaw znalezione wersje z komunikatem CERT Polska i wypisz repozytoria, potoki oraz stacje robocze, w których biblioteka występuje.
- Spisz sekrety dostępne tam, gdzie pakiet działał. Dla każdego znalezionego środowiska zanotuj tokeny CI/CD, klucze SSH, poświadczenia programistów i dostęp do kont chmurowych. Przy każdej pozycji wpisz właściciela i to, czy da się ją wymienić jeszcze dziś.
- Wyznacz osobę, która decyduje o rotacji. Uzgodnij z osobą odpowiedzialną za reakcję na incydenty, kto zatwierdza wymianę poświadczeń i w jakiej kolejności. Przed czyszczeniem środowisk zabezpiecz logi buildów od 14 maja jako materiał do analizy.
Przejęte konto opiekuna wystarczyło, by zwykła aktualizacja zależności mogła otworzyć drogę do tokenów CI/CD, kluczy SSH i danych chmurowych. Incydent z node-ipc zamyka dopiero przegląd poświadczeń, które pakiet mógł zobaczyć. Zmiana numeru wersji kończy tylko jego pierwszy etap.
Źródła
Redakcja cyberinsight.pl.