Skaner Trivy Security w GitHub Actions włamany, 75 tagów przejętych do kradzieży sekretów CI/CD

Ekosystem open-source stoi przed poważnym zagrożeniem, a ostatni atak na Trivy — popularny skaner podatności utrzymywany przez Aqua Security — stanowi kolejny dowód na to, jak kruche są fundamenty naszej infrastruktury DevOps. W ciągu zaledwie miesiąca Trivy padł ofiarą dwóch incydentów bezpieczeństwa, a najnowszy z nich dotyczył kompromitacji 75 tagów na GitHub, które wykorzystano do kradzieży wrażliwych sekretów CI/CD z tysięcy zespołów deweloperskich na całym świecie. To nie jest zwykłe włamanie — to precyzyjnie zaplanowany atak na serce nowoczesnego procesu wdrażania oprogramowania.

Załamanie zaufania do narzędzia, które miało chronić infrastrukturę, odsłania fundamentalne słabości w sposobie, w jaki traktujemy bezpieczeństwo łańcucha dostaw oprogramowania. Gdy zespoły DevOps integrują akcje GitHub do swoich przepływów pracy, oczekują, że będą one bezpieczne i godne zaufania. Incydent z Trivy pokazuje, że takie założenie może być niebezpiecznie naiwne. W momencie, gdy atakujący uzyskali dostęp do oficjalnych repozytorium, mogli modyfikować kod, który wykonywany był z prawami dostępu do najbardziej wrażliwych zasobów — tokenów dostępu, kluczy API i poświadczeń do rejestrów kontenerów.

Anatomia ataku: jak 75 tagów stało się bronią

Atak na Trivy nie był przypadkowy ani nieudolny. Atakujący, którzy uzyskali dostęp do repozytorium, systematycznie zainfekowali 75 różnych tagów wersji akcji GitHub — zarówno dla "aquasecurity/trivy-action" jak i "aquasecurity/setup-trivy". To oznacza, że nie chodziło o jednorazową zarazę, którą można łatwo zidentyfikować i wyeliminować. Zamiast tego, atakujący stworzyli szeroki wachlarz zainfekowanych wersji, co utrudniało wykrycie i pozwalało na zainfekowanie maksymalnie możliwej liczby zespołów.

Każdy tag reprezentuje konkretną wersję akcji, którą deweloperzy mogą wybrać w swoich workflow. Niektóre zespoły mogą być ustawione na pobieranie najnowszej wersji automatycznie, podczas gdy inne mogą być "zablokowane" na starszych wersjach. Infekując szeroki zakres tagów — od starszych do najnowszych — atakujący zapewnili sobie maksymalny zasięg. Było to podobne do podania trucizny do systemu wodociągowego na wielu poziomach jednocześnie, aby mieć pewność, że ludzie pijący wodę z różnych kranów będą zainfektowani.

Złośliwy kod osadzony w tych tagach miał konkretny cel: kradzież sekretów przechowywanych w zmiennych środowiskowych GitHub Actions. Gdy akcja Trivy była uruchamiana w przepływie pracy CI/CD, kod wykonywał się z dostępem do wszystkich zmiennych dostępnych dla danego workflow — w tym tokenów GitHub, kluczy AWS, poświadczeń Docker Hub i wielu innych wrażliwych danych. Te sekrety są zwykle przechowywane w ustawieniach repozytorium, ale GitHub Actions automatycznie przekazuje je do zmiennych środowiskowych, aby narzędzia mogły się nimi posługiwać.

Drugi atak w miesiąc: wzór czy przypadek?

Fakt, że Trivy padł ofiarą ataku po raz drugi w ciągu zaledwie 30 dni, nie jest przypadkiem. Sugeruje to jedno z dwóch scenariuszy: albo Aqua Security ma poważne problemy z zarządzaniem dostępem i bezpieczeństwem repozytorium, albo atakujący, którzy przeprowadzili pierwszy atak, pozostawili sobie "tylne drzwi" do powrotu. W branży bezpieczeństwa znane jest zjawisko zwane "persistence" — kiedy atakujący uzyskują dostęp, często instalują dodatkowe mechanizmy umożliwiające im powrót nawet po odkryciu i usunięciu pierwotnego wektora ataku.

Powtarzające się incydenty sugerują również, że pierwszy atak mógł nie być w pełni zbadany. Możliwe, że zespół Aqua Security skupił się na naprawie widocznych szkód, nie usuwając wszystkich ścieżek dostępu, które wykorzystali atakujący. To klasyczny błąd w reagowaniu na incydenty — zespoły często działają pod presją czasu i skupiają się na przywróceniu normalnego działania, zamiast przeprowadzić gruntowną kryminalistykę cybernetyczną.

Seria ataków na popularną i zaufaną aplikację również sugeruje, że atakujący mogą być dobrze skoordynowani i dysponować znacznymi zasobami. Nie jest to praca samotnego hakera działającego z zapamiętania. To wygląda bardziej na pracę zespołu mającego dostęp do zaawansowanych narzędzi i wyspecjalizowanej wiedzy na temat ekosystemu GitHub i infrastruktury CI/CD.

Łańcuch dostaw jako pole bitwy

Ataki na narzędzia open-source takie jak Trivy reprezentują ewolucję zagrożeń bezpieczeństwa. Zamiast atakować bezpośrednio aplikacje końcowych użytkowników, atakujący kierują się na narzędzia i biblioteki, które są używane przez tysiące lub miliony projektów. Jest to bardziej efektywne, ponieważ jeden atak może zainfekować setki tysięcy systemów naraz. To jest atak na łańcuch dostaw oprogramowania — gra w wyższej lidze.

Aqua Security nie jest zwykłym projektem hobbyistycznym. To komercyjna firma zajmująca się bezpieczeństwem kontenerów, a Trivy jest jednym z jej flagowych produktów. Fakt, że została zaatakowana, pokazuje, że żaden rozmiar firmy ani poziom doświadczenia nie gwarantuje ochrony przed zdeterminowanym atakującym. Nawet firmy, które specjalizują się w bezpieczeństwie, mogą mieć luki w swoich własnych systemach bezpieczeństwa.

Co szczególnie niepokojące, GitHub Actions są używane przez większość nowoczesnych zespołów DevOps do automatyzacji procesów CI/CD. Jeśli atakujący mogą zainfekować popularne akcje, mogą skutecznie umieścić się w sercu infrastruktury tysiąca organizacji. To jest jak zainfekcja systemu sterowania ruchem drogowym — jedna luka może wpłynąć na miliony ludzi.

Sekrety CI/CD: najcenniejszy skarb atakującego

Sekrety przechowywane w GitHub Actions — tokeny, klucze API, poświadczenia — to nie zwykłe dane. To klucze do królestwa cyfrowego każdej organizacji. Gdy atakujący uzyskają dostęp do tokenu GitHub z uprawnieniami do repozytorium, mogą modyfikować kod, tworzyć nowe gałęzie, a nawet bezpośrednio wdrażać zmiany do produkcji. Klucze AWS dają dostęp do całej infrastruktury chmurowej. Poświadczenia Docker Hub pozwalają na zainfekowanie obrazów kontenerów, które są wdrażane na całej infrastrukturze.

Te sekrety są zwykle bardzo dobrze chronione — przechowywane w szyfrowanych magazynach, dostępne tylko dla autoryzowanych procesów. Jednak GitHub Actions automatycznie przekazuje je do zmiennych środowiskowych, aby narzędzia mogły się nimi posługiwać. To jest konieczne dla funkcjonalności, ale stanowi również punkt słabości. Jeśli kod wykonywany w ramach akcji jest złośliwy, może łatwo wyświetlić te zmienne i wysłać je do serwera atakującego.

Atakujący mogą następnie wykorzystać te sekrety do:

• Bezpośredniego dostępu do repozytorium i modyfikacji kodu produkcyjnego
• Zainfekowania obrazów Docker przechowywanych w rejestrach
• Przejęcia infrastruktury chmurowej i wdrażania backdoorów
• Kradzieży danych wrażliwych przechowywanych w bazach danych
• Tworzenia długotrwałych mechanizmów dostępu do systemów organizacji

Wpływ na ekosystem: ile zespołów zostało zagrożonych?

Trivy jest jednym z najpopularniejszych skanerów podatności w ekosystemie kontenerów. Aqua Security raportuje, że akcje Trivy są pobierane miliony razy miesięcznie. Nawet jeśli tylko mały procent tych pobierań dotyczył zainfekowanych tagów, liczba zagrożonych systemów jest ogromna. Mówimy o potencjalnie dziesiątkach tysięcy organizacji, od startupów po Fortune 500 firmy.

Szczególnie zagrożone są duże organizacje, które mają złożone przepływy pracy CI/CD i przechowują w GitHub Actions wiele wrażliwych sekretów. Te organizacje są również bardziej atrakcyjnymi celami dla atakujących, ponieważ potencjalne korzyści z dostępu do ich systemów są znacznie większe. Startup z kilkoma pracownikami może stracić dostęp do swoich kodów źródłowych, ale Fortune 500 firma może stracić dostęp do całej infrastruktury wartej miliardy dolarów.

Trzeba również wziąć pod uwagę efekt domina. Jeśli atakujący uzyskają dostęp do repozytorium organizacji A, mogą zainfekować kod, który ta organizacja wykorzystuje w swoich produktach. Te produkty mogą być następnie używane przez organizację B, która znowu wykorzystuje je w swoich produktach. W ten sposób jeden atak może rozprzestrzeniać się przez wiele warstw łańcucha dostaw.

Lekcje z poprzedniego incydentu, które nie zostały wdrożone

Pierwszy atak na Trivy w ciągu miesiąca powinien był być sygnałem ostrzegawczym dla Aqua Security. Każdy incydent bezpieczeństwa wymaga gruntownego śledztwa, aby zidentyfikować pierwotną przyczynę i wszystkie możliwe wektory ataku. Jednak fakt, że drugi atak miał miejsce tak szybko, sugeruje, że albo pierwsze śledztwo nie było wystarczająco gruntowne, albo jego wyniki nie zostały w pełni wdrożone.

W dobrze zarządzanym procesie reagowania na incydenty, po pierwszym ataku Aqua Security powinna była:

• Przeprowadzić pełną audyt dostępu do repozytorium i zidentyfikować wszystkie konta z uprawnieniami do modyfikacji kodu
• Zmienić wszystkie hasła i tokeny dostępu
• Wdrożyć dodatkowe warstwy autentykacji dla operacji krytycznych
• Zainstalować narzędzia do monitorowania podejrzanej aktywności w repozytorium
• Przeprowadzić pełną kryminalistykę cybernetyczną, aby zidentyfikować wszystkie ścieżki dostępu wykorzystane przez atakujących

Brak wdrożenia tych środków sugeruje, że Aqua Security albo nie miała wystarczających zasobów, albo nie traktowała pierwszego ataku z wystarczającą powagą. To jest błąd, który będzie kosztować firmę znacznie więcej niż inwestycja w odpowiednie zabezpieczenia.

Przesunięcie odpowiedzialności: kto powinien być odpowiedzialny?

Incydent z Trivy otwiera ważne pytanie o odpowiedzialność w ekosystemie open-source. Trivy jest darmowym, open-source projektem, ale jest również utrzymywany przez komercyjną firmę — Aqua Security. Czy Aqua Security ma taką samą odpowiedzialność za bezpieczeństwo Trivy jak tradycyjny dostawca oprogramowania? Czy deweloperzy korzystający z Trivy powinni byli mieć wyższe oczekiwania dotyczące bezpieczeństwa?

W rzeczywistości, odpowiedzialność jest rozproszona. Aqua Security ma odpowiedzialność za bezpieczeństwo repozytorium i procesów wdrażania. Deweloperzy korzystający z Trivy mają odpowiedzialność za weryfikację integralności pobieranego kodu i monitorowanie zmian w używanych zależnościach. GitHub ma odpowiedzialność za zapewnienie bezpiecznej platformy do hostowania repozytorium. Wszyscy ci gracze mają rolę do odegrania.

Jednak w praktyce, większość deweloperów ufa, że narzędzia pobierane z oficjalnych źródeł są bezpieczne. Ta zaufanie jest w dużej mierze uzasadnione, ale incydenty takie jak Trivy pokazują, że zaufanie samo nie wystarczy. Konieczne są dodatkowe warstwy weryfikacji i monitorowania.

Jak organizacje powinny reagować teraz

Dla organizacji, które używały zainfekowanych tagów Trivy, czas działania jest kluczowy. Pierwszym krokiem powinno być zidentyfikowanie, które wersje Trivy były używane i czy któreś z nich były zainfekowane. Aqua Security opublikowała listę zainfekowanych tagów, więc to jest stosunkowo proste do sprawdzenia.

Następnie, organizacje powinny założyć, że wszystkie sekrety przechowywane w GitHub Actions w tym samym repozytorium mogły zostać skompromitowane. Oznacza to, że wszystkie tokeny, klucze API i poświadczenia powinny być natychmiast zmienione. To jest drażliwy proces, szczególnie w dużych organizacjach, ale jest absolutnie konieczny.

Długoterminowo, organizacje powinny również rozważyć wdrożenie bardziej zaawansowanych praktyk bezpieczeństwa dla swoich przepływów CI/CD:

• Używanie Zero Trust Network Access (ZTNA) do ograniczenia dostępu do wrażliwych zasobów tylko do zaufanych procesów
• Implementacja Code signing dla wszystkich akcji GitHub, aby zapewnić, że kod pochodzi z zaufanego źródła
• Regularne audyty dostępu i zmian w repozytorium
• Monitorowanie anomalii w przepływach CI/CD, takich jak nieoczekiwane połączenia sieciowe lub dostęp do sekretów
• Rotacja sekretów w regularnych odstępach czasu, niezależnie od tego, czy podejrzewamy kompromitację

Incydent z Trivy jest przypomnieniem, że bezpieczeństwo CI/CD nie może być traktowane jako dodatek czy drugoplanowy problem. To musi być integralną częścią każdego procesu wdrażania oprogramowania, z takim samym poziomem inwestycji i uwagi jak bezpieczeństwo samej aplikacji.