Megalodon-hyökkäys iski 5 561 GitHub-repositorioon kuudessa tunnissa
GitHub CI/CD -toimitusketjuhyökkäys nimeltä Megalodon on asettanut uuden vertailukohdan automaattiselle, laajamittaiselle repositorioiden vaarantamiselle. Kuuden tunnin aikaikkunassa hyökkääjät työnsivät 5 718 haitallista koodipäivitystä 5 561 GitHub-repositorioon käyttäen vääriä henkilöllisyyksiä työnkulkutiedostojen injektoimiseen, joiden tarkoituksena oli hiljaa tyhjentää pilvipalvelutunnisteet, SSH-avaimet ja lähdekoodisalaisuudet. Kampanjan pelkkä nopeus ja laajuus viittaa siirtymiseen teollistuneisiin putkilinjahyökkäyksiin, jotka ylittävät useimpien tiimien kyvyn havaita tai reagoida niihin reaaliajassa.
Kuinka Megalodon-hyökkäys toimi: Väärät henkilöllisyydet ja automatisoitu työnkulun injektointi
Megalodonin takana olleet hyökkääjät eivät turvautuneet nollapäivähaavoittuvuuksiin tai kehittyneeseen haittaohjelmistoon, joka toimitettaisiin loppukäyttäjien koneille. Sen sijaan he hyödynsivät GitHubin CI/CD-infrastruktuurin luotettua luonnetta. Rakentamalla vääriä avustajatahoja he lähettivät vetopyyntöjä tai muokkasivat suoraan työnkulkujen konfiguraatiotiedostoja – erityisesti YAML-tiedostoja, joita GitHub Actions käyttää automatisoitujen rakennus- ja käyttöönottoputkilinjojen määrittämiseen.
Kun haitallinen työnkulkutiedosto päätyy repositorioon, se suoritetaan automaattisesti aina kun putkilinja käynnistyy – yleensä push-tapahtumien tai vetopyyntöjen yhdistämisen yhteydessä. Suoritus tapahtuu GitHubin omassa runner-ympäristössä, jolla on usein pääsy repositorion salaisuuksiin, ympäristömuuttujiin ja pilvipalveluihin kohdennettuihin tokeneihin. Megalodonin työnkulut käyttivät tätä pääsyikkunaa tietojen suodattamiseen ulospäin – todennäköisesti hyökkääjien hallitsemaan infrastruktuuriin – ennen kuin repositorion ylläpitäjällä oli syytä tarkistaa muutos.
Kampanjan määrittelevä ominaisuus on sen automatisointi. Lähes 5 720 erillisen koodityönnön suorittaminen yli 5 500 repositorioon kuudessa tunnissa ei ole manuaalinen toimenpide. Se vaatii skriptattua työkalustoa, joka kykenee tunnistamaan kohteet, todentamaan väärien henkilöllisyyksien avulla, muodostamaan uskottavan näköisiä työnkulkumuutoksia ja lähettämään ne rinnakkain. Tämä automaation taso tarkoittaa, että hyökkäyspinta laajeni nopeammin kuin mikään ihmisvalvontatiimi pystyisi seuraamaan.
Mitä tunnistietoja varastettiin ja miksi se on tärkeää kehittäjille
Jokaisen haitallisen työnkulun hyötykuorma oli tunnistetietojen kerääminen. Kohteisiin kuuluivat pilvipalveluntarjoajien tunnisteet – yleisimmin AWS-, GCP- ja Azure-pääsyavaimet, jotka on tallennettu GitHub Secrets -toiminnolla tai joihin viitataan työnkulun ympäristömuuttujissa. Kohteena olivat myös SSH-yksityisavaimet, joita käytetään palvelimen käyttöön tai palveluiden väliseen todentamiseen, sekä kaikki lähdekoodiin tai konfiguraatiotiedostoihin upotetut selkotekstiset salaisuudet.
Nämä tunnistetyypit sisältävät kasautuvan riskin. Varastettu AWS-pääsyavain, joka on sidottu laajat oikeudet omaavaan IAM-rooliin, voi antaa hyökkääjälle mahdollisuuden käynnistää infrastruktuuria, suodattaa tietovarastoja tai liikkua sivuttain yhteydessä oleviin palveluihin minuuteissa. SSH-avaimet voivat tarjota pysyvän pääsyn tuotantopalvelimille kauan sen jälkeen, kun alkuperäinen tietomurto on havaittu ja GitHub-repositorio on siivottu. Näiden tietojen arvo ulottuu paljon itse repositorioiden ulkopuolelle.
Tämä ei ole hypoteettinen riskimalli. Aiemmin tänä vuonna CISA:n alihankkija paljasti AWS-avaimet ja selkotekstiset salasanat julkisessa GitHub-repositoriossa, mikä osoitti, että tunnistetietojen virheellinen hallinta kehitysympäristöissä vaikuttaa jopa organisaatioihin, joilla on omistettu tietoturvavelvoite. Megalodon yksinkertaisesti teollistutti saman hyökkäyspolun, jonka yksittäiset inhimilliset virheet ovat jo toistuvasti osoittaneet.
On myös syytä huomata, että tunnistetietojen varkaustyökalut ja -putkilinjat ovat itse kohteita. Äskettäinen Bitwarden CLI:n toimitusketjuhyökkäys osoitti, että jopa kehittäjien salaisuuksien hallintaan käyttämät työkalut voidaan vaarantaa ylävirtaan, mikä tarkoittaa, että luottamusketju ulottuu yksittäistä repositoriota tai putkilinjan konfiguraatiota pidemmälle.
Puolustuksen syvyys kehitystiimeille: Salaisuuksien hallinta, salattu viestintä ja käyttöoikeuksien hallinta
Megalodon hyödynsi useita heikkouksia, jotka ovat yleisiä sekä avoimen lähdekoodin että yksityisissä repositorioissa. Niihin puuttuminen vaatii kerrostettua lähestymistapaa yksittäisen kontrollin sijaan.
Ensinnäkin salaisuuksia ei tulisi koskaan tallentaa selkotekstinä työnkulkutiedostoihin, ympäristön konfiguraatiotiedostoihin tai lähdekoodiin. GitHubin salattu Secrets-toiminto tarjoaa peruslinjan, mutta näiden salaisuuksien tulisi myös noudattaa vähimmän oikeuden periaatetta. Työnkulku, joka ottaa käyttöön staging-ympäristöön, ei tarvitse tuotantotietokannan tunnistietoja. Salaisuuksien tarkka rajaaminen rajoittaa vahinkoa, kun työnkulku vaarantuu.
Toiseksi haarasuojaussäännöt ja vaaditut tarkistajat työnkulkutiedostojen muutoksille luovat ihmisen tarkistuspisteen, jonka automatisoidut hyökkäykset joutuvat ohittamaan. Vähintään yhden hyväksytyn tarkistuksen vaatiminen ennen muutoksia .github/workflows/-tiedostoihin voi hidastaa tai estää sen tyyppistä nopeaa automatisoitua injektiota, johon Megalodon turvautui.
Kolmanneksi kolmansien osapuolten GitHub Actions -toimintojen kiinnittäminen tiettyihin commit-SHA-tunnisteisiin kelluvan tagin sijaan estää erillisen mutta liittyvän hyökkäysvektorin, jossa vaarantunut toiminnon julkaisija päivittää hiljaisti tagin osoittamaan haitalliseen koodiin. Tämä on ollut mekanismina useissa viimeaikaisissa GitHub Actions -toimitusketjuihin kohdistuneissa tapauksissa.
Lopuksi työnkulun suoritusten auditointi lokitus ja poikkeamien havaitseminen voivat paljastaa odottamattomia lähtevien yhteyksien verkkoyhteyksiä tai epätavallisia salaisuuksien käyttömalleja. GitHubin auditointiloki-API ja kolmannen osapuolen CI/CD-tietoturvatyökalut voivat auttaa näiden signaalien tunnistamisessa.
Kuinka auditoida GitHub-repositoriosi ja CI/CD-putkilinjasi nyt
Jos organisaatiollasi on GitHub-repositorioita, joissa on aktiiviset CI/CD-putkilinjat, muutama välitön toimenpide on syytä priorisoida.
Tarkista kaikki .github/workflows/-hakemiston tiedostot äskettäin lisättyjen tai muokattujen kohteiden varalta, erityisesti sellaiset, jotka on lisännyt tunnistamaton avustaja. Tarkista työnkulkutiedostojen commit-historia erityisesti, ei vain oletushaarannäkymää.
Vaihda kaikki salaisuudet, jotka olivat aktiivisia hyökkäyksen aikana tai joita et voi varmistaa olevan paljastumattomia. Pilvipalvelun tunnistetietojen osalta tarkista palveluntarjoajan puoleisista käyttölokeista epätavalliset API-kutsut saman ajanjakson aikana.
Auditoi, millä repositorion avustajilla ja sovelluksilla on kirjoitusoikeus. Vääriin henkilöllisyyksiin perustuvat hyökkäykset riippuvat kyvystä työntää koodia, joten avustajaoikeuksien tiukentaminen ja pakollisten tarkistusten käyttöönotto työnkulkumuutoksille poistaa tärkeän sisäänkäyntipisteen.
Harkitse lopuksi omistetun salaisuuksien skannaustyökalun käyttöönottoa, joka suoritetaan jokaisen commitin yhteydessä ja joka havaitsee tunnisteet ennen kuin ne koskaan tallennetaan repositorioon. Useita avoimen lähdekoodin ja kaupallisia vaihtoehtoja integroituu suoraan GitHubiin.
Mitä tämä tarkoittaa sinulle
Megalodon-kampanja on käytännön esimerkki siitä, miksi CI/CD-putkilinjoista on tullut ensisijainen hyökkäyspinta. Kehittäjät ja tietoturvatiimit, jotka pitävät putkilinjan tietoturvaa toissijaisena sovelluksen tietoturvaan nähden, jättävät avoimen väylän arkaluonteisimpiin tunnistetietoihinsa.
Aloita salaisuuksien auditoinnilla tällä viikolla. Tarkista, kuka voi muokata työnkulkutiedostojasi, vaihda tunnisteet, joita et voi todentaa puhtaiksi, ja ota haarasuojaus käyttöön oletushaarassasi, jos et ole vielä tehnyt niin. Megalodon-hyökkäyksen nopeus tarkoittaa, että siihen mennessä kun hälytys laukeaa, suodatus on saattanut jo olla valmis. Ennaltaehkäisy ja käyttöoikeuksien rajaaminen ovat ainoat luotettavat puolustukset.
