Hemmelighetslekkasjer: Ett skritt til dødensaster

Å gi husnøklene til kriminelle er definitivt ikke den beste ideen. Men det er det som ofte skjer i de fleste organisasjoner som utvikler moderne programvare.

I dette første innlegget om lekkasjer av hemmeligheter skal vi analysere hvorfor dette skjer så ofte, hva konsekvensene er, og hvilke tiltak som må iverksettes for å forhindre eller redusere problemet og håndtere hendelser med lekkasjer av hemmeligheter.

Herregud! Jeg sendte skytilgangsnøklene mine til et offentlig arkiv

Hardkodede hemmeligheter i kildekode eller konfigurasjonsfiler i DevOps-verktøy kan havne i dårlige hender. Hvis hemmeligheten er commitlagret i et offentlig kildekodelager, er du dømt til å mislykkes. Men selv private kildekodelager er ikke trygge, ettersom hemmeligheter også lekker gjennom applikasjonsbinærfiler, logger eller stjålet kildekode.

I ettertid er det urovekkende hvor ofte en enkel forglemmelse har ført til et alvorlig sikkerhetsbrudd. Bare google «AWS-nøkkellekkasjer","Lekkasjer av GitHub-tilgangstoken«, og så videre. Ikke ta disse eksemplene som skjulte anbefalinger for den ene eller den andre leverandøren. Bruk dine egne!»

For eksempel den (beryktede) Codecov-angrep av april 2021 var mulig fordi Codecov Docker-avbildningen inneholdt git-legitimasjon som tillot en angriper å få tilgang til Codecovs private git-repositorier og legge til en enkelt linje i Codecovs bash-opplastingsskript for samlingsmiljøvariabler og URL-er til git-repositorier.

Husk at deler av belønningen i angrep er hemmelighetene for å få tilgang til flere systemer, og mange angrep investerer tungt i påloggingsinformasjon, kryptonøkler og eksfiltrering av tokens. 

Problemet er det Hardkodede hemmeligheter er vanligeI mars 2022 ble Lapsus$-leiligheten lekket 189 GB av Samsungs kildekode og andre sensitive filer. Analysen avdekket at den inneholdt noen 6,600 hardkodede hemmeligheter90 % for interne systemer, men 10 % for eksterne tjenester og verktøy som GitHub, AWS eller Google. Disse hemmelighetene inkluderte AWS/Twilio/Google API-nøkler, databasetilkoblingsstrenger og annen sensitiv informasjon. Dette er den nyeste teknologien i de fleste kodebaser.

Hemmelighetslekkasjer er den enkleste veien til angrep i forsyningskjeden

Pakkeavhengigheter er for tiden det hyppigste, men ikke det eneste målet, for angrep i forsyningskjeden. De slemme gutta kan lage en ny pakke som ender opp med å bli installert i ofrenes programvare (ved hjelp av en Typosquatting og andre teknikker), men vanligvis prøver de å infisere en eksisterende pakke enten ved å legge til modifikasjoner i kildekoden i programvarelagre (SCM) som GitHub, GitLab eller BitBucket, eller ved å legge til skadelige versjoner i offentlige registre som NPM, PyPI, RubyGems og Maven Central.

Men å injisere ondsinnet kode eller en ondsinnet avhengighet skjult i en intrikat avhengighetsgraf krever login legitimasjon som brukernavn/passord, tokener eller tilgangsnøkler (la oss kalle dem «nøkler” forkortet), for henholdsvis målkildelageret eller det offentlige registeret. 

Skurkene får noen ganger tak i nøklene via sosialteknikk. De angrepet mot event-stream populær NPM-pakke gir et godt eksempel. Men å søke etter lekkede login legitimasjon eller tilgangsnøkler er den vanligste angrepsteknikken for angrep i forsyningskjeden for programvare.

Kildelager og pakkeregistre er to viktige systemer i programvarebyggingen. pipelineMen det finnes mange verktøy i DevOps: CI/CD systemer, verktøy for å kjøre tester, automatisering av konfigurasjon og klargjøring, eller distribusjon og utgivelse. Alle disse kan misbrukes til å injisere skadelig kode i programvare. Lekkasje av gyldige nøkler for disse verktøyene fører direkte til elendighet og smerte. Tenk deg å lekke root-tilgangsnøkler med full kontroll over dine offentlige skyressurser ...

De vanlige anbefalingene

Vi sier ikke noe nytt her, det vet dere alle. Men ta grep! Husk at roboter jevnlig skanner alle offentlige SCM arkiver. Noen anbefalinger, i tilfeldig rekkefølge.

• Hvis du har ansvar for IT-sikkerhetsstyring, definere hvordan hemmeligheter skal håndteres i sikkerhetspolicyen. Men policyer er bare så gode som håndheving: sørg for at en retningslinje for håndtering av hemmeligheter håndheves i organisasjonen din – inkludert ikke bare DevOps-teamene dine, men også programvareleverandørene dine, og at organisasjonens hendelsesplan inneholder bestemmelser for hendelser med lekkasje av hemmeligheter.
• Implementere og håndheve multifaktorautentisering (MFA, 2FA eller hvilket som helst akronym). Og ingen besparelser på sikkerhet: en USB-sikkerhetsnøkkel er verdt de få kronene den koster. Du må git-pushe hvilken som helst av dine tusenvis av påloggingsinformasjoner (enkelt) og deretter bli full og legge igjen nøklene dine i en bar med noe som lenker til deg (oddsen er bare litt mindre, spesielt hvis du er avholdsmann).
• Bruk en passordbehandler med et sterkt, ulagret passord. For håndtering av hemmeligheter i systemer, bruk Hemmelige hvelv. CI/CD systemer, skyleverandører, SCMs og andre DevOps-verktøy tilbyr denne tjenesten, men du kan velge en generisk Secret Vault-løsning.
• Kjøp helst Kortlevd tokens til langlivede tilgangsnøkler. De er lettere å tilbakekalle og eksponerer et mer begrenset vindu for ondskapen.
• Begrens gjenbruk av legitimasjonAngripere vil gjenbruke innsamlet legitimasjon for et mål i andre systemer, et annet poeng for bruk av en passordbehandler. Passordbehandlere og hemmelige hvelv bør gjøre gjenbruk av legitimasjon til en saga blott.
• Begrens og overvåk bruken av admin passord. De er kraftige nok til å fortjener spesiell sporing.
• Implementere sterk hashing og krypteringTilbake til USB-nøkler (kryptografiske nøkler), strenge prosedyrer for overføring av legitimasjon med partnere og kolleger, og så videre.
• Bruk hemmelighetsskanner, for eksempel løpe i en pre-commit krok for å unngå lekkasjer i versjonskontrollsystemer, som en sikkerhetsport. Før tingen er viktig her. Alternativt kan du bruke post-hoc-skanninger for å oppdage lekkede hemmeligheter, for eksempel som en sjekk før pull request fusjonerer. Merk: Xygeni-plattformen vår inkluderer en hemmelighetsskanner som tillater begge driftsmoduser. 
• Det manuelle alternativet til å bruke kode anmeldelser å søke etter hardkodede hemmeligheter har høyere kostnader og fungerer etterpåcommit (men forhåpentligvis i hvert fall før hemmeligheten blir tilgjengelig for utenforstående). Men anmeldelser kan avdekke ukonvensjonelle hemmeligheter som kan unngå hemmelighetsskannere.       
• Unngå ved et uhell commitlegge til vanlige filer med hemmeligheter for versjonskontroll med passende ekskluder mønstre (som `gitignore`-malen), med hensyn til filer som .env, .npmrc, .pypirc, midlertidige filer ... Et ekstra lag i sikkerhetsløken, ja.
• Og den siste på denne lange listen: la skyleverandørene utføre skanninger for nøklenes lekkasjer, når det er tilgjengelig. I det minste dette kan gi deg beskjed om lekkasjen når den skjedde, men sikkerhet er et must for skyleverandører. Dette post-hoc Hemmelig skanning er ikke særlig gjennomsiktig med hensyn til hvor og hvor ofte skanningen utføres, og krever ofte eksplisitt oppsett, men er absolutt den siste ressursen når alt annet feiler.

Herregud! Jeg sendte skytilgangsnøklene mine til et offentlig depot, ta #2

Det kan skje med den beste av oss. Brett opp ermene!

Forny/tilbakekall/deaktiver den lekkede hemmeligheten umiddelbart! Hvis kontoen har anstendig MFA, er risikoen mye lavere. Det kan være vanskeligere med f.eks. private nøkler på nettsteder (du må utstede et nytt sertifikat for en ny privat nøkkel og tilbakekalle den eksisterende), men moderne verktøy har en rask måte å fornye legitimasjon eller tilbakekalle tokener på. 

Følg trinnene som anbefales av leverandøren når de er tilgjengelige, som for eksempel AWS i dette eksemplet.

Identifiser årsaken til lekkasjen. Å vite hvordan det skjedde er avgjørende for avsløring, analyse, inneslutning og lærdomsaktiviteter.

Rapporter deretter lekkasjen til de berørte partene, og forklar tiltakene du tar for å tette lekkasjen og redusere skaden. Det finnes ingen måte å reversere skaden på, det som ble lekket, er lekket. Vær transparent og informer andre slik at de kan iverksette tiltak. 

Begynn deretter med etterforskning. De eksponeringsvindu er tiden mellom lekkasjen og tidspunktet da hemmeligheten ikke var gyldig. Vær klar til å lese logger og spore uvanlig aktivitet med den berørte kontoen i løpet av dette vinduet. Fjern kontoer og nøkler generert med den berørte kontoen. Husk at hvis den berørte kontoen har administratorrettigheter, er løsningen mye mer kompleks. 

Omskriving av (versjonskontroll) historikk er komplekst. Selv totalitære stater prøver dette uten hell (ordspill ment). Og sannsynligvis irrelevant: hackerne eller robotene på offentlige repositorier kan ha klonet repositoriet eller allerede ha hentet ut gullet, spesielt hvis eksponeringsvinduet er stort nok. 

Hvis du er eventyrlysten og vil se selv hvor lang tid det tar for roboter å oppdage en lekket hemmelighet, kan snubletråder som Kanariøyner lar deg eksperimentere. Husk at roboter svartelister standarden canarytokens.org domene…