Les cartes de crédit sont vulnérables aux attaques de type brute force

• La PCI DSS limite le stockage et l’affichage des données de carte, mais même avec les seules informations autorisées comme le BIN, les 4 derniers chiffres et la date d’expiration, il reste possible de poursuivre des tentatives de paiement supplémentaires chez d’autres commerçants
• Depuis un compte compromis, l’attaquant a obtenu via la page 3D Secure de la banque la confirmation que la carte était utilisable, le nom de la banque, le numéro de carte masqué et la date d’expiration complète, puis a déclenché environ 6 heures plus tard des tentatives d’authentification chez plusieurs commerçants
• Le numéro de carte de paiement (PAN) suit une structure avec IIN, identifiant de compte et chiffre de contrôle Luhn ; si la réponse de la passerelle de paiement indique quelle valeur est erronée, il devient plus facile de deviner le PAN, la date d’expiration et le CVV
• La vitesse observée en test était de 6 essais par seconde, soit environ 2 par seconde et par API ; comme l’IP change via des proxys et que le numéro de carte change aussi en continu, il est difficile pour les commerçants de détecter un brute force
• L’attaquant a utilisé des commerçants bénéficiant d’une exception 3D Secure pour transférer l’intégralité de la limite abaissée vers un portefeuille électronique ; l’argent a été remboursé via chargeback, mais la limitation de débit CVC2 de la banque se limite à un blocage de quelques minutes

---

Ce que PCI DSS empêche, et ce qu’elle laisse possible

• La PCI DSS est le standard industriel qui définit les mesures minimales de sécurité nécessaires lorsqu’on traite des données bancaires sensibles comme les cartes de crédit ; elle limite le stockage et l’affichage afin que l’ensemble des informations ne soit pas exposé même si un compte est compromis ou si les données de carte sont transmises à un tiers
• Selon PCI DSS 4, les informations pouvant être affichées à l’écran ou sur un reçu sont le PAN masqué, le nom du titulaire, le code de service et la date d’expiration ; pour le PAN, le BIN et les 4 derniers chiffres peuvent être visibles
• Les informations qui ne peuvent pas être affichées sont limitées aux données de piste complètes, au code de vérification de la carte et au PIN/bloc PIN
• Les sites d’e-commerce comme les reçus papier peuvent être touchés par le même problème ; une exposition partielle des informations de carte peut provenir non seulement d’un compte compromis, mais aussi de reçus qui n’ont pas été détruits

Déroulement de l’incident

• La victime utilisait une carte de crédit virtuelle avec une limite plafonnée, avait activé la double authentification 3D Secure et n’enregistrait sa carte que chez des commerçants connus
• Après la compromission d’un ancien compte, un SMS de tentative d’achat est arrivé depuis un site où la carte était enregistrée ; la victime s’est immédiatement connectée, a changé le mot de passe, a vérifié si l’achat avait eu lieu, puis a fortement abaissé la limite de la carte virtuelle
• La carte n’a pas été totalement désactivée, car il était estimé que les informations complètes de la carte n’avaient pas été compromises
• Environ 6 heures après la compromission initiale, 3 ou 4 tentatives de SMS 3D Secure ont été observées chez plusieurs commerçants jamais utilisés ; elles ont toutes échoué, mais sont devenues un indice clé pour comprendre la méthode d’attaque
• Quelques minutes plus tard, pendant l’appel à la banque pour désactiver complètement la carte, l’attaquant a utilisé d’autres commerçants sans 3D Secure pour retirer en plusieurs paiements l’intégralité de la limite abaissée
• L’argent a été déplacé vers le portefeuille électronique d’une place de marché permettant le retrait en espèces, puis la victime a demandé un chargeback et a été remboursée par la banque

Informations obtenues par l’attaquant

• Depuis le compte compromis, l’attaquant a tenté un paiement, a consulté la page 3D Secure de la banque, puis a annulé la commande et quitté le site
• Ce processus lui a permis d’apprendre que la carte était toujours utilisable, ainsi que le nom de la banque, le numéro de carte masqué et la date d’expiration complète
• En général, pour finaliser normalement un paiement par carte, il faut le PAN complet à 16 chiffres, la date d’expiration, le numéro CVC2 et des informations comme le téléphone mobile utilisé pour 3D Secure
• Dans l’attaque réelle, une partie seulement de ces informations suffisait pour poursuivre des tentatives chez d’autres commerçants

Structure du PAN et possibilité de devinette

• Le numéro de carte de paiement (PAN) est l’identifiant de carte utilisé pour les cartes de crédit, cartes de débit, cartes prépayées et cartes cadeaux
• Le PAN suit un schéma de numérotation commun conforme à l’ISO/IEC 7812, avec la structure interne suivante
  • un Issuer Identification Number (IIN) de 6 ou 8 chiffres
  • un identifiant de compte individuel pouvant aller jusqu’à 12 chiffres
  • un chiffre de contrôle calculé avec l’algorithme de Luhn
• La banque de la victime n’autorisait pas un paiement avec le seul numéro de carte et exigeait aussi le PAN, la date d’expiration et le CVV
• Certaines banques et passerelles de paiement peuvent traiter un paiement avec le seul numéro de carte, ce qui était le point le plus difficile à croire pour la victime

Les conditions de brute force créées par les réponses de la passerelle de paiement

• La banque de la victime rejetait les paiements quand une valeur requise manquait ou était incorrecte, mais l’indiquait via des codes de réponse précisant quelle partie était erronée
• Exemples de réponses
  • « pas une carte de crédit valide »
  • « carte expirée »
  • « toutes les autres informations sont correctes, mais le CVV est erroné »
• De telles réponses peuvent permettre à un attaquant de distinguer quelles valeurs du numéro de carte, de la date d’expiration et du CVV sont correctes ou non
• Dans l’attaque réelle, l’attaquant testait à une cadence de 6 essais par seconde, soit environ 2 essais par seconde et par API
• Ce rythme est difficile à détecter côté commerçant, car l’IP d’origine change via des proxys, le numéro de carte n’est pas identique d’une tentative à l’autre en raison même du brute force, et la fréquence des requêtes reste très faible

Le rôle des commerçants en exception 3D Secure

• La banque dispose d’une liste de commerçants bénéficiant d’une exception 3D Secure ; ils sont considérés comme fiables par la banque et peuvent accepter des paiements et abonnements sans 3D Secure
• En cas de chargeback, ces commerçants en assument la responsabilité
• L’attaquant a utilisé des commerçants sans 3D Secure pour transférer, dans la limite autorisée par la carte, des fonds vers un portefeuille électronique

Réponse après coup et problèmes persistants

• L’argent a été rapidement remboursé via chargeback
• Il a été signalé au commerçant que son système de conversion des paiements par carte en espèces avait servi à des retraits non autorisés, mais le commerçant a répondu qu’il fallait voir cela avec la banque
• Il a aussi été signalé au site d’e-commerce qu’exposer 10 chiffres du numéro de carte avec la date d’expiration facilitait l’attaque, mais le site a refusé de reconnaître cela comme une vulnérabilité et a répondu que c’était un choix de conception délibéré conforme aux standards PCI DSS 3 et 4
• Les personnes qui créent des API de paiement ou travaillent dans l’industrie des paiements ne se sont pas dites surprises, et certains commerçants ont répondu qu’ils pouvaient effectuer des transactions même sans date d’expiration
• Après l’incident, l’acteur qui convertissait les paiements par carte en argent liquide ne traite plus cela sans 3D Secure
• La banque de la victime conserve toujours une limitation de débit relativement permissive contre le brute force du CVC2, avec au mieux un blocage temporaire de quelques minutes pour la carte concernée lorsqu’une limite est atteinte