Tekoälyavusteinen muutos avasi tien Snowflaken sisäiseen Jira-järjestelmään

Myöhemmin käytetty sed-suodatus ei voinut korjata ongelmaa, koska GitHub oli jo laajentanut lausekkeen ennen shellin suorittamaa komentoa. Tässä vaiheessa hyökkääjän syöte oli siis jo tulkittu osaksi komentoriviä.

Työnkulun

issues: opened

Muutoksen tekijätiedoissa Copilot Autofix powered by AI mainittiin kanssatekijänä, eikä tekoälyavusteinen tarkistus nostanut ongelmaa esiin. Saatavilla oleva näyttö ei kuitenkaan osoita, loiko Copilot vaarallisen muutoksen vai tarkasteliko se ihmisen tekemää muutosta ja jätti haavoittuvuuden huomaamatta. Täsmällisin johtopäätös on, että Copilot liittyi muutokseen eikä havainnut injektiota – mallin varmaa tekijyyttä ei ole osoitettu.

Näin Red Agent löysi ja todensi vian

Wizin Red Agent analysoi Snowflaken julkista GitHub-organisaatiota etsien riskialttiita CI/CD-malleja. Se tunnisti Jira-työnkulun, jossa epäluotettavaa ongelman tietoa käytettiin shellin run:-lohkossa, ja päätteli, että erityisesti muotoiltu julkinen ongelman otsikko voisi johtaa komentojen mielivaltaiseen suorittamiseen GitHubin ylläpitämällä Actions-suorittimella.

23. kesäkuuta – vain viisi päivää haavoittuvan muutoksen yhdistämisen jälkeen – agentti avasi Snowflaken HackerOne-tietoturvanpaljastusohjelman puitteissa muotoillun ongelman. Otsikko pakeni shell-merkkijonosta, minkä jälkeen työnkulku lähetti Jiran tunnistetiedot Wizin hyväksyttyä konseptitodistetta varten hallinnoimaan out-of-band-palveluun eli erilliseen yhteydenottopisteeseen.

Kyse ei ollut luvattomasta tunkeutumisesta vaan hyväksytystä tietoturvatestistä. Löydön tekninen merkitys oli silti todellinen: julkisen ongelman avaaminen saattoi johtaa koodin suorittamiseen työnkulussa, joka käsitteli sisäisiä tunnistetietoja.

Mihin tunnukset antoivat pääsyn?

Hyödynnetyllä työnkululla oli käytössään Snowflaken sisäisen Jiran asetuksia, kuten Jiran osoite, käyttäjän sähköpostiosoite ja API-tunnus. Palautunut tunnus liittyi osoitteeseen qa@snowflake.net. Wiz käytti sitä kirjautuakseen sisäiseen Jira-portaaliin ja arvioidakseen mahdollista altistumista.

Raportoinnin mukaan tunnuksella oli lukuoikeus projekteihin, jotka liittyivät muun muassa suunnitteluun, tietoturvan vaatimustenmukaisuuteen ja bug bounty -toimintaan. Saatavilla oleva näyttö ei kuitenkaan määritä tunnuksen koko oikeusjoukkoa eikä luettele lopullisesti kaikkia tietueita, joihin sillä olisi ollut pääsy. Vahvin tuettu johtopäätös on, että tunnus mahdollisti pääsyn arkaluonteiseen sisäiseen Jira-sisältöön – ei rajoittamatonta pääsyä Snowflaken järjestelmiin.

Haavoittunut kohde oli repositorion CI/CD-automaatio. Julkaistusta Snowflake Connector for .NET -versiosta ei raportoitu haavoittunutta versiota, koska ongelma oli GitHub Actions -työnkulussa, ei liittimen ajonaikaisessa koodissa.

Snowflake reagoi nopeasti

Wiz ilmoitti haavoittuvuudesta 23. kesäkuuta. Snowflake korjasi työnkulun samana päivänä ja vaihtoi altistuneen Jira-tunnuksen seuraavana päivänä.

Snowflake tarkasteli tämän jälkeen lokitietoja ja ilmoitti, että Wiz oli ainoa toimija altistumisjakson aikana. Wiz puolestaan kertoi poistaneensa turvallisesti käyttämänsä konseptitodisteen tiedot.

Luvattomasta kolmannen osapuolen pääsystä ei raportoitu. Tapaukselle ei ilmoitettu CVE-tunnusta, eikä yhdenkään julkaistun liitinversion raportoitu kärsineen ongelmasta. Nämä rajaukset kuvaavat vahvistettua vaikutusta, mutta eivät tee alkuperäisestä työnkulkusuunnittelusta turvallista: julkisen ongelman otsikon ei olisi pitänyt päästä osaksi shell-komentoa työnkulussa, joka käsitteli sisäisiä tunnistetietoja.

Mitä tästä pitäisi oppia CI/CD-ympäristöissä?

Snowflaken tapaus ulottuu Copilotia laajemmalle. GitHub-lausekkeista peräisin olevia ongelmien ja pull requestien otsikoita, haarojen nimiä ja kommentteja on käsiteltävä vihamielisenä syötteenä aina, kun ne siirtyvät shell-komennon käsiteltäväksi.

Turvallisempi työnkulkusuunnittelu sisältää esimerkiksi seuraavat käytännöt:

• Välitä epäluotettavat arvot ympäristömuuttujina sen sijaan, että upottaisit ne suoraan run:-skripteihin.
• Rakenna JSON rakenteisilla työkaluilla, kuten jq:lla, älä kokoamalla shell-merkkijonoja käsin.
• Lainaa ja validoi tiedot shell-rajapinnassa.
• Älä anna tunnistetietoja käsittelevälle vaiheelle pääsyä hyökkääjän hallitsemaan sisältöön, jos se voidaan välttää.
• Tarkista tekoälyn tuottamat tietoturvamuutokset yhtä huolellisesti kuin ihmisen kirjoittama koodi.

Tapaus tiivistää uudenlaisen tietoturvariskin: yksi tekoälyavusteinen koodausjärjestelmä voi jättää vaarallisen CI/CD-muutoksen huomaamatta, kun taas autonominen hyökkäysagentti löytää ja todentaa sen muutamassa päivässä. Automaatio voi nopeuttaa sekä korjaamista että hyväksikäyttöä – mutta se ei korvaa riippumatonta tarkistusta.