Uitgelekte Stripe-sleutels zetten gegevens van 688.363 klanten op het spel

Onderzoekers zouden 650 actieve sk_live-geheime sleutels en negen beperkte sleutels hebben aangetroffen. Van de getroffen accounts konden er volgens de aangehaalde analyse 573 betalingen accepteren, 531 uitbetalingen uitvoeren en 519 beide mogelijkheden gebruiken.

Waarom één actieve sleutel al gevaarlijk kan zijn

Een geheime Stripe-sleutel is een API-inloggegeven, geen gewone identificatiecode. De precieze reikwijdte hangt af van de rechten van de sleutel en de configuratie van het handelaarsaccount. Een gestolen sleutel kan echter toegang geven tot accountgegevens en ongeoorloofde betalingsactiviteiten mogelijk maken.

Volgens de beschreven tests kon één actieve sleutel worden gebruikt om klantlijsten op te vragen, frauduleuze betaallinks aan te maken en testbetalingen uit te voeren. Mogelijke gevolgen zijn het verzamelen van klantgegevens, betalingsfraude, ongeoorloofde terugbetalingen, gerichte phishing en social engineering rond betalingen. Voor accounts met uitbetalingsrechten moeten bovendien de uitbetalingsinstellingen en bestemmingen extra worden gecontroleerd.

Het grootste praktische gevaar is de snelheid waarmee misbruik kan plaatsvinden. Een servergeheim dat uitlekt, kan een fout in het beheer van inloggegevens binnen korte tijd veranderen in een actief fraude- en incidentonderzoek — nog voordat een bedrijf ongebruikelijke activiteit opmerkt.

Waarom dit niet als een inbraak bij Stripe zelf werd beoordeeld

De beschikbare aanwijzingen suggereren dat aanvallers geldige handelaarscredentials gebruikten om via de legitieme Stripe-API gegevens op te vragen. Onderzoekers die de vrijgegeven bestanden offline bekeken, meldden dat de Stripe-achtige objecten en mappenstructuur overeenkwamen met exports uit API-eindpunten. Zij gebruikten de blootgestelde sleutels niet om in te loggen en kregen voor deze analyse geen toegang tot live omgevingen van handelaars.

Dat onderscheid is belangrijk. De vermoedelijke fout ligt dan niet bij de kernsystemen van Stripe, maar op plekken waar handelaars hun geheimen bewaren of onbedoeld blootstellen, zoals:

• Infostealer-malware op apparaten van ontwikkelaars of beheerders
• Openbare codeopslagplaatsen en oude Git-geschiedenis
• Openbare .env-bestanden en serverconfiguraties
• Cloudopslag, back-ups en containerlagen
• CI/CD-systemen en logs van GitHub Actions
• Verkeerd geconfigureerde servers of geautomatiseerde scans op blootgestelde variabelen

De oorspronkelijke diefstalroute van de 659 handelaarscredentials is niet vastgesteld. Dit zijn mogelijke blootstellingsroutes, geen bevestigde gezamenlijke oorzaak van de volledige dataset.

Een verwante publicatie en de kanttekening bij de aantallen

Hudson Rock koppelde een verwante publicatie op een forum aan dezelfde actor. Die release zou 669 leveranciersmappen en 1.033 gecompromitteerde API-sleutels hebben bevat en werd aangeboden als een bestand van 33 GB; de daadwerkelijke download zou kleiner zijn geweest. De actor beweerde daarnaast over ongeveer 20.000 extra gecompromitteerde Stripe-sleutels te beschikken en kondigde mogelijk nieuwe reeksen aan.

Deze cijfers mogen niet zonder meer bij elkaar worden opgeteld. Het verschil tussen 659 handelaarsaccounts, 669 leveranciersmappen en 1.033 sleutels kan te maken hebben met verschillende datasets, meerdere sleutels per account, dubbele bestanden of uiteenlopende telmethodes. Het aantal van 20.000 sleutels blijft een onbevestigde claim van de actor.

In welke landen zaten de meeste getroffen handelaars?

Volgens de beschikbare berichtgeving waren de Verenigde Staten, het Verenigd Koninkrijk en Frankrijk het sterkst vertegenwoordigd:

• Verenigde Staten: 212 handelaars
• Verenigd Koninkrijk: 81
• Frankrijk: 57
• Canada: 38
• Brazilië: 30
• Australië: 27

Deze verdeling beschrijft alleen de gemelde dataset. De volledige omvang van de blootstelling werd nog onderzocht.

Wat bedrijven die Stripe gebruiken nu moeten doen

1. Vervang alle mogelijk blootgestelde live-sleutels

Trek elke live geheime sleutel in die mogelijk in broncode, logs, back-ups, endpointtelemetrie, containerimages of openbare infrastructuur heeft gestaan en maak een nieuwe aan. Wacht niet op bewijs van fraude voordat je een mogelijk gelekte sleutel roteert.

2. Controleer API-activiteit en betalingshandelingen

Bekijk API- en beveiligingslogs op onbekende aanroepen, nieuwe betaallinks, test- of ongeautoriseerde betalingen, onverwachte terugbetalingen, wijzigingen in rechten en ongebruikelijke IP-adressen. Bewaar relevante logs, zodat een tijdlijn kan worden opgesteld.

3. Controleer de uitbetalingsinstellingen

Controleer gekoppelde bankrekeningen, uitbetalingsbestemmingen en andere payout-instellingen. Meld verdachte wijzigingen zo snel mogelijk bij Stripe en de betrokken financiële instellingen, volgens de toepasselijke procedures voor incidentrespons en rapportage.

4. Gebruik beperkte sleutels in plaats van brede credentials

Maak voor iedere dienst gebruik van restricted keys die alleen de noodzakelijke API-handelingen toestaan. Scheid productie, ontwikkeling en operationele rollen en voorkom dat één brede sleutel over meerdere applicaties wordt verspreid.

5. Zoek op alle plekken waar geheimen kunnen blijven bestaan

Doorzoek huidige en historische repositories, Git-geschiedenis, CI/CD-uitvoer, GitHub Actions-logs, .env-bestanden, containerlagen, cloudopslag, documentatie en back-ups op waarden die beginnen met sk_live. Trek iedere gevonden sleutel in en vervang deze, ook als hij niet meer in de huidige codeversie staat.

6. Zie GitHub-scanning als één beveiligingslaag

GitHub voert secret scanning automatisch uit voor openbare repositories. Voor organisatie-eigen private en interne repositories is GitHub Secret Protection nodig op daarvoor geschikte abonnementen. Zo’n scan kan bovendien geen geheimen terughalen die al in logs, back-ups, endpointtelemetrie of gedownloade archieven zijn terechtgekomen. Secret scanning moet daarom een aanvulling zijn op centraal geheimenbeheer, korte levensduren van credentials, toegangsbeperkingen en voortdurende monitoring.

De belangrijkste les voor handelaars

De duidelijkste conclusie is dat de beveiliging van een betaalplatform deels afhangt van hoe bedrijven hun eigen credentials beheren. De beschikbare berichtgeving bewijst geen inbraak in de infrastructuur van Stripe, maar laat wel zien hoe blootgestelde live API-sleutels toegang kunnen geven tot klantgegevens en betalingsfuncties. Behandel productiesleutels daarom als zeer gevoelige inloggegevens: houd ze uit code en logs, beperk hun rechten, roteer ze snel en onderzoek elke onverwachte API- of uitbetalingsactiviteit.