Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw systemu coraz częściej uderzają w środowiska CI/CD, ponieważ to właśnie tam przetwarzane są tokeny, sekrety oraz poświadczenia do repozytoriów i usług chmurowych. Najnowszy incydent przypisywany grupie TeamPCP pokazuje, iż przejęcie zaufanego elementu pipeline’u może stać się punktem wyjścia do dalszej kompromitacji projektów, narzędzi deweloperskich i infrastruktury organizacji.
W opisywanym przypadku celem były workflowy GitHub Actions utrzymywane przez Checkmarx. Atakujący mieli wykorzystać złośliwy ładunek kradnący dane z runnerów CI, co wpisuje się w rosnący trend nadużywania zaufanych komponentów automatyzacji do przejmowania kolejnych etapów procesu wytwarzania oprogramowania.
W skrócie
- TeamPCP miało skompromitować dwa workflowy GitHub Actions powiązane z Checkmarx.
- Złośliwy kod służył do kradzieży poświadczeń i sekretów z runnerów CI.
- Atak przypomina wcześniejsze działania obserwowane w kampanii związanej z Trivy.
- Napastnicy mogli wykorzystywać przejęte dane do modyfikacji tagów, publikacji skażonych artefaktów i dalszej eksfiltracji informacji.
- Dodatkowym elementem operacji były trojanizowane rozszerzenia publikowane w ekosystemie Open VSX.
Kontekst / historia
Incydent nie wygląda na odosobnione zdarzenie. Z dostępnych analiz wynika, iż TeamPCP było wcześniej łączone z kompromitacją innych elementów ekosystemu bezpieczeństwa i DevSecOps, w tym komponentów związanych z Trivy. Wspólne cechy obejmują podobny typ malware kradnącego dane, zbliżony sposób eksfiltracji oraz schemat działania skoncentrowany na środowiskach chmurowych, pipeline’ach buildów i repozytoriach kodu.
W przypadku Checkmarx wskazano dwa projekty GitHub Actions jako dotknięte kompromitacją. Pojawiły się także informacje o przejęciu konta usługowego używanego do publikacji komponentów oraz o wypuszczeniu złośliwych wersji rozszerzeń deweloperskich. Jednocześnie komunikaty producenta sugerowały brak wpływu na dane klientów i środowiska produkcyjne, co nie zmienia faktu, iż organizacje korzystające z zagrożonych artefaktów powinny traktować zdarzenie jako pełnoprawny incydent bezpieczeństwa.
Analiza techniczna
Trzonem ataku był złośliwy skrypt typu stealer osadzony w zaufanych akcjach GitHub poprzez manipulację tagami i przekierowanie ich na złośliwe commity. Taka technika jest szczególnie skuteczna w organizacjach, które przypinają zależności CI/CD do tagów wersji zamiast do pełnych identyfikatorów commitów. W efekcie pipeline może uruchomić zmodyfikowaną akcję bez jakichkolwiek zmian widocznych w konfiguracji.
Zadaniem ładunku było pozyskiwanie danych z runnera CI, w tym kluczy SSH, tokenów GitHub, poświadczeń do AWS, Google Cloud i Microsoft Azure, konfiguracji Kubernetes i Dockera, plików środowiskowych oraz innych sekretów używanych w trakcie budowania i testowania oprogramowania. Taki zakres zbieranych informacji sugeruje, iż celem operacji nie było tylko przejęcie pojedynczego repozytorium, ale uzyskanie możliwości dalszego poruszania się po infrastrukturze ofiary.
Istotnym elementem było także ukrywanie eksfiltracji danych. Ruch wychodzący miał być kierowany do infrastruktury podszywającej się pod legalny zasób związany z ofiarą, co utrudnia wykrycie podczas pobieżnej analizy logów. Dodatkowo malware mogło tworzyć repozytorium zapasowe z wykorzystaniem tokena ofiary, aby przechowywać wykradzione dane wtedy, gdy bezpośrednia eksfiltracja do serwera kontrolowanego przez napastników nie była możliwa.
Najgroźniejszy był jednak efekt kaskadowy. jeżeli runner CI uruchamiał skażoną akcję i jednocześnie dysponował tokenem z uprawnieniami zapisu do innych repozytoriów, napastnicy mogli wykorzystać przejęte dane do kompromitacji kolejnych projektów. W praktyce taki model prowadzi do samonapędzającego się ataku supply chain, w którym jedno zatrute ogniwo umożliwia skażenie następnych.
Dodatkowym wektorem były zainfekowane rozszerzenia dla środowisk programistycznych publikowane w Open VSX. Po instalacji taki komponent miał sprawdzać obecność poświadczeń do usług chmurowych i platform deweloperskich, a następnie pobierać kolejny etap ładunku. Na systemach niebędących runnerami CI złośliwe oprogramowanie mogło również ustanawiać mechanizm przetrwania, rozszerzając zagrożenie na stacje robocze programistów.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tego typu incydentu jest utrata integralności zaufanych komponentów procesu wytwarzania oprogramowania. o ile organizacja korzystała z zainfekowanych GitHub Actions lub trojanizowanych rozszerzeń, mogło dojść do wycieku tokenów, kluczy oraz danych dostępowych do środowisk chmurowych i repozytoriów kodu.
Ryzyko nie kończy się na samym wycieku. Przejęte poświadczenia mogą zostać użyte do modyfikacji kodu źródłowego, publikacji złośliwych artefaktów, przejmowania nowych repozytoriów, a choćby uzyskania dostępu do systemów uruchomieniowych. W środowiskach wielochmurowych oraz zintegrowanych z Kubernetes konsekwencje mogą obejmować eskalację do kontroli nad kontenerami, klastrami i usługami produkcyjnymi.
Dodatkowym problemem jest niska wykrywalność takiej operacji. Tradycyjne przeglądy kodu i skanowanie zależności nie zawsze wychwytują kompromitację, jeżeli złośliwy kod został wstrzyknięty bezpośrednio do zaufanej akcji u źródła. Organizacja może więc przez dłuższy czas uruchamiać legalnie wyglądający komponent, który poza deklarowaną funkcją potajemnie kradnie sekrety.
Rekomendacje
Organizacje, które mogły korzystać z zagrożonych artefaktów, powinny w pierwszej kolejności przeprowadzić pełną rotację wszystkich sekretów dostępnych dla runnerów CI w okresie potencjalnej kompromitacji. Obejmuje to tokeny GitHub, klucze SSH, dane dostępowe do chmury, sekrety Kubernetes, poświadczenia bazodanowe oraz wartości przechowywane w zmiennych środowiskowych.
- Przejrzeć logi workflowów pod kątem nietypowych połączeń wychodzących, archiwów i nowych repozytoriów tworzonych automatycznie.
- Zweryfikować historię tagów wersji i sprawdzić, czy nie doszło do force-push lub nieautoryzowanych zmian wskaźników.
- Przypinać GitHub Actions do pełnych SHA commitów zamiast do tagów lub ruchomych wersji.
- Ograniczyć uprawnienia tokenów i kont serwisowych zgodnie z zasadą najmniejszych uprawnień.
- Segmentować sieć runnerów oraz ograniczyć ruch wychodzący wyłącznie do zatwierdzonych lokalizacji.
- Monitorować tworzenie nietypowych repozytoriów, publikację nowych artefaktów i rozszerzeń poza zatwierdzonym pipeline’em.
- Sprawdzić stacje deweloperskie pod kątem mechanizmów trwałości i podejrzanych rozszerzeń.
Z perspektywy strategicznej najważniejsze jest traktowanie runnerów CI jako systemów uprzywilejowanych o wysokiej wartości. Każdy sekret dostępny podczas builda może mieć skutki wykraczające daleko poza jedno repozytorium, dlatego ochrona integralności pipeline’u powinna być priorytetem zarówno dla zespołów bezpieczeństwa, jak i dla inżynierów platformowych.
Podsumowanie
Incydent przypisywany TeamPCP pokazuje, iż nowoczesna kompromitacja łańcucha dostaw nie musi zaczynać się od wykorzystania klasycznej podatności. Wystarczy przejęcie poświadczeń CI i możliwość manipulacji zaufanym artefaktem, aby uruchomić efekt domina obejmujący repozytoria, rozszerzenia deweloperskie i środowiska chmurowe.
Dla organizacji najważniejszą lekcją jest konieczność wdrożenia twardych kontroli integralności, ograniczonych uprawnień, monitoringu anomalii oraz szybkiej rotacji sekretów po każdym podejrzeniu kompromitacji. CI/CD nie może być traktowane wyłącznie jako warstwa automatyzacji — to dziś jeden z najbardziej krytycznych elementów całego krajobrazu bezpieczeństwa.
