Stripe-nøkler på avveie kan ha satt 688 363 kunderegistre i fare

650 aktive nøkler

Forskerne skal ha funnet 650 aktive sk_live-nøkler og ni begrensede nøkler. Av de berørte kontoene kunne 573 ta imot betalinger, 531 gjennomføre utbetalinger og 519 gjøre begge deler, ifølge analysen som er gjengitt i rapporteringen.

En Stripe-hemmelig nøkkel er en faktisk API-legitimasjon – ikke bare en kontoidentifikator. Hvor mye tilgang den gir, avhenger av rettighetene og kontooppsettet. En kompromittert nøkkel kan likevel gi innsyn i butikkens Stripe-ressurser og åpne for uautoriserte betalingsoperasjoner.

Testing omtalt i rapporteringen viste at én aktiv nøkkel kunne brukes til å hente kundelister, opprette falske betalingslenker og gjennomføre testbelastninger. Mulige følger er kartlegging av kundedata, betalingssvindel, uautoriserte refusjoner, målrettet phishing og sosial manipulering knyttet til betalinger. Kontoer med utbetalingsfunksjon må i tillegg kontrollere at utbetalingsinnstillinger og mottakerdetaljer ikke er endret.

Det praktiske problemet er tempoet: En lekket servernøkkel kan forvandle en svakhet i hemmelighetshåndteringen til en aktiv svindelsak før virksomheten rekker å oppdage uvanlig aktivitet.

Hvorfor dette ikke ser ut som et Stripe-innbrudd

Tilgjengelige funn tyder på at angriperne brukte gyldige nøkler tilhørende enkeltstående Stripe-kunder for å hente data gjennom Stripes ordinære API. Forskere som undersøkte filene uten nettilgang, sa at Stripe-lignende objekter og mappestrukturen stemte med eksporter fra API-endepunkter. De brukte ikke de lekkede nøklene til å logge inn eller undersøke kundenes aktive miljøer.

Skillet er viktig. Den mest sannsynlige kontrollsvikten ligger da hos stedene der bedrifter oppbevarer eller eksponerer hemmeligheter, for eksempel:

• infostealer-skadevare på utvikleres eller administratorers enheter
• offentlige kodearkiver og historisk Git-data
• åpne .env-filer og serverkonfigurasjoner
• skylagring, sikkerhetskopier og containerlag
• CI/CD-systemer og logger fra GitHub Actions
• feilkonfigurerte servere eller automatiserte søk etter eksponerte variabler

Den opprinnelige tyveriveien for de 659 kontoene er ikke fastslått. Dette er mulige eksponeringskilder, ikke en bekreftet felles årsak for hele datasettet.

Flere tall bør ikke blandes sammen

Hudson Rock knyttet en relaterte forum-publisering til den samme aktøren. Denne ble omtalt som 669 leverandørmapper og 1 033 kompromitterte API-nøkler, med en annonsert størrelse på 33 GB. Den tilgjengelige nedlastingen skal ha vært mindre. Aktøren hevdet også å ha rundt 20 000 ytterligere kompromitterte Stripe-nøkler og antydet at flere datasett kunne bli publisert.

Tallene bør ikke summeres til én bekreftet total. Forskjellen mellom 659 kontoer, 669 leverandørmapper og 1 033 nøkler kan skyldes ulike datasett, flere nøkler per konto, duplikater eller forskjellige opptellingsmetoder. Påstanden om 20 000 nøkler er fortsatt bare en ubekreftet påstand fra aktøren.

De mest berørte landene i den tilgjengelige rapporteringen var:

• USA: 212 leverandører
• Storbritannia: 81
• Frankrike: 57
• Canada: 38
• Brasil: 30
• Australia: 27

Fordelingen må ses i lys av at omfanget av datasettet fortsatt var under vurdering.

Dette bør Stripe-bedrifter gjøre nå

1. Roter aktive hemmelige nøkler

Tilbakekall og erstatt alle aktive nøkler som kan ha vært lagret i kildekode, logger, sikkerhetskopier, endepunktdata, containerbilder eller offentlig tilgjengelig infrastruktur. Ikke vent på tegn til svindel før en mulig eksponert nøkkel byttes.

2. Gå gjennom API- og betalingsaktivitet

Se etter ukjente API-kall, nye betalingslenker, test- eller uautoriserte belastninger, uventede refusjoner, endrede tillatelser og uvanlige IP-adresser. Ta vare på relevante logger slik at en tidslinje kan etableres.

3. Kontroller utbetalingene

Sjekk utbetalingsinnstillinger, tilknyttede bankkontodetaljer og mottakere for utbetalinger. Mistenkelige endringer bør meldes raskt til Stripe og relevante finansinstitusjoner, i tråd med virksomhetens rutiner for hendelseshåndtering og rapportering.

4. Bytt ut brede nøkler med begrensede nøkler

Bruk begrensede nøkler med bare de API-rettighetene hver tjeneste trenger. Skill mellom produksjon, utvikling og administrative roller i stedet for å bruke én bred hemmelighet i flere systemer.

5. Let i hele infrastrukturen

Søk i nåværende og historiske kodearkiver, Git-historikk, CI/CD-utdata, GitHub Actions-logger, .env-filer, containerlag, skylagring, dokumentasjon og sikkerhetskopier etter sk_live-verdier. Alle nøkler som blir funnet, bør tilbakekalles og erstattes – også når de ikke lenger finnes i den nyeste kodeversjonen.

6. Se på GitHub-skanning som ett sikkerhetslag

GitHub opplyser at hemmelighetsskanning kjører automatisk for offentlige arkiver. For private og interne arkiver som eies av organisasjoner, kreves GitHub Secret Protection på kvalifiserte abonnementer. Skanning kan heller ikke hente tilbake hemmeligheter som allerede er kopiert til logger, sikkerhetskopier, telemetri på endepunkter eller nedlastede arkiver.

Derfor bør skanning kombineres med sentral håndtering av hemmeligheter, kort levetid for nøkler, tilgangskontroller og kontinuerlig overvåking.

Hovedlærdommen

Rapporteringen dokumenterer ikke et innbrudd i Stripes egen infrastruktur. Den viser likevel hvor raskt en eksponert produksjonsnøkkel kan gi tilgang til kundedata og betalingsfunksjoner. For virksomheter som bruker Stripe, er god håndtering av egne legitimasjoner derfor like viktig som sikkerheten hos betalingsplattformen: Hold produksjonshemmeligheter ute av kode og logger, begrens rettighetene, roter nøklene raskt og undersøk alle uventede API- eller utbetalingshendelser.