Chiavi segrete Stripe pubblicate online: esposti 688.363 record cliente

I record risalirebbero al periodo compreso tra gennaio 2022 e giugno 2026.

Il rischio non riguarda soltanto la riservatezza dei dati. Secondo i ricercatori, 519 dei 659 account potevano sia accettare pagamenti sia disporre pagamenti in uscita. Se le credenziali fossero rimaste valide, questa combinazione avrebbe potuto facilitare attività fraudolente o tentativi di dirottamento dei fondi.

La concentrazione maggiore di account colpiti sarebbe stata negli Stati Uniti, con 212, seguiti dal Regno Unito con 81 e dalla Francia con 57.

Le cifre non coincidono: perché

I numeri variano a seconda del rilascio e del metodo di conteggio. L’analisi di Hudson Rock relativa a una pubblicazione collegata descrive 669 cartelle di vendor, 1.033 chiavi API compromesse e un archivio dichiarato di 33 GB.

Questi dati non devono essere sommati automaticamente a quelli del dataset validato da altre analisi: potrebbero riferirsi a fasi diverse della pubblicazione, a criteri di verifica differenti o a copie non coincidenti dell’archivio.

Hudson Rock ha inoltre rilevato una discrepanza tra i 33 GB indicati nell’inserzione sul forum e i circa 2,37 GB effettivamente disponibili per il download. Il divario è compatibile con l’ipotesi che esistesse altro materiale non incluso nel primo rilascio, ma non la dimostra.

La dichiarazione secondo cui l’attore possiederebbe circa 20.000 ulteriori chiavi API Stripe destinate a pubblicazioni future non è stata verificata in modo indipendente.

Perché non sembra una violazione dei sistemi Stripe

Le informazioni disponibili indicano che gli aggressori potrebbero aver usato chiavi segrete rubate per effettuare normali richieste alle API di Stripe. In questo scenario, i dati sarebbero stati estratti utilizzando credenziali autorizzate ad accedere ai singoli account merchant, non sfruttando una falla nei sistemi centrali della piattaforma. I ricercatori non hanno riferito prove di una compromissione dell’infrastruttura core di Stripe.

Le possibili origini delle chiavi esposte includono:

• log raccolti da infostealer, cioè malware che sottraggono credenziali;
• commit in repository pubblici;
• file .env esposti;
• backup non adeguatamente protetti;
• log delle pipeline CI/CD;
• server web configurati in modo errato;
• scansioni automatizzate alla ricerca di variabili d’ambiente e altri segreti mal protetti.

Al momento dei rilievi, i ricercatori non avevano collegato un’infezione da infostealer ai domini dei merchant specificamente presenti nel dataset. L’origine precisa delle credenziali rimane quindi irrisolta.

La distinzione è importante anche per la risposta all’incidente. Una violazione dell’infrastruttura Stripe implicherebbe un evento di sicurezza centralizzato; l’esposizione delle chiavi dei merchant indica invece molte credenziali separate, sottratte e poi utilizzate per operare sugli account a cui davano accesso.

Cosa si poteva fare con una sola chiave attiva

I ricercatori hanno riferito che una singola chiave attiva era sufficiente per consultare l’elenco clienti di un merchant, creare un Payment Link fraudolento ed effettuare un addebito di prova entro 17 ore.

La dimostrazione spiega perché una chiave segreta live, soprattutto se dotata di autorizzazioni ampie, debba essere trattata come un incidente immediato di sicurezza dell’account. Se la chiave consente già l’accesso ai dati e alle funzioni di pagamento, l’attaccante non deve necessariamente penetrare nei sistemi di Stripe.

A seconda dei permessi e della configurazione del merchant, l’accesso non autorizzato potrebbe esporre informazioni sui pagamenti o consentire operazioni relative a link di pagamento, addebiti, rimborsi e pagamenti in uscita. Il dataset includeva diverse di queste categorie, ma le fonti disponibili non dimostrano che ogni account elencato abbia subito attività fraudolente.

Il limite della scansione dei segreti su GitHub

Il caso mostra perché controllare soltanto i repository pubblici non basta a proteggere le credenziali di pagamento. I ricercatori hanno indicato come possibili punti di esposizione anche i log di GitHub Actions, gli artefatti storici, i file .env pubblici, i backup e i server configurati erroneamente. Questi elementi possono sfuggire a una semplice scansione del repository.

Un’analisi separata ha riferito di aver individuato oltre 50.000 segreti Stripe tra codice pubblico, log di GitHub Actions e server configurati in modo errato. Il dato descrive il problema generale della scoperta di credenziali esposte e non significa che tutte quelle chiavi facessero parte del dataset pubblicato il 18 agosto.

Per le aziende, la conseguenza pratica è chiara: eliminare un segreto dal repository attuale non lo rende automaticamente sicuro. Copie della chiave possono restare nella cronologia dei commit, nei log di build, negli artefatti, nei backup o nei sistemi già distribuiti.

Cosa devono fare subito i merchant Stripe

1. Revocare o ruotare immediatamente le chiavi segrete live potenzialmente esposte. Eliminare un file o una voce dal repository non invalida la chiave.
2. Esaminare i log delle API e dell’account Stripe alla ricerca di indirizzi IP sconosciuti, accessi agli elenchi clienti, esportazioni di dati, creazione di Payment Link, tentativi di pagamento, rimborsi e attività di payout.
3. Verificare le coordinate bancarie dei pagamenti in uscita e le modifiche recenti alle relative impostazioni. Ove necessario, aumentare temporaneamente il monitoraggio o i controlli sui trasferimenti.
4. Sostituire le chiavi con privilegi ampi con chiavi limitate, autorizzate soltanto a eseguire le operazioni necessarie all’applicazione.
5. Conservare i segreti in un sistema di gestione dedicato e rimuoverli dal codice sorgente, dai file di ambiente, dai log e dai backup non protetti.
6. Cercare nelle vecchie versioni dei repository, nei log CI/CD, negli artefatti, nei server e nei backup, non soltanto nel codice pubblico più recente.

Le evidenze disponibili descrivono una seria esposizione di credenziali merchant, con un rischio rilevante per dati dei clienti e operazioni di pagamento. Non consentono però di affermare che l’infrastruttura centrale di Stripe sia stata violata. Anche i conteggi devono essere letti come stime specifiche dei diversi dataset: le discrepanze tra 659 e 669 merchant e tra 650 e 1.033 chiavi riflettono probabilmente rilasci o criteri di validazione differenti.