Lækkede Stripe-nøgler satte 688.363 kundeposter i fare

Forskerne rapporterede, at de fandt 650 aktive sk_live-hemmelige nøgler og ni begrænsede nøgler. Blandt de berørte konti kunne 573 modtage betalinger, 531 foretage udbetalinger, og 519 kunne begge dele, ifølge den analyse, som rapporteringen henviste til.

Hvorfor kan én aktiv nøgle være alvorlig?

En hemmelig Stripe-nøgle er en API-legitimationsoplysning – ikke blot et kontonavn eller en identifikator. Hvor meget adgang den giver, afhænger af nøglens rettigheder og virksomhedens opsætning. En kompromitteret nøgle kan dog give adgang til forhandlerens ressourcer og gøre uautoriserede betalingshandlinger mulige.

Test, der blev beskrevet i rapporteringen, viste, at én aktiv nøgle kunne bruges til at hente kundelister, oprette falske betalingslinks og gennemføre testbetalinger. Mulige konsekvenser omfattede masseudtræk af kundedata, betalingsmisbrug, uautoriserede tilbagebetalinger, målrettet phishing og betalingsrelateret social engineering. Konti med udbetalingsfunktioner havde desuden behov for at kontrollere udbetalingsindstillinger og modtageroplysninger.

Den praktiske risiko handler især om tempo. En lækket servernøgle kan på kort tid forvandle en fejl i håndteringen af hemmeligheder til en aktiv svindelsag, før virksomheden opdager den usædvanlige aktivitet.

Hvorfor blev det ikke klassificeret som et Stripe-brud?

De tilgængelige oplysninger tydede på, at angriberne brugte gyldige forhandlerlegitimationsoplysninger til at hente Stripe-data gennem legitim API-adgang. Forskere, der gennemgik de offentliggjorte filer offline, sagde, at Stripe-lignende objekter og mappestrukturer stemte overens med eksporter fra API-endepunkter. De loggede ikke ind med de lækkede nøgler og fik ikke adgang til forhandlernes aktive miljøer som led i gennemgangen.

Det er en vigtig forskel. Den peger på et sandsynligt kontrolsvigt hos de virksomheder, der opbevarede eller eksponerede hemmelighederne, snarere end i Stripes kernesystemer. Mulige eksponeringsveje omfatter:

• Infostealer-infektioner på udvikleres eller administratorers enheder
• Offentlige kodearkiver og historik i Git
• Eksponerede .env-filer og serverkonfigurationer
• Cloudlagring, sikkerhedskopier og containerlag
• CI/CD-systemer og GitHub Actions-logfiler
• Fejlkonfigurerede servere eller automatiserede scanninger efter eksponerede variabler

Den oprindelige tyverivej for de 659 forhandleres legitimationsoplysninger er ikke fastslået. Punkterne ovenfor er mulige eksponeringsruter – ikke en bekræftet fælles årsag til hele datasættet.

Et relateret udslip skaber forvirring om tallene

Hudson Rock koblede en relateret offentliggørelse på et forum til den samme aktør. Den blev beskrevet som omfattende 669 leverandørmapper og 1.033 kompromitterede API-nøgler med en annonceret størrelse på 33 GB. Den tilknyttede download skulle dog have været mindre. Aktøren hævdede desuden at have omkring 20.000 yderligere kompromitterede Stripe API-nøgler og antydede, at flere portioner kunne følge.

Tallene bør ikke lægges sammen til én verificeret total. Forskellene mellem 659 forhandlerkonti, 669 leverandørmapper og 1.033 nøgler kan skyldes forskellige datasæt, flere nøgler pr. konto, dubletter eller forskellige optællingsmetoder. Tallet på 20.000 nøgler er fortsat en ubekræftet påstand fra aktøren.

Her lå de fleste berørte forhandlere

De lande, der ifølge den tilgængelige rapportering havde flest berørte forhandlere, var:

• USA: 212 forhandlere
• Storbritannien: 81
• Frankrig: 57
• Canada: 38
• Brasilien: 30
• Australien: 27

Tallene viser den rapporterede geografiske fordeling og bør ses i sammenhæng med, at datasættets fulde omfang stadig blev undersøgt.

Hvad bør Stripe-virksomheder gøre nu?

1. Udskift aktive hemmelige nøgler

Tilbagekald og erstat alle aktive hemmelige nøgler, der kan have optrådt i kildekode, logfiler, sikkerhedskopier, endpoint-telemetri, container-images eller offentlig infrastruktur. Vent ikke på beviser for svindel, før en muligvis eksponeret nøgle udskiftes.

2. Gennemgå API- og betalingsaktivitet

Undersøg API- og sikkerhedslogge for ukendte kald, nye betalingslinks, testbetalinger eller uautoriserede betalinger, uventede tilbagebetalinger, ændringer i rettigheder og usædvanlige IP-adresser. Gem relevante logge, så en tidslinje kan etableres.

3. Kontrollér udbetalingsopsætningen

Gennemgå udbetalingsindstillinger, tilknyttede bankkonti og udbetalingsmodtagere. Mistænkelige ændringer bør straks eskaleres til Stripe og de relevante finansielle institutioner efter virksomhedens procedurer for hændelseshåndtering og rapportering.

4. Erstat brede nøgler med begrænsede nøgler

Brug begrænsede nøgler, der kun har de API-rettigheder, som den enkelte tjeneste faktisk behøver. Adskil produktionssystemer, udviklingsmiljøer og driftsroller i stedet for at dele én bred hemmelig nøgle mellem flere applikationer.

5. Søg alle steder, hvor hemmeligheder kan ligge gemt

Gennemsøg aktuelle og historiske kodearkiver, Git-historik, CI/CD-output, GitHub Actions-logge, .env-filer, containerlag, cloudlagring, dokumentation og sikkerhedskopier efter sk_live-værdier. Alle fundne legitimationsoplysninger bør tilbagekaldes og erstattes – også hvis de ikke længere findes i den aktuelle kodeversion.

6. Se GitHub-scanning som ét lag – ikke som fuld dækning

GitHub oplyser, at secret scanning automatisk kører for offentlige arkiver, mens private og interne arkiver, der ejes af organisationer, kræver GitHub Secret Protection på kvalificerede abonnementer. Scanning kan heller ikke hente hemmeligheder tilbage, hvis de allerede er kopieret til logge, sikkerhedskopier, endpoint-telemetri eller downloadede arkiver. Den bør derfor supplere – ikke erstatte – central håndtering af hemmeligheder, korte levetider for legitimationsoplysninger, adgangskontroller og løbende overvågning.

Den vigtigste læring for forhandlere

Sagen viser, at sikkerheden omkring en betalingsplatform også afhænger af virksomhedens egen håndtering af API-legitimationsoplysninger. Den tilgængelige rapportering dokumenterer ikke et brud på Stripes infrastruktur, men viser, hvordan eksponerede aktive API-nøgler kan åbne vejen til kundedata og betalingsmisbrug. Produktionshemmeligheder bør behandles som adgang til kritiske systemer: Hold dem ude af kode og logge, begræns deres rettigheder, udskift dem hurtigt, og undersøg enhver uventet API- eller udbetalingshændelse.