Naruszenie Trivy GitHub Actions: przejęte tagi umożliwiły kradzież sekretów CI/CD

securitybeztabu.pl 2 dni temu

Wprowadzenie do problemu / definicja

Incydent związany z Trivy pokazuje, iż współczesne ataki na łańcuch dostaw systemu coraz częściej koncentrują się na automatyzacji CI/CD. W tym przypadku celem nie były wyłącznie pakiety czy artefakty, ale również zaufane akcje GitHub Actions, które w wielu organizacjach stanowią integralny element procesu budowania, testowania i wdrażania aplikacji.

Kluczowym mechanizmem wykorzystanym przez napastników było przejęcie tagów wersji i skierowanie ich na złośliwe commity. Taka technika pozwala uruchomić nieautoryzowany kod w pipeline’ach bez konieczności modyfikowania samej konfiguracji workflow po stronie ofiary.

W skrócie

Naruszenie objęło oficjalne repozytoria aquasecurity/trivy-action oraz aquasecurity/setup-trivy. Z dostępnych ustaleń wynika, iż napastnik przepisał większość tagów wersji w tych projektach, tak aby wskazywały na złośliwe rewizje.

Po uruchomieniu w środowisku GitHub Actions złośliwy kod próbował pozyskiwać sekrety i dane uwierzytelniające obecne w runnerach CI/CD. Zakres potencjalnie przejętych informacji obejmował między innymi klucze SSH, tokeny GitHub, dane dostępowe do usług chmurowych, rejestrów kontenerów, baz danych oraz środowisk Kubernetes.

atak dotknął zaufanych akcji używanych w pipeline’ach bezpieczeństwa,
wektor opierał się na zatruciu tagów wersji,
celem była kradzież sekretów z runnerów CI/CD,
incydent wpisuje się w szerszy łańcuch wcześniejszych naruszeń wokół Trivy.

Kontekst / historia

Sprawa nie pojawiła się w próżni. To kolejny incydent dotyczący ekosystemu Trivy w krótkim czasie. Wcześniejsze doniesienia wskazywały na kompromitację środowiska projektu i przejęcie poświadczeń, które mogły zostać następnie wykorzystane do dalszych działań ofensywnych.

Jednym z wcześniejszych sygnałów ostrzegawczych była publikacja podejrzanej wersji narzędzia, która łączyła prawidłowe funkcje skanera z dodatkowym kodem służącym do kradzieży danych. Obecny przypadek rozszerzył jednak skalę problemu, ponieważ objął GitHub Actions, czyli komponenty automatyzacji powszechnie uruchamiane z wysokimi uprawnieniami w środowiskach deweloperskich i produkcyjnych.

Szczególnie istotne jest to, iż wiele organizacji odnosi się do akcji po tagach wersji, zakładając ich stabilność i niezmienność. Incydent pokazał, iż jeżeli atakujący zdobędzie odpowiednie poświadczenia, może przesunąć tag na inny commit i w praktyce przejąć wykonanie w cudzych pipeline’ach.

Analiza techniczna

Technika użyta w ataku jest określana jako tag poisoning. Zamiast klasycznej kompromitacji głównej gałęzi kodu źródłowego napastnik nadpisuje istniejące tagi Git, przez co odwołania typu @v1 lub @vX.Y.Z zaczynają wskazywać na złośliwy commit. Dla użytkownika workflow wygląda poprawnie, ale pobierana zawartość nie jest już tą samą rewizją, której wcześniej ufał.

W praktyce oznacza to, iż każdy pipeline odwołujący się do skompromitowanego tagu mógł pobrać i uruchomić nieautoryzowaną akcję. To bardzo niebezpieczny scenariusz, ponieważ działania wykonywane przez runnera często obejmują dostęp do sekretów, repozytoriów, artefaktów oraz infrastruktur chmurowych.

Analizy wskazują, iż malware działał etapowo. Najpierw zbierał zmienne środowiskowe i dane z systemu plików runnera, następnie przygotowywał je do eksfiltracji i próbował przesłać do infrastruktury kontrolowanej przez napastnika. Wśród poszukiwanych danych znajdowały się:

sekrety GitHub Actions,
klucze SSH,
poświadczenia do usług chmurowych,
konfiguracje Git i Docker,
tokeny Kubernetes,
inne wrażliwe dane obecne w środowisku uruchomieniowym.

W części analiz opisywano również mechanizm awaryjny: jeżeli standardowa eksfiltracja nie była możliwa, złośliwy kod miał wykorzystywać przejęte poświadczenia GitHub do publikacji skradzionych danych w publicznym repozytorium. Taki model zwiększa odporność operacji i utrudnia wykrywanie oparte wyłącznie na blokadzie pojedynczych hostów lub domen.

Konsekwencje / ryzyko

Skutki kompromitacji pipeline’u CI/CD mogą wykraczać daleko poza sam wyciek sekretów. Runner budujący oprogramowanie często posiada szeroki dostęp do repozytoriów, środowisk testowych, rejestrów kontenerów, a niekiedy również do produkcji. To czyni go atrakcyjnym punktem wejścia do dalszej eskalacji i ruchu bocznego.

Najważniejsze ryzyka obejmują przejęcie poświadczeń wykorzystywanych do wdrożeń, modyfikację artefaktów produkcyjnych, wstrzyknięcie backdoora do obrazów kontenerów oraz trwałe naruszenie zaufania do procesu dostarczania oprogramowania. W skrajnym scenariuszu organizacja może nieświadomie podpisywać i publikować złośliwe komponenty jako własne, legalne wydania.

Niepokojące jest również to, iż atak nie wymagał luki w samym GitHubie. Wystarczyło wykorzystanie prawidłowych, ale skompromitowanych poświadczeń z odpowiednim zakresem uprawnień. Oznacza to, iż bezpieczeństwo łańcucha dostaw zależy dziś nie tylko od jakości kodu, ale również od kontroli dostępu, integralności referencji i praktyk operacyjnych wokół automatyzacji.

Rekomendacje

Organizacje korzystające z Trivy oraz innych akcji GitHub powinny potraktować ten incydent jako impuls do przeglądu zabezpieczeń CI/CD. W praktyce warto wdrożyć następujące działania:

Pinowanie akcji do pełnych hashy commitów zamiast odwołań do tagów wersji.
Natychmiastową rotację sekretów, jeżeli istnieje choćby cień podejrzenia uruchomienia skompromitowanej akcji.
Przegląd logów workflow i artefaktów pod kątem nietypowych połączeń wychodzących, nowych repozytoriów i użycia tokenów.
Ograniczenie uprawnień tokenów oraz runnerów zgodnie z zasadą najmniejszych uprawnień.
Monitorowanie operacji na tagach i repozytoriach, w tym force-pushy i nietypowych zmian referencji.
Kontrolę integralności zależności pipeline’u poprzez listy zatwierdzonych SHA i regularne audyty konfiguracji.
Pełne działania containment po incydencie, wykonywane w sposób skoordynowany i kompleksowy.

Z perspektywy bezpieczeństwa najważniejsza lekcja jest prosta: tag wersji nie powinien być traktowany jako gwarancja niezmienności. W krytycznych workflow jedynym rozsądnym podejściem jest przypinanie zależności do konkretnych commitów i cykliczna weryfikacja ich integralności.

Podsumowanie

Naruszenie Trivy GitHub Actions to kolejny przykład dojrzałego ataku na łańcuch dostaw oprogramowania, w którym kluczową rolę odegrało przejęcie poświadczeń oraz podmiana zaufanych referencji. Incydent pokazuje, iż choćby narzędzia bezpieczeństwa mogą stać się skutecznym wektorem kompromitacji, jeżeli są osadzone w wysoko uprzywilejowanych pipeline’ach.

Dla zespołów bezpieczeństwa i DevSecOps oznacza to konieczność zmiany podejścia do zaufania w CI/CD. Ochrona musi obejmować nie tylko kod aplikacji, ale również akcje, skrypty bootstrapujące, system zarządzania sekretami, integralność tagów oraz bieżące monitorowanie zachowań runnerów.