Fant tusenvis av «sletta» hemmeligheter på GitHub
"White hat"-hacker fikk 250.000 kroner i belønning etter å ha funnet hemmeligheter utviklere trodde de hadde slettet. Sånn gjør du det riktig.
Mange utviklere "force-pusher" til GitHub for å bli kvitt tidligere tabber – men glemmer ofte at git-historikken beholder alt – også filer som har blitt slettet.
Såkalte "dangling commits" er commits som ikke lenger er koblet til commit-historikken via en kjent gren, men de eksisterer fortsatt i git-databasen.
Sikkerhetseksperten Sharon Brizinov hadde en mistanke om at slike dangling commits kunne inneholde hemmeligheter, og fikk rett, skriver Cybernews.com.
– Jeg skannet alle force pusher siden 2020 og fant hemmeligheter verdt 25.000 dollar (250.000 kroner) i "bug bounties" (dusører), skriver Brizinov i et blogginnlegg.
Admin-tilgang til alle repoene
Etter å ha skannet alle repoene ved hjelp av et egenutviklet verktøy, fant Brizinov ut at den tabben flest gjør, er å ved en feil commite .env-filer.
Det er MongoDB-hemmeligheter som lekkes mest, noe som ifølge Brizinovs analyser skyldes at juniorutviklere og studenter lekker MongoDB-hemmeligheter som for det meste brukes i uinteressante sideprosjekter.
De mest interessante lekkasjene er ifølge sikkerhetseksperten GitHub PAT-tokens (Personal Access Token) og AWS-hemmeligheter.
– Det var også disse som ga de høyeste dusørene!
Jeg kunne ha lest miljøvariabler, endret pipelines, pushet kode, opprettet nye "releases" og til og med slettet hele prosjektet.
Ett av funnene var et GitHub PAT-token som ga admin-tilgang til alle repoene tilhørende Istio, en populær løsning for administrasjon og sikring av mikrotjenester.
– Jeg kunne ha lest miljøvariabler, endret pipelines, pushet kode, opprettet nye "releases" og til og med slettet hele prosjektet. Potensialet for et massivt forsyningskjedeangrep var skremmende, sier Brizinov.
Istio har nå endret PAT-tokenet.
Vibekodet skanneverktøyet
Brizinov skriver at han faktisk vibe-kodet verktøyet han brukte til å skanne GitHub-repoene.
– Etter et par hundre manuelle gjennomganger hadde jeg fått nok og bestemte meg for å skalere opp gjennomgangen av lekkede hemmeligheter. Jeg brukte Vercel v0 til å «vibe-code» en hel plattform for å sortere disse “Oops Commit”-hemmelighetene.
Han har lagt ut hele løsningen som åpen kildekode på GitHub, hvis du vil prøve skanneren selv.
Dette må du gjøre hvis du har tabbet deg ut
Så bør du egentlig gjøre hvis du har tabbet deg ut og ved en feil commitet hele .env-filen, eller andre filer som inneholder hemmeligheter?
GitHub har skrevet en artikkel der de går grundig igjennom dette.
– Som et første steg må du oppheve og/eller bytte ut hemmeligheten. Når hemmeligheten er opphevet eller rotert, kan den ikke lenger brukes for tilgang, og det kan være tilstrekkelig for å løse problemet. Det er ikke sikkert det er nødvendig å gå videre med å omskrive historikken for å fjerne hemmeligheten, står det i artikkelen.
Hvis du likevel bestemmer deg for å skrive om git-historikken for å fjerne alle spor av tabben må du:
- Rotere hemmelighetene umiddelbart
- Skrive om den lokale repo-historikken ved hjelp av git-filter-repo
- Gjøre tiltak for å unngå å gjøre samme tabbe igjen. Sjekk .gitignore, bruk evt. verktøy, aktiver push protection.
Det er en risiko for at andre som har klonet klonet prosjektet kan reintrodusere hemmelighetene til git-repoet igjen neste gang de pusher. Så sørg for at alle på teamet enten sletter sine lokale kopier, eller grundig sørger for at den lokale kopien er fri for hemmeligheter før de pusher på nytt.
GitHub advarer mot en masse sideeffekter ved å skrive om git-historikken. Som sagt er det ofte nok å bare rotere hemmeligheten du har lekket.
