Luka w GitHub Actions w repozytorium Snowflake umożliwiała command injection przez spreparowane zgłoszenia

Wprowadzenie do problemu / definicja

Ujawniona podatność w GitHub Actions pokazała, jak groźne może być bezpośrednie używanie danych kontrolowanych przez użytkownika w krokach wykonywanych przez powłokę. W tym przypadku problem nie dotyczył samej platformy Snowflake ani wydania konektora .NET, lecz workflow odpowiedzialnego za obsługę zgłoszeń i integrację z Jira w publicznym repozytorium.

Atak polegał na wykorzystaniu pól tekstowych publicznego zgłoszenia typu issue. Jeśli tytuł lub treść zgłoszenia trafiają bez odpowiedniego zabezpieczenia do bloku run:, mogą zostać zinterpretowane jako fragment polecenia systemowego, co prowadzi do command injection w pipeline CI/CD.

W skrócie

Podatność wykryto w workflow GitHub Actions powiązanym z repozytorium Snowflake Connector for .NET.
Spreparowane publiczne issue mogło doprowadzić do wstrzyknięcia poleceń do kroku run:.
W tym samym kontekście dostępne były sekrety integracji z Jira, w tym token API.
Według opisu incydentu poprawkę wdrożono tego samego dnia, a ujawniony sekret został następnie zrotowany.
Brak publicznych informacji wskazujących na nadużycie luki poza autoryzowanym testem badawczym.

Kontekst / historia

Podatności typu workflow injection w GitHub Actions nie są nowym zjawiskiem. Szczególnie niebezpieczne są scenariusze, w których automatyzacja reaguje na publiczne zdarzenia, takie jak otwarcie issue, komentarz lub pull request. W takich przypadkach dane wejściowe pochodzą bezpośrednio od użytkownika zewnętrznego i muszą być traktowane jako niezaufane.

W analizowanym incydencie problem dotyczył automatyzacji obsługującej zgłoszenia i komunikację z Jira. Podatny kod trafił do domyślnej gałęzi na krótko przed odkryciem błędu, co oznaczało ograniczone, ale realne okno ekspozycji. Sprawa zwróciła też uwagę na szerszy problem: workflow pomocnicze często nie są audytowane z taką samą dokładnością jak kod aplikacyjny, mimo że mają dostęp do cennych sekretów i zasobów organizacji.

Analiza techniczna

Źródłem podatności było bezpośrednie wstawianie wartości pochodzących z github.event.issue.title oraz github.event.issue.body do polecenia uruchamianego przez shell. W praktyce oznacza to, że atakujący mógł przygotować zgłoszenie w taki sposób, aby zmienić semantykę wykonywanej komendy i wymusić wykonanie dodatkowych instrukcji na runnerze.

Dodatkowym problemem była logika warunkowa odnosząca się do właściwości github.event.pull_request.user.login, mimo że sam workflow był uruchamiany dla zdarzenia typu issue. Tego rodzaju niespójność mogła spowodować, że zabezpieczenie nie działało zgodnie z intencją autora, a publiczne zgłoszenie przechodziło dalej do podatnego kroku.

Najpoważniejszy aspekt ryzyka wynikał z obecności sekretów związanych z Jira w tym samym jobie. Jeżeli command injection zakończy się powodzeniem w kontekście procesu mającego dostęp do danych uwierzytelniających, napastnik może nie tylko wykonać dowolne polecenia, ale również odczytać i wyeksportować tokeny, adresy usług oraz inne poufne informacje.

Bezpieczniejszy model projektowania workflow polega na unikaniu bezpośredniej interpolacji niezaufanych danych do komend powłoki. Zamiast tego należy przekazywać takie wartości przez zmienne środowiskowe lub kontrolowane argumenty, z zachowaniem właściwego quoting i escaping oraz z minimalizacją kontaktu z interpreterem poleceń.

Konsekwencje / ryzyko

Choć nie wskazano wpływu na samo wydanie konektora .NET, potencjalne skutki podatności były istotne z perspektywy bezpieczeństwa łańcucha dostaw oprogramowania. Kompromitacja nawet pojedynczego kroku workflow może otworzyć drogę do dalszych działań w środowisku organizacji.

kradzież sekretów CI/CD i tokenów integracyjnych,
nieautoryzowany dostęp do systemów zewnętrznych, takich jak Jira,
modyfikacja procesów developerskich i artefaktów pomocniczych,
wykorzystanie runnera do dalszego ruchu w łańcuchu dostaw,
pozyskanie informacji o wewnętrznych projektach, zgłoszeniach i procedurach.

Ryzyko jest szczególnie wysokie w publicznych repozytoriach open source, gdzie wywołanie określonych zdarzeń automatyzacji nie wymaga uprzedniego zaufania. Nawet gdy runner jest efemeryczny, wyciek sekretów może prowadzić do długotrwałych konsekwencji operacyjnych i reputacyjnych.

Rekomendacje

Organizacje korzystające z GitHub Actions powinny traktować workflow jako pełnoprawny element powierzchni ataku i wdrożyć zestaw podstawowych zabezpieczeń procesowych oraz technicznych.

Nie umieszczać bezpośrednio danych z issue, komentarzy i pull requestów w blokach run:.
Przekazywać niezaufane dane przez zmienne środowiskowe lub bezpiecznie obsługiwane argumenty.
Oddzielać workflow publiczne od jobów mających dostęp do sekretów.
Stosować zasadę najmniejszych uprawnień dla tokenów, kont technicznych i integracji.
Ograniczać dostęp do sekretów wyłącznie do kroków, które rzeczywiście ich wymagają.
Regularnie audytować logikę warunkową i wzorce podatne na injection.
Weryfikować zmiany w CI/CD z taką samą starannością jak kod aplikacyjny.
Monitorować logi workflow i nietypowe połączenia wychodzące z runnerów.
Rotować sekrety po każdym podejrzeniu ekspozycji.
Włączać testy bezpieczeństwa pipeline’ów do standardowego procesu przeglądu kodu.

Podsumowanie

Opisana luka jest kolejnym przypomnieniem, że bezpieczeństwo łańcucha dostaw nie kończy się na kodzie aplikacji. Publiczne workflow CI/CD mogą stać się wygodnym punktem wejścia do systemów wewnętrznych, jeśli przetwarzają dane użytkownika bez odpowiednich zabezpieczeń i jednocześnie operują na sekretach.

W tym przypadku kluczowe znaczenie miało połączenie dwóch błędów: niebezpiecznej interpolacji danych do komend powłoki oraz obecności danych uwierzytelniających w tym samym kroku automatyzacji. Szybka reakcja ograniczyła ekspozycję, ale incydent wyraźnie pokazuje, że GitHub Actions wymaga takiej samej dyscypliny bezpieczeństwa jak każda inna część infrastruktury produkcyjnej.