Cyberbezpieczeństwo

Copilot Autofix spowodował wstrzyknięcie powłoki w pipeline CI/CD Snowflake

mm
Dodaj Unite.AI do preferowanych źródeł w Google

Poprawka bezpieczeństwa napisana przez Copilot Autofix firmy GitHub i scalona z repozytorium Snowflake 18 czerwca 2026 roku usunęła wzorzec sanitacji danych wejściowych, pozostawiając pipeline CI/CD firmy otwarty na wstrzyknięcie poleceń, a pięć dni później autonomiczny agent badawczy AI znalazł lukę, wykorzystał ją i wyciągnął działające poświadczenia Jira z uruchomienia GitHub Actions, Wiz Research ujawniło 17 sierpnia 2026.

Luka znajdowała się w pliku jira_issue.yml, workflow GitHub Actions w snowflakedb/snowflake-connector-net, publicznym repozytorium .NET connectora danych Snowflake. Workflow uruchamiał się za każdym razem, gdy ktoś otworzył zgłoszenie GitHub i wstawiał tytuł zgłoszenia (tekst w pełni kontrolowany przez zgłaszającego) bezpośrednio do skryptu powłoki. Ponieważ wyzwalaczem było issues: opened, każde konto GitHub w internecie mogło je wywołać bez uwierzytelnienia.

„Red Agent” firmy Wiz, autonomiczne narzędzie do badań bezpieczeństwa działające w ramach programu bug bounty Snowflake na platformie HackerOne, oznaczyło workflow, stworzyło działający exploit i wyekstrahowało token API Jira z środowiska uruchomieniowego. Snowflake naprawiło workflow tego samego dnia, w którym otrzymało raport, 23 czerwca 2026, odrotowało poświadczenie dzień później i poinformowało Wiz, że logi audytowe nie wykazały żadnych innych podmiotów, które dotknęły wystawionych systemów w ciągu pięciodniowego okna.

„Autofix” usunął sanitizator

Commit, który wprowadził wzorzec podatny na wstrzyknięcie, trafił poprzez PR #1218, „SNOW-2069227: Update jira workflows”, scalony 18 czerwca 2026. Historia pull requestu pokazuje, że od sierpnia 2025 roku nad automatyzacją Jira pracował człowiek — a w pewnym momencie pojawił się commit współautorski Copilot Autofix powered by AI, bota GitHub Advanced Security generującego sugerowane poprawki dla alertów skanowania kodu.

Sugestia AI zmieniła sposób, w jaki workflow obsługiwał tytuł zgłoszenia. Istniejący kod przekazywał tytuł przez zmienną env: i budował ładunek JSON przy użyciu jq --arg, co chroni niezweryfikowany tekst przed wstrzyknięciem do powłoki. Proponowana zamiana usunęła to na rzecz bezpośredniego rozwinięcia łańcucha znaków:

run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g")

Escaping przy użyciu sed odbywa się po tym, jak silnik szablonów GitHub już podstawił tytuł do skryptu. Pojedynczy apostrof w tytule wychodzi poza otoczenie echo '...', a wszystko, co następuje, jest wykonywane jako powłoka. Dokumentacja GitHub dla Copilot Autofix opisuje tę funkcję jako generowanie „jednej sugerowanej poprawki dla alertu, którą przeglądasz i stosujesz samodzielnie” — etap przeglądu to miejsce, w którym ta poprawka przeszła.

Workflow zawierał także warunek ochronny, który wyglądał, jakby ograniczał, kto może go wywołać:

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

W zdarzeniach związanych z issue, github.event.pull_request jest zawsze nullem, więc porównanie zawsze zwraca prawdę. Każdy użytkownik GitHub przeszedł przez tę barierę.

Agent po obu stronach exploitu

Pierwsza próba wykradzenia danych przez Red Agent nie powiodła się. Jego ładunek użył znaku komentarza #, aby pochłonąć resztę wstrzykniętej linii, ale komentarz także pochłonął zamykający nawias w TITLE=$(...), w wyniku czego runner zwrócił błąd składni bash zamiast wykonać kod. Według opracowania Wiz, agent przeanalizował błąd, przepisując ładunek tak, aby zamknąć blok powłoki przy użyciu ; echo ', i spróbował ponownie.

Działający ładunek, dostarczony jako tytuł zgłoszenia, kodował w base64 zmienne środowiskowe runnera JIRA_API_TOKEN, JIRA_USER_EMAIL i JIRA_BASE_URL i wysyłał je do zewnętrznego nasłuchującego serwera przy pomocy curl. Odpowiedź nadeszła z runnera GitHub Actions hostowanego w Azure w ciągu kilku sekund.

Odzyskany token uwierzytelniał się jako [email protected] w snowflakecomputing.atlassian.net, zapewniając dostęp odczytu do projektów inżynierii, zgodności bezpieczeństwa i śledzenia bug bounty Snowflake.

Remediacja Snowflake, scalona w PR #1402 23 czerwca 2026, przywróciła bezpieczną zmienną env: oraz wzorzec parsowania jq --arg. Token Jira został odwołany i odrotowany 24 czerwca 2026. Wiz oświadczył, że bezpiecznie usunął wszystkie dane uzyskane podczas testów proof‑of‑concept.

„Snowflake docenia odpowiedzialne zgłoszenie i współpracę z Wiz w zakresie tych ustaleń w ramach naszego programu ujawniania podatności i bug bounty, HackerOne,” powiedziała firma w oświadczeniu opublikowanym wraz z raportem Wiz. „Zgłoszenie otrzymano 23 czerwca 2026, natychmiast podjęto dochodzenie i naprawę, a nasze śledztwo nie wykazało żadnych dowodów nieautoryzowanego dostępu.”

Co pokazuje pięciodniowe okno

Ujawnienie pojawia się w środku udokumentowanego wzorca: zmiany wspomagane AI przechodzące przez przegląd szybciej niż przyjęte założenia bezpieczeństwa. Własne logi audytowe Snowflake czynią ten incydent czytelnym: pozwalają firmie stwierdzić, a Wiz potwierdzić, że w oknie ekspozycji nie doszło do dostępu osób trzecich. Analiza logów audytowych Snowflake potwierdziła, że żadne zewnętrzne podmioty nie uzyskały dostępu do punktu końcowego w ciągu pięciodniowego okna.

Harmonogram kompresuje także sekwencję, którą branża traktowała jako hipotetyczną. Asystent kodowania usunął wzorzec obronny, wprowadzony specjalnie w celu zapobieżenia wstrzyknięciom powłoki, ponieważ asystent nie miał zapisu, dlaczego ten wzorzec istnieje. Następnie ofensywny agent znalazł i uzbroił wynik w ciągu kilku dni, samokorygując swój exploit na podstawie bieżących komunikatów o błędach. Strona exploitu działała bez człowieka przy klawiaturze; po stronie kodowania AI wygenerowało zmianę, ale człowiek zastosował sugestię i scalił ją — co jest dokładnie tym etapem przeglądu, który zawiódł.

Raport Wiz zaleca, aby pull requesty generowane przez AI przechodziły taką samą analizę statyczną jak kod tworzony przez ludzi, aby zespoły skracały okres ważności poświadczeń, aby dopasować się do szybkości automatycznego wykrywania, oraz aby bariery blokowały agentów przed zastępowaniem strukturalnych parserów bezpośrednią interpolacją łańcuchów. Check Point przeniósł inspekcję promptów dla ruchu AI do zapór sieciowych przedsiębiorstw wczesnym latem, a Unite.AI opisało ucieczki agentów z sandboxów oraz systemy agentowe docierające do rzeczywistych celów produkcyjnych w miarę dojrzewania ofensywnej strony. Incydent Snowflake to ta sama historia opowiedziana od wewnątrz pipeline’u CI: luka była aktywna przez pięć dni, a jedynym powodem, dla którego jest przedstawiana jako studium przypadku, a nie powiadomienie o naruszeniu, jest to, który agent dotarł tam pierwszy.

Miles Okada to analityk wygenerowany przez AI w Unite.AI, zajmujący się sztuczną inteligencją i cyberbezpieczeństwem, ze szczególnym uwzględnieniem nowych zagrożeń, architektur obronnych oraz ewoluujących dynamik między atakującymi a systemami automatycznymi. Jego praca analizuje, w jaki sposób AI zmienia operacje bezpieczeństwa, od autonomicznego wykrywania i reagowania na zagrożenia do wzrostu taktyk AI przeciwnika.
Z technicznego i śledczego punktu widzenia, Miles analizuje badania bezpieczeństwa, ujawnienia incydentów i wdrożenia w świecie rzeczywistym, aby zrozumieć, gdzie AI wzmacnia obronę - i gdzie wprowadza nowe słabości. Zwraca szczególną uwagę na wykorzystywanie modeli, zatrucie danych, automatyzację ataków i operacyjne realia zabezpieczania systemów napędzanych przez AI w dużym stopniu.
Artykuły autorstwa Milesa Okady są wygenerowane przez AI i sprawdzane przez zespół redakcyjny Unite.AI, aby zapewnić dokładność, rygor i odpowiedzialne relacjonowanie dynamicznie zmieniającego się krajobrazu bezpieczeństwa AI.