Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo łańcucha dostaw oprogramowania w coraz większym stopniu zależy nie tylko od jakości samego kodu, ale również od sposobu projektowania i konfiguracji pipeline’ów CI/CD. Badacze bezpieczeństwa opisali nową klasę błędów nazwaną Cordyceps, która dotyczy workflow opartych o GitHub i wynika z nieprawidłowego przekraczania granic zaufania pomiędzy niezaufanym wejściem a uprzywilejowanymi zadaniami.
W praktyce problem pojawia się wtedy, gdy dane pochodzące od zewnętrznych użytkowników, takie jak pull requesty, komentarze, nazwy gałęzi czy metadane workflow, wpływają na zadania uruchamiane z szerokimi uprawnieniami. Taki układ może otworzyć drogę do zdalnego wykonania kodu, przejęcia tokenów i kompromitacji procesu budowania oraz publikacji oprogramowania.
W skrócie
Cordyceps to wzorzec podatności w CI/CD, w którym niezaufane dane trafiają do workflow wykonujących operacje z wysokim poziomem zaufania. W analizie około 30 tysięcy istotnych repozytoriów zidentyfikowano ponad 300 przypadków pełnej podatności na nadużycia.
- Problem dotyczy błędnej kompozycji workflow, a nie pojedynczej luki produktowej.
- Atak może prowadzić do wykonania kodu w runnerze CI.
- Możliwe skutki obejmują wyciek sekretów, przejęcie tokenów automatyzacji i modyfikację procesu release.
- Zagrożenie ma bezpośredni wpływ na bezpieczeństwo software supply chain.
Kontekst / historia
Ekosystem open source od lat próbuje równoważyć otwartą współpracę z restrykcyjnym modelem zaufania. Mechanizmy takie jak pull requesty, forki, automatyczne testy, zatwierdzanie zmian i publikacja artefaktów przyspieszają rozwój, ale jednocześnie zwiększają powierzchnię ataku.
W przypadku Cordyceps nie chodzi o pojedynczy błąd w jednej funkcji platformy, lecz o problem architektoniczny. Każdy element pipeline’u może działać zgodnie z dokumentacją, jednak połączenie wielu poprawnych mechanizmów w nieodpowiedni sposób tworzy podatny układ. To właśnie dlatego tego typu słabości bywają trudne do wykrycia klasycznymi narzędziami skanującymi.
Szczególnie niebezpieczne są scenariusze, w których workflow reaguje na zdarzenia generowane przez użytkowników zewnętrznych, a następnie wykonuje operacje z uprawnieniami zapisu, dostępem do sekretów lub możliwością uruchamiania kolejnych uprzywilejowanych akcji. W takich przypadkach granica zaufania zostaje zatarta.
Analiza techniczna
Techniczny rdzeń problemu sprowadza się do sytuacji, w której dane z niezaufanego źródła są używane bez odpowiedniej walidacji i izolacji w kontekście mającym dostęp do wrażliwych zasobów. Jeżeli nazwa gałęzi, treść komentarza, tytuł pull requestu lub inny parametr wejściowy trafia bezpośrednio do komendy shell, skryptu lub kroku workflow o podwyższonych uprawnieniach, atakujący może uzyskać możliwość wykonania własnego kodu.
Badacze wskazują, że skuteczne wykorzystanie tej klasy błędów nie musi wymagać członkostwa w organizacji ani specjalnych przywilejów. W niektórych scenariuszach wystarcza publiczne konto i możliwość utworzenia pull requestu z forka lub zamieszczenia komentarza aktywującego określony etap automatyzacji.
W konsekwencji podatny workflow może dopuścić do eskalacji uprawnień z kontekstu publicznego do uprzywilejowanego. Otwiera to drogę do odczytu i eksfiltracji sekretów, użycia tokenów z prawem zapisu do repozytorium, przejęcia procesu zatwierdzania zmian, a nawet manipulacji etapem budowania i publikacji pakietów.
- wstrzyknięcie poleceń do kroków CI,
- eskalacja uprawnień z niezaufanego kontekstu,
- kradzież sekretów i tokenów automatyzacji,
- modyfikacja workflow lub kodu źródłowego,
- przejęcie procesu wydawniczego i dystrybucji artefaktów.
Z perspektywy bezpieczeństwa jest to klasyczny przykład naruszenia granicy zaufania. Workflow traktuje dane pochodzące od użytkownika zewnętrznego tak, jakby były bezpieczne, a następnie łączy je z kontekstem dysponującym sekretami, prawami zapisu lub możliwością wykonania dalszych działań administracyjnych.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem błędów klasy Cordyceps jest kompromitacja łańcucha dostaw oprogramowania. Jeżeli napastnik przejmie kontrolę nad pipeline’em budowania lub wydania, może doprowadzić do wstrzyknięcia złośliwego kodu do oficjalnych artefaktów, pakietów lub obrazów kontenerowych.
Skala ryzyka wykracza daleko poza samo repozytorium. Złośliwe modyfikacje mogą zostać dostarczone użytkownikom końcowym, partnerom biznesowym i innym projektom zależnym od zaatakowanego komponentu. To właśnie dlatego incydenty związane z CI/CD są dziś traktowane jako jedne z najpoważniejszych zagrożeń dla integralności ekosystemu open source.
- wyciek tokenów GitHub, kluczy API i poświadczeń chmurowych,
- nieautoryzowane zatwierdzanie pull requestów,
- modyfikacja kodu źródłowego i plików workflow,
- utrata integralności procesu release management,
- osadzenie trwałego backdoora w procesie deweloperskim,
- skutki reputacyjne i zgodnościowe dla organizacji.
Szczególnie zagrożone są duże projekty open source oraz organizacje, które szeroko dopuszczają wkład zewnętrzny i jednocześnie utrzymują rozbudowaną automatyzację opartą na GitHub Actions. Im bardziej złożony pipeline i im więcej zdarzeń pochodzących z PR wpływa na etapy uprzywilejowane, tym wyższe prawdopodobieństwo błędnej kompozycji uprawnień.
Rekomendacje
Organizacje korzystające z GitHub Actions powinny potraktować Cordyceps jako sygnał do pilnego przeglądu architektury zaufania w swoich workflow. Kluczowe znaczenie ma rozdzielenie zadań obsługujących niezaufane wejście od etapów mających dostęp do sekretów, publikacji i operacji administracyjnych.
- rozdzielać workflow dla niezaufanych pull requestów od workflow uprzywilejowanych,
- nie udostępniać sekretów zadaniom uruchamianym przez użytkowników zewnętrznych,
- ograniczać uprawnienia tokenów zgodnie z zasadą najmniejszych uprawnień,
- traktować nazwy gałęzi, komentarze i metadane PR jako dane niezaufane,
- unikać bezpośredniego użycia niezaufanego inputu w poleceniach shell i skryptach,
- stosować walidację, listy dozwolonych wartości oraz bezpieczne quotingowanie parametrów,
- separować testy od etapów publikacji, podpisywania i automatycznego mergowania,
- regularnie audytować workflow pod kątem eventów wysokiego ryzyka,
- rotować tokeny i sekrety przy podejrzeniu ich ekspozycji,
- włączyć monitoring zmian w plikach workflow i analizę nietypowych uruchomień CI.
Warto również przeanalizować poboczne mechanizmy, takie jak ręczne reruny zadań, automatyczne approvale czy workflow aktywowane komentarzem. To właśnie one często stają się najsłabszym ogniwem w procesie, pozwalając przejść z kontekstu niezaufanego do bardziej uprzywilejowanego.
Podsumowanie
Cordyceps pokazuje, że bezpieczeństwo CI/CD nie kończy się na poprawnym działaniu pojedynczych komponentów. Kluczowe jest to, w jaki sposób organizacja łączy zdarzenia pochodzące od niezaufanych użytkowników z workflow posiadającymi szerokie uprawnienia i dostęp do wrażliwych zasobów.
Fakt, że ponad 300 repozytoriów spośród około 30 tysięcy przeanalizowanych projektów zostało uznanych za w pełni podatne, wskazuje na realną i szeroką skalę zagrożenia. Dla zespołów DevSecOps oraz administratorów repozytoriów to wyraźny sygnał, że audyt workflow CI/CD powinien stać się jednym z priorytetów ochrony software supply chain.