Pas le serveur de l’application
Les journaux des requêtes Stripe montrent que les factures n’ont pas été créées depuis le serveur qui héberge l’application.
En deux jours, environ 800 factures d’abonnement inconnues sont parties du compte Stripe d’une entreprise vers des destinataires qu’elle ne connaissait pas. Nous sommes intervenus en urgence, alors que nous n’avions pas la charge de son application.
Une entreprise qui facture ses clients avec Stripe découvre des factures qu’elle n’a jamais émises : des renouvellements d’abonnement de près de 500 dollars, adressés à des personnes inconnues. Les e-mails sont authentiques, envoyés par Stripe lui-même, au nom de l’entreprise.
Chaque facture contient un court message : un abonnement a été renouvelé, et pour l’annuler, il faut appeler un numéro de téléphone.
Les journaux des requêtes de l’API indiquent, pour chaque appel, d’où il vient et avec quel outil il a été fait.
Les journaux des requêtes Stripe montrent que les factures n’ont pas été créées depuis le serveur qui héberge l’application.
Les requêtes venaient d’une infrastructure cloud située aux États-Unis, sans lien avec le client.
Les appels utilisaient une bibliothèque officielle de l’API Stripe, et non un navigateur. Le script créait un client, une ligne de facture et une facture, puis l’envoyait aussitôt.
Aucun accès SSH suspect, aucun fichier sensible exposé par le serveur web (configuration, dépôt Git, sauvegardes), une racine web correctement configurée.
Conclusion : la clé secrète utilisée par l’application était entre les mains d’un tiers, qui l’utilisait depuis sa propre infrastructure. Restait à comprendre comment il l’avait obtenue.
Le compte Stripe ne servait pas à encaisser de l’argent. Une facture payée aurait crédité le compte du client, pas celui des fraudeurs. Il servait à rendre la fraude crédible.
Le message de la facture était écrit avec des homoglyphes : des lettres empruntées à d’autres alphabets, comme le cyrillique ou l’arménien, qui ressemblent aux lettres latines. Le texte se lit normalement, mais échappe à certains filtres de détection.
La clé compromise a été remplacée, ce qui a stoppé toute nouvelle utilisation par le tiers.
Équipe sécurité de Stripe saisie avec les identifiants des requêtes, factures frauduleuses annulées, destinataires prévenus, nettoyage complet des objets créés dans le compte.
La clé figurait dans des documents de spécifications techniques, transmis par le client à un trop grand nombre de partenaires.
Clé à droits restreints à la place de la clé secrète complète, mots de passe renouvelés.
Aucun paiement n’a été effectué. La fraude a été stoppée dès le remplacement de la clé, le compte a été nettoyé, les destinataires informés, et l’origine de la fuite identifiée.
La leçon principale ne tient pas au code : une clé d’API est un identifiant, comme un mot de passe. Elle n’a rien à faire dans un document, un e-mail ou une spécification, même transmis à des partenaires de confiance. Stripe le rappelle dans sa documentation : ne partagez pas vos clés par e-mail ou par un canal non chiffré.
Les journaux des requêtes de l’API montrent l’origine de chaque appel. Des requêtes qui ne viennent pas de vos serveurs, ou des objets que vous n’avez pas créés (factures, clients, abonnements), sont le signe qu’un tiers utilise votre clé.
Pas directement : un paiement sur une facture crédite votre compte. Dans ce cas, le compte servait à envoyer des e-mails authentiques pour attirer les victimes vers un faux support. Une clé secrète complète donne cependant un accès large au compte : elle doit être remplacée sans attendre.
Non. Une clé exposée doit être considérée comme compromise et remplacée. Retirer le document n’efface pas les copies déjà transmises.
Oui. Dans ce cas, nous sommes intervenus en urgence pour un client dont nous ne maintenions pas l’application.
Remplacez la clé sans attendre, puis contactez-nous : nous analysons les journaux, trouvons l’origine et fermons les accès. Voir aussi notre guide en cas de clé Stripe compromise, notre audit de sécurité et nos interventions d’urgence.