Over 9 300 lekkede AWS-nøkler virket fortsatt

Offentlig eksponerte AWS-nøkler var ikke nødvendigvis kortvarige glipper. Truffle Securitys undersøkelse fra august 2022 til august 2026 viser at mange forble gyldige i årevis – også nøkler med nok rettigheter til å overta bedriftskontoer i AWS, Amazons skytjeneste.

Hovedfunnet: Eksponering ble ofte til et varig sikkerhetshull

Truffle Security samlet inn 431 875 forekomster av AWS-hemmeligheter fra offentlige kodearkiver, Git-historikk, datasett, Docker-avbildninger, containerregistre og logger fra kontinuerlig integrasjon (CI). Etter at duplikater var fjernet, representerte materialet 64 024 unike AWS-tilgangsnøkler knyttet til 50 654 AWS-kontoer.

Forskerne klarte å verifisere 10 616 komplette nøkkelpar. Da de testet disse på nytt 10. august, autentiserte 88 prosent fortsatt. Det betyr at mer enn 9 300 offentlig eksponerte nøkler fremdeles kunne brukes.

At en nøkkel dukker opp i et offentlig arkiv, betyr ikke automatisk at den fortsatt er farlig. Risikoen blir akutt når nøkkelen ikke er tilbakekalt, fortsatt godtas av AWS og har reelle tillatelser. I denne undersøkelsen opptrådte disse tre forholdene ofte samtidig.

768 bedriftsnøkler ga full administratorkontroll

Av de aktive nøklene som kunne knyttes til bedriftskontoer, var 817 tilordnet selskaper. Disse omfattet:

• 526 nøkler til AWS-rotkontoer
• 242 nøkler til IAM-brukere med AWS-policyen AdministratorAccess
• 768 nøkler totalt som ga full administrativ kontroll over en bedrifts AWS-konto

Rotbrukeren har det høyeste kontrollnivået en AWS-kunde kan ha. En IAM-identitet med AdministratorAccess kan på sin side utføre handlinger på tvers av AWS-tjenester med svært vide rettigheter.

En gyldig nøkkel på ett av disse nivåene kan åpne for konto-overtakelse, uautorisert opprettelse av ressurser, tilgang til data og misbruk av skytjenester som gir uventede regninger.

Funnene handler derfor ikke bare om ryddigere kildekode. De peker også på svakheter i tilganger og livssyklusforvaltning. Å fjerne en nøkkel fra en synlig fil beskytter ikke kontoen dersom noen allerede har kopiert den. Nøkkelen må tilbakekalles eller roteres.

Hugging Face var den største enkeltkilden

Hugging Face sto for 8 482 eksponeringer av AWS-legitimasjon, og var dermed den største enkeltkilden i rapporteringen. Truffle Security oppga at 17,9 prosent av disse AWS-legitimasjonene var rotnøkler.

Dette inngår i en bredere gjennomgang av offentlige data på Hugging Face. Truffle Security opplyste at selskapet undersøkte 7,6 petabyte med offentlige datasett og fant aktive tilgangsopplysninger i tusenvis av datasett. Det viser hvordan hemmeligheter kan bli liggende utenfor vanlige programvarearkiver og følge med data som distribueres offentlig.

For sikkerhetsteam betyr det at det ikke er nok å skanne dagens kildekode. Git-historikk, byggeartefakter, containeravbildninger, registre, publiserte datasett og CI-utdata kan bevare nøkler selv etter at utviklere tror de er fjernet.

Mange nøkler var flere år gamle

Medianalderen på legitimasjonen var omtrent 1 831 dager, altså rundt fem år. Den eldste nøkkelen var 17,4 år gammel. Bare 13,7 prosent av oppføringene hadde en nyere nøkkel knyttet til samme bruker, noe som tyder på at de fleste ikke var blitt erstattet gjennom vanlig nøkkelrotasjon.

Langlivede tilgangsnøkler gir uvedkommende mer tid til å misbruke dem og gjør det vanskeligere å fastslå hvem som har ansvaret. De kan overleve både personellendringer, migreringer, opprydding i arkiver og skifte av driftsansvar.

Alder bør derfor behandles som et faresignal. En eksponert nøkkel som er flere år gammel, bør ikke avskrives som foreldet uten kontroll. Den bør verifiseres, tilbakekalles og undersøkes – med mindre eieren kan dokumentere at den ikke lenger er gyldig.

Få kontoer hadde kostnadsvarsler

Truffle Security kunne lese kontoinformasjon for 2 754 kontoer, men bare 262 av dem hadde varsler for AWS-budsjett aktivert.

Budsjettvarsler erstatter ikke tilbakekalling av nøkler eller overvåking av sikkerhetshendelser. De kan likevel gi et tidlig signal dersom lekkede nøkler brukes til å opprette dyre ressurser, for eksempel til kryptoutvinning eller annet misbruk av skykapasitet.

Uten en varslingskanal som når noen med myndighet til å reagere, kan unormal pengebruk fortsette lenge etter at en konto er kompromittert.

Hva AWS-varsler løser – og ikke løser

Rapporteringen beskriver AWS-beskyttelse som kan oppdage offentliggjorte tilgangsnøkler, varsle berørte kunder og innføre begrensninger eller karantenetiltak. At så mange av de testede nøklene fortsatt var gyldige, tyder imidlertid på at varsling og oppdagelse ikke alltid førte til rask tilbakekalling eller rotasjon hos kunden.

Oppdagelse er bare første steg i håndteringen av en lekket nøkkel. En fullstendig respons må identifisere eieren, kartlegge hva nøkkelen har tilgang til, undersøke mulig misbruk og gjøre nøkkelen ugyldig.

Truffle Security beskriver sin egen validering som lesebasert: Selskapet kontrollerte om legitimasjonen kunne autentisere og undersøkte tillatelses- eller kontometadata, uten å endre kunders ressurser. Denne metodikken er gjengitt slik Truffle Security selv beskriver den, og er ikke uavhengig bekreftet i alle kildene som er tilgjengelige her.

Dette bør organisasjoner gjøre etter en AWS-lekkasje

1. Tilbakekall eller roter nøkkelen umiddelbart

Slett eller deaktiver en offentliggjort tilgangsnøkkel, og opprett bare en erstatning dersom tilgangen fortsatt er nødvendig. Å fjerne hemmeligheten fra et arkiv, slette en fil eller skrive om Git-historikken gjør ikke kopier som allerede er hentet, ugyldige.

2. Fjern rotnøkler

AWS-rotnøkler bør ikke brukes til vanlig programmatisk tilgang. Slett dem, og flytt arbeidsbelastninger over til kontrollerte identiteter med så begrensede rettigheter som mulig.

3. Kartlegg rettigheter og eierskap

Finn ut hvilken konto, bruker, tjeneste og hvilke ressurser nøkkelen tilhørte. Prioriter nøkler med rotprivilegier, AdministratorAccess, bred datatilgang eller mulighet til å opprette infrastruktur.

4. Undersøk aktivitet før og etter tilbakekalling

Gå gjennom autentiseringsaktivitet, CloudTrail-logger, endringer i IAM, nyopprettede ressurser og fakturering på jakt etter mistenkelig aktivitet. Tilbakekalling stanser videre bruk av den eksponerte nøkkelen, men viser ikke om den allerede er blitt misbrukt.

5. Bytt ut langlivede nøkler med kortlivede identiteter

Bruk kortlivede IAM-roller og arbeidsbelastningsidentiteter i stedet for permanente tilgangsnøkler når det er mulig. Minste privilegiums-prinsippet begrenser skaden en lekket legitimasjon kan gjøre.

6. Aktiver budsjettvarsler og en tydelig beredskapslinje

Konfigurer varsler i AWS Budgets og overvåking av kostnadsavvik. Varslene bør sendes til personer som kan handle raskt. Økonomisk overvåking er et sikkerhetsnett – ikke en erstatning for skanning etter hemmeligheter, nøkkelrotasjon og jevnlig tilgangskontroll.

Den større sikkerhetslærdommen

Det viktigste funnet var ikke bare antallet hemmeligheter. Det var kombinasjonen av offentlig eksponering, fortsatt gyldighet, høye privilegier, ekstrem alder og svak overvåking.

Offentlige datalagre kan bevare tilgangsopplysninger lenge etter at en organisasjon har glemt hvor de ble brukt. En kopiert nøkkel kan på sin side fortsette å virke helt til den uttrykkelig tilbakekalles.

Den tryggeste arbeidsregelen for skytjenester er derfor enkel: Behandle enhver eksponert AWS-legitimasjon som kompromittert. Kartlegg hva den kan nå, roter eller tilbakekall den umiddelbart, og erstatt langlivede nøkler med kortlivede identiteter med minst mulige rettigheter.