Stjålne GitHub-adgange brugt til at stjæle udvikleres hemmeligheder

Stjålne GitHub-adgangstokens bliver brugt til at plante automatiske arbejdsgange, som kan afsløre virksomheders adgangsnøgler og andre hemmeligheder. Det fremgår af en ny analyse, som sikkerhedsfirmaet Wiz offentliggjorde søndag den 25. oktober. Forskerne har fundet mere end 13.500 plantede kodegrene på over 850 kompromitterede konti i kampagnen Gheist.

Ifølge Wiz er angreb lykkedes i private kodeprojekter og GitHub Enterprise-miljøer, mens en nyere GitHub-beskyttelse har bremset dem i offentlige projekter. For danske virksomheder, der bruger GitHub til at bygge og udgive software, er forskellen vigtig: Et projekt bliver ikke beskyttet af netop denne kontrol, blot fordi koden er privat.

Angriberne bruger en allerede stjålet adgang

Gheist begynder med et kompromitteret token – en digital adgangsnøgle, som software kan bruge på en kontos vegne. Kampagnen tilføjer en arbejdsgang med navnet sync-check. Den får hemmeligheder skrevet til kørselsloggen, hvorefter angriberens værktøj henter loggen gennem GitHubs egen grænseflade og sletter kørslen kort efter.

Wiz har fulgt aktiviteten siden 15. september. De offentliggjorte tal gælder fundne kodegrene og konti; de er ikke en opgørelse over 850 virksomheder eller 13.500 særskilte datalæk. Analysen siger heller ikke, at alle GitHub-brugere er ramt.

GitHubs stop gælder offentlige projekter

GitHub indførte den 28. juli en kontrol, der sætter visse potentielt skadelige Actions-kørsler på pause. GitHub Actions er tjenesten, der blandt andet kan teste kode og automatisere udgivelsen af software.

Når en kørsel tilbageholdes, skal en samarbejdspartner med skriverettigheder gennemgå og godkende den, før den må starte. Godkendelsen skal gives fra en websession, hvor vedkommende er logget ind. Kontrollen kræver ingen særskilt opsætning fra brugeren.

GitHubs egen meddelelse afgrænser imidlertid funktionen til offentlige projekter på github.com. Den omfatter ikke GitHub Enterprise Server. Det er derfor ikke en generel garanti mod misbrug af stjålne tokens, og en ukendt arbejdsgang bør ikke godkendes, blot fordi den ligner rutinemæssig vedligeholdelse.

Hemmeligheder er nødvendige – men skal afgrænses

Udviklingsteams gemmer ofte adgangsoplysninger som såkaldte secrets, så eksempelvis en automatisk udgivelse kan logge ind på den rigtige tjeneste. GitHubs dokumentation beskriver tre niveauer: organisation, det enkelte kodeprojekt og særlige driftsmiljøer.

Organisationshemmeligheder kan deles mellem flere projekter, men adgangen kan begrænses til bestemte projekter. Miljøhemmeligheder kan desuden beskyttes med krav om godkendelse fra udpegede personer. En arbejdsgang kan da ikke hente dem, før godkendelsen foreligger.

Den afgrænsning betyder noget for skadens mulige omfang. En nøgle til én afgrænset opgave bør ikke samtidig give adgang til alle organisationens projekter eller produktionssystemer. GitHub anbefaler de mindst mulige rettigheder og peger på fint afgrænsede tokens eller GitHub Apps med kortlivede tokens som muligheder.

En skjult værdi i loggen kan stadig lække

GitHub skjuler automatisk kendte hemmeligheder, når de optræder i kørselslogs. Men dokumentationen understreger, at beskyttelsen ikke er garanteret, når en værdi omformes. Det er altså ikke tilstrækkeligt at antage, at platformens logfilter altid fanger en adgangsnøgle.

GitHubs sikkerhedsvejledning anbefaler både at fjerne logs med eksponerede hemmeligheder og at udskifte de pågældende adgangsoplysninger. Det sidste er afgørende: At slette et spor gør ikke en allerede kopieret nøgle ugyldig.

Sikkerhedsfirmaet Safeguard fremhæver i sin gennemgang af Gheist, at teams også bør se efter usædvanlige kodegrene, nye workflow-filer og kørsler, der hurtigt bliver slettet. Firmaet gør samtidig klart, at dets eget værktøj ikke kan tilbagekalde GitHub-tokens eller læse organisationens revisionslogs.

Opgaven ligger hos dem, der administrerer adgangen

For almindelige brugere af en virksomheds hjemmeside kræver rapporten ikke i sig selv et nyt login eller en ændring af en adgangskode. Den konkrete kontrol ligger hos udviklings- og driftsteams: Hvem kan ændre automatiseringen, hvilke hemmeligheder kan den nå, og er der tegn på ukendte ændringer?

Der er ikke i de gennemgåede oplysninger dokumentation for navngivne danske ofre. Den nye analyse dokumenterer derimod en igangværende angrebsmetode og en vigtig begrænsning i beskyttelsen: Godkendelsesstoppet for offentlige projekter kan ikke stå alene som sikkerhed for private kodeprojekter og virksomheders egne installationsmiljøer.