Hvordan brukte angriperne stjålne tokens til å kompromittere GitHub-repositorier?

Ifølge rapporten brukte angriperne stjålne tilgangstokens til å legge til «WFX stealer»-workflows i omtrent 66 000 GitHub-repositorier. Fordi GitHub behandler handlinger utført med gyldige tokens som legitime, kjørte de ondsinnede workflowene inne i pipelinen uten å utnytte noen programvarefeil.

Hva kan WFX-stealeren få tilgang til gjennom en kompromittert pipeline?

Rapporteringen beskriver workflowene som hemmelighetsstjelende, og en stealer som kjører i en pipeline kan nå alt den pipelinen kan nå, for eksempel API-nøkler, skylegitimasjon, distribusjonstokens, legitimasjon for pakkeregistre og andre GitHub-tokens. De nøyaktige dataene den samler inn, er ikke bekreftet.

GitHub-stjålne tokens planter WFX Stealer i 66 000 repoer

Q: Hvorfor er GitHub Actions-workflows et attraktivt mål for angripere?

Workflow-filer kjøres automatisk og har ofte tilgang til hemmelighetene et prosjekt bruker for å bygge, teste og distribuere kode. En ondsinnet workflow trenger ikke å utnytte en programvarefeil – den trenger bare å bli committet av noen GitHub tror er autorisert, og deretter kjører den inne i pipelinen.

Q: Ble jeg eller repositoriet mitt spesifikt påvirket av denne kampanjen?

Artikkelen sier at den ikke kan fortelle deg om et bestemt repositorium er på den påvirkede listen, og den tilgjengelige rapporteringen publiserer ingen. Leserne rådes til å se etter tegn på tukling selv.

En rapportert kampanje bygget rundt GitHub-stjålne tokens og WFX-stealeren setter rundt 66 000 repositorier i fare, ifølge dekning fra Cybernews. Angriperne skal ha brukt stjålne tilgangstokens til å plante ondsinnede workflow-filer, og dermed gjort en utviklingspipeline om til en måte å samle inn hemmeligheter. Den tilgjengelige rapporteringen er kort, så dette innlegget holder seg til det som er blitt uttalt, og fokuserer på praktiske tiltak utviklere kan gjøre nå.

Hvordan stjålne tokens muliggjorde GitHub-workflow-angrepet

Ifølge rapporten brukte kampanjen stjålne tokens til å legge til «WFX stealer»-workflows i omtrent 66 000 GitHub-repositorier. Et token er en legitimasjon som lar en person eller en applikasjon handle på en konto uten å skrive inn et passord. Hvis en angriper har et gyldig token med tilstrekkelige tillatelser, behandler GitHub handlingene deres som legitime.

Det er dette som gjør workflows til et attraktivt mål. GitHub Actions-workflows er filer som lagres i et repositorium og kjøres automatisk, ofte med tilgang til hemmelighetene et prosjekt bruker for å bygge, teste og distribuere kode. En ondsinnet workflow trenger ikke å utnytte en programvarefeil. Den trenger bare å bli committet av noen GitHub tror er autorisert, og deretter kjører den inne i pipelinen.

Kildesammendraget går ikke i detalj på hvordan tokens opprinnelig ble stjålet, og vi kommer ikke til å gjette. Det som betyr noe for leserne, er mønsteret: selve pipelinen blir leveringsmekanismen, og legitimasjonen som låser den opp, er den virkelige premien.

Hva WFX-stealeren kan eksponere fra utviklerkontoer

Rapporteringen beskriver workflowene som hemmelighetsstjelende, og den foreslåtte vinklingen bemerker at CI/CD-pipelines kan bli en vei til utvikleres hemmeligheter og personlige kontoer. I praksis kan en stealer som kjører i en pipeline, være posisjonert til å nå alt den pipelinen kan nå. Typiske eksempler på slikt materiale inkluderer:

API-nøkler og skylegitimasjon lagret som repositoriumshemmeligheter
Distribusjonstokens og legitimasjon for pakkeregistre
Andre GitHub-tokens tilgjengelige for workflowen

De nøyaktige dataene WFX-stealeren samler inn, er ikke bekreftet i informasjonen vi har, så behandle listen ovenfor som risikokategorier som er vanlige for pipeline-hemmeligheter, ikke som verifiserte funn om denne kampanjen. Den bredere bekymringen er at ett stjålet token kan føre til flere stjålne tokens. Hemmeligheter høstet fra ett repositorium kan låse opp andre tjenester, og det er slik et repositorium-kompromiss kan spre seg til personlige og organisatoriske kontoer.

Dette passer inn i et bredere tema vi har dekket før: systemer folk skal kunne stole på, blir vendt mot dem. Vår gjennomgang av hvordan en Pixel zero-click-sårbarhet og ScreenConnect-angrep mot MSP-er delte den samme ubehagelige tråden, viser hvor ofte det pålitelige verktøyet er det svake punktet.

Hvordan sjekke om repositoriene dine ble påvirket

Vi kan ikke fortelle deg om et bestemt repositorium er på den påvirkede listen, og den tilgjengelige rapporteringen publiserer ingen. Du kan likevel se etter tegn på tukling selv:

Gå gjennom workflow-filer. Åpne .github/workflows-mappen i hvert repositorium og se etter filer du ikke kjenner igjen, eller endringer du ikke har gjort.
Sjekk commit- og pull request-historikk. Se etter nylige commits eller grener som berører workflows, spesielt fra ukjente kontoer eller på merkelige tidspunkter.
Inspiser kjørelogger for Actions. Uventede kjøringer, nye triggere eller steg som gjør utgående nettverksforespørsler fortjener en nærmere titt.
Gå gjennom sikkerhetsloggen og autoriserte apper. I GitHub-innstillingene, sjekk hvilke personlige tilgangstokens, OAuth-apper og GitHub-apper som har tilgang, og fjern alt du ikke bruker.
Anta eksponering hvis du finner noe. Behandle hver hemmelighet den workflowen kunne lese, som kompromittert, og bytt den ut.

Herding av GitHub: tokens, MFA og tredjeparts Actions

Ingen av disse stegene er eksotiske, men sammen reduserer de hva et stjålet token kan gjøre.

Roter og begrens tokens. Tilbakekall gamle personlige tilgangstokens og utsted nye med det smaleste omfanget og korteste utløpet som fungerer. Finkornede tokens begrenset til bestemte repositorier er tryggere enn brede.

Slå på multifaktorautentisering. MFA beskytter påloggingen til kontoen din, men det er verdt å huske at et stjålet token kan omgå påloggingstrinnet helt. Det er derfor token-hygiene betyr like mye.

Begrens workflow-tillatelser. Sett standard workflow-token til skrivebeskyttet og gi skrivetilgang bare der en jobb virkelig trenger det. Krev gjennomgang før endringer i workflow-filer blir flettet inn, for eksempel gjennom grenbeskyttelse og code owners.

Vurder tredjeparts Actions. Fest Actions til en bestemt commit i stedet for en flyttbar tag, og foretrekk de fra vedlikeholdere du stoler på. Hold hemmeligheter unna jobber som ikke trenger dem.

Hva dette betyr for deg

Hvis du vedlikeholder selv et lite prosjekt på GitHub, er workflow-filene dine en del av angrepsflaten din. Et stjålet token kan la noen legge til en workflow som stille leser hemmelighetene dine, og du får kanskje aldri se noen varsel. Individuelle utviklere, vedlikeholdere av åpen kildekode og selskaper med automatisert distribusjon er alle i målgruppen.

Det gode er at forsvaret er innenfor din kontroll og koster lite tid. Dette er også en del av et tilbakevendende mønster der angripere går etter kontoene og verktøyene folk allerede stoler på. Vår dekning av Incransom som hevder et angrep på TrRAC Inc. er en annen type hendelse, men den understreker hvor raskt stjålet tilgang kan bli reell skade.

Handlingsrettede punkter

Roter GitHub-tokensene dine i dag og slett alle du ikke lenger bruker.
Aktiver MFA på hver konto med repositoriumstilgang.
Revider .github/workflows-filene dine for endringer du ikke har gjort.
Sett workflow-tillatelser til skrivebeskyttet som standard og fest tredjeparts Actions.
Hvis du finner noe mistenkelig, bytt ut hver hemmelighet den workflowen kunne få tilgang til.

Rapportene om GitHub-stjålne tokens og WFX-stealeren er fortsatt i utvikling, og detaljer kan endre seg. Ikke vent på bekreftelse for å rydde opp i ditt eget oppsett: roter tokens, aktiver MFA og revider workflowene dine i dag.