Vulnérabilité liée à l'algorithme de hachage MIGS

Avec l'avènement des cartes de crédit et d'Internet, les achats sont devenus beaucoup plus faciles et, comme on dit, plus sûrs. En quelques clics, le produit dont vous avez besoin est déjà en route vers votre domicile. Cependant, tous les systèmes ne sont pas idéaux, ou plutôt il n'y en a pas. Vous pouvez toujours trouver une sorte d'erreur, un écart qui permet aux attaquants de faire leur sale boulot. Aujourd'hui, je voudrais attirer votre attention sur l'étude d'un programmeur très talentueux, Yohanes Nugroho, qui a parlé des vulnérabilités du système MIGS.

Ce texte est une traduction des mots du chercheur en vulnérabilité Yohanes Nugroho lui-même. Passez un bon moment.

Vulnérabilité liée à l'algorithme de hachage MIGS

L'année dernière, j'ai découvert une erreur dans l'algorithme de hachage basé sur MD5 utilisé par MIGS (Mastercard Internet Gateway Service). Il vous a permis de modifier la taille de la transaction. L'entreprise m'a récompensé pour avoir découvert ce problème. La même année, le MIGS est passé à l'utilisation du HMAC-SHA256, mais il y avait quelques vulnérabilités.

Qu'est-ce que le MIGS?

Lorsque vous payez sur un site Web, ses propriétaires connectent généralement leur système à une passerelle de paiement intermédiaire (il y a une transition vers une autre page). Cette passerelle de paiement est ensuite connectée à plusieurs systèmes de paiement disponibles dans un pays particulier. Pour les cartes de crédit, de nombreuses passerelles se connectent à d'autres passerelles (dont l'une est MIGS), qui fonctionnent avec de nombreuses banques pour fournir 3DSecure.

Comment ça marche?

La séquence de paiement, si vous utilisez MIGS, ressemble généralement à ceci:

1. Vous sélectionnez un produit sur le site.
2. Entrez votre numéro de carte de crédit.
3. Le numéro de carte, la taille du paiement et d'autres paramètres sont signés et renvoyés au navigateur, qui génère automatiquement une demande POST à ​​la passerelle de paiement intermédiaire.
4. Cette passerelle convertit les informations dans un format pris en charge par MIGS, signe avec une clé MIGS et les renvoie au navigateur. Après quoi, le navigateur génère une autre requête POST au serveur MIGS lui-même.
5. Si 3DSecure n'est pas activé, cette étape est ignorée. Sinon, le MIGS transfère la demande à la banque qui a émis la carte. La banque demande OTP et génère du HTML, qui génère une requête POST pour le serveur MIGS.
6. MIGS renvoie les données signées au navigateur et crée une demande POST pour la passerelle de paiement intermédiaire.
7. Validation des données et signature par une passerelle de paiement intermédiaire. Si les données sont incorrectes, une page d'erreur est générée.
8. Sur la base de la réponse MIGS, la passerelle de paiement transmet l'état du paiement au vendeur.

Vulnérabilité dans l'algorithme de hachage MD5

Cette erreur est très simple. La méthode de hachage utilise la formule suivante:

MD5 (secret + données)

Mais il n'y a aucune vulnérabilité à l'extension de hachage (certaines vérifications ont été effectuées pour éviter cela). Les données sont formées de cette manière: tous les paramètres de requête commençant par vpc_ sont triés, après quoi les valeurs sont connectées sans séparation. Par exemple, nous avons les données suivantes:

Nom: Joe
Montant: 10000
Carte: 1234567890123456

vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456

Appliquer le tri:

vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe

Nous connectons les valeurs:

100001234567890123456Joe

Remarquez si je modifie les paramètres:

vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000

Appliquer le tri:

vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe

Nous connectons les valeurs:

100001234567890123456Joe

Cette valeur MD5 sera la même. En effet, lorsque les données sont transférées au MIGS, nous pouvons ajouter un paramètre supplémentaire après la taille du paiement pour supprimer le dernier chiffre, ou avant - pour supprimer le premier. Et vous pouvez payer 2 $ au lieu de 2000 pour un MacBook.

Les passerelles intermédiaires et les commerçants peuvent éviter cette vulnérabilité en vérifiant toujours si le montant du paiement retourné par MIGS correspond à ce qui a été demandé.

MasterCard m'a récompensé pour avoir identifié cette erreur avec une prime de 8500 $.

Vulnérabilité de hachage dans HMAC-SHA256

Le nouveau HMAC-SHA256 présente une vulnérabilité qui pourrait être exploitée si nous injections des valeurs incorrectes dans la passerelle de paiement intermédiaire. J'ai vérifié cette erreur sur l'une des passerelles de paiement (Fusion Payments). Ils m'ont payé un bonus de 500 $ pour cela. Cette vulnérabilité pourrait également affecter d'autres passerelles de paiement connectées au MIGS.

Dans la nouvelle version, des délimiteurs (&) entre les champs, des noms de champ (pas seulement des valeurs) ont été ajoutés et, bien sûr, HMAC-SHA256. Pour les mêmes données que précédemment, la ligne hachée ressemble à ceci:

Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe

Nous ne pouvons rien déplacer, tout dans ce plan est en ordre. Mais que faire si la valeur contient les caractères & ou = ou un autre?

Après avoir lu le document de référence d'intégration du client de paiement virtuel MiGS, j'ai trouvé:

"Remarque: La valeur dans toutes les paires nom / valeur, à des fins de hachage, ne doit PAS contenir de caractères URL"

Je me concentre sur PAS . Cela signifie que si nous avons les champs suivants:

Montant = 100
Carte = 1234
CVV = 555

Le hachage sera comme ceci: HMAC (Montant = 100 & Carte = 1234 & CVV = 555)

Et si les champs sont comme ça (en utilisant & et =):

Montant = 100 et carte = 1234
CVV = 555

Ce hachage ressemble à ceci: HMAC (Amount = 100 & Card = 1234 & CVV = 555)

De la même manière. Mais jusqu'à présent, pas un tel problème.

Bien sûr, je pensais qu'il pourrait y avoir un problème dans la documentation officielle, peut-être que les caractères URL devraient toujours être utilisés. Mais j'ai vérifié le comportement du serveur MIGS, tout était comme dans le document. Peut-être qu'ils ne veulent pas travailler avec un encodage différent (comme + au lieu de% 20).

Il semble qu'il ne devrait pas y avoir de problème, des valeurs incorrectes seront vérifiées par le MIGS et donneront une erreur (par exemple, la mauvaise taille de paiement sera rejetée).

Mais j'ai remarqué que dans certaines passerelles de paiement, au lieu de vérifier les données saisies côté serveur, elles signent et redirigent tout vers MIGS. Il est beaucoup plus facile de tester JavaScript côté client, de signer les données côté serveur, puis de laisser le MIGS décider si le numéro de carte est correct, si CVV doit être composé de 3 ou 4 chiffres, si la carte expire correctement, etc. La logique est la suivante: MIGS revérifiera les données et les améliorera.

Chez Fusion Payments, j'ai découvert que c'est ce qui se passe: ils vous permettent d'entrer n'importe quelle longueur de code CVV (la vérification a lieu uniquement en JavaScript), puis de signer la demande et de l'envoyer au MIGS.

Exploiter

Pour exploiter cette vulnérabilité, nous devons créer une chaîne qui sera la bonne requête et obtenir la bonne réponse du serveur MIGS. Nous n'avons pas besoin de communiquer avec le serveur MIGS, nous faisons simplement signer au client les données correctes.

Demande de base:

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999 & vpc_OrderInfo = vdchecfurecurecurecurecurur

Et la réponse de base du serveur sera comme ceci:

vpc_Message = Approuvé & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_Secure25Shec2525

Dans le cas de Fusion Payment, l'exploit est implémenté en implémentant vpc_CardSecurityCode (CVV)

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3DA & vpc_OrderInfo = COMMANDER Se & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

La passerelle client / paiement génère le hachage correct pour cette ligne.

Maintenant, nous pouvons entrer ces données dans le client lui-même (sans interagir avec le serveur MIGS de quelque manière que ce soit), mais nous allons les modifier un peu pour que le client reconnaisse les variables nécessaires (la plupart des clients vérifient uniquement vpc_TxnResponseCode et vpc_TransactionNo):

vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 & vpc_Message = Approuvé & vpc_OrderInfo = COMMANDER Se & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

Remarque:

Le hachage sera le même que pour les données précédentes.
Le client ignorera vpc_AccessCode et sa valeur.
Le client gérera vpc_TxnResponseCode, etc., en supposant que la transaction est correcte.

On peut dire qu'il s'agit d'une erreur client MIGS, mais la méthode de hachage utilisée par MasterCard permet à cette erreur d'exister. Si les valeurs étaient codées, cette vulnérabilité n'existerait pas.

Réponse du MIGS

MasterCard n'a pas répondu à ce bogue dans le HMAC-SHA256. J'ai contacté plusieurs personnes que j'avais précédemment contactées à propos d'une vulnérabilité antérieure. Il n'y a pas de réponse. Même se désinscrire dans le style de "nous le testons". Ils ont mon Facebook s'ils veulent me contacter (depuis la correspondance sur MD5).

Certains prétendent apparemment ne pas avoir vu mon rapport, mais j'ai mis un mot de passe sur la lettre. Il y avait au moins 3 vues de l'adresse IP MasterCard. Dans le même temps, ce ne sont pas des clics aléatoires sans lecture, car vous devez entrer consciemment le mot de passe. Je leur écris chaque semaine.

Je m'attendais à ce qu'ils avertissent tous ceux qui se connectent à leur système de vérifier et de filtrer les données intégrées.

Lacunes dans les passerelles de paiement

En outre, je tiens à dire: malgré le fait que les passerelles de paiement traitent de l'argent, elles ne sont pas aussi sécurisées qu'il n'y paraît. Lors de mes pentests (tests de pénétration), j'ai découvert plusieurs vulnérabilités dans les protocoles de paiement dans plusieurs passerelles intermédiaires. Malheureusement, je ne peux pas en dire les détails (si je dis "pentest", alors c'est quelque chose qui relève de l'accord de non-divulgation).

J'ai également trouvé des erreurs de mise en œuvre. Par exemple, les attaques par extension de hachage, XML, les erreurs de vérification de signature, etc. L'un des bogues les plus simples que j'ai trouvés dans Fusion Payments. Le premier bug que j'ai trouvé était: ils ne vérifient même pas les signatures du MIGS. Cela signifie que nous pouvons simplement modifier les données renvoyées par MIGS et marquer la transaction comme réussie. Cela signifie seulement changer un caractère: de F (échoué) à 0 (réussi).

Autrement dit, nous pouvons entrer n'importe quel numéro de carte, recevoir une réponse incorrecte du MIGS, la changer et soudain, le paiement devient un succès. Il s'agit d'une entreprise avec un budget de 20 millions d'euros et j'ai reçu 400 dollars de leur part. Ce n'est pas la seule passerelle de paiement avec une telle vulnérabilité, lors de mon pentest, j'ai trouvé cela dans d'autres passerelles. Malgré la petite récompense, Fusion Payments est actuellement la seule passerelle de paiement que j'ai contactée, ce qui est très clair dans son programme de récompense pour les bugs trouvés. Ils ont répondu très rapidement à mes messages et ont rapidement corrigé leurs bugs.

Conclusion

Les passerelles de paiement ne sont pas aussi sécurisées que vous le pensez. Avec des récompenses aussi faibles (et dans certains cas, j'ai reçu 0 $), je me demande combien de personnes ont déjà exploité ces vulnérabilités dans les passerelles de paiement.

Remarque du traducteur

De ma part, je voudrais ajouter quelques mots aux conclusions de l'auteur de l'étude. Tout d'abord, cette étude est un avertissement et un appel à la prudence pour les vendeurs, car les vulnérabilités constatées en font les victimes des intrus. Mais il existe de nombreux autres bugs qui peuvent nuire aux clients (titulaires de carte, utilisateurs de systèmes de paiement, etc.). Soyez prudent lorsque vous saisissez vos informations de facturation personnelles sur un site non vérifié. Mieux encore, ayez à votre disposition une carte bancaire distincte, sur laquelle il y aura exactement le montant dont vous avez besoin pour effectuer un achat sur Internet.

Avez-vous rencontré des bugs dans les systèmes de paiement, ou peut-être avez-vous même été victime de ces bugs? Partagez vos expériences, opinions et conseils sur la façon de vous protéger dans les commentaires. Passez une bonne journée et faites du shopping en toute sécurité.

Comme une publicité. Promotion! Obtenez maintenant jusqu'à 4 mois d'utilisation gratuite de VPS (KVM) avec des disques dédiés aux Pays-Bas et aux États-Unis (configurations de VPS (KVM) - E5-2650v4 (6 cœurs) / 10 Go DDR4 / 240 Go SSD ou 4 To HDD / 1 Gbit / s 10 To - 29 $ / mois et au-dessus, des options avec RAID1 et RAID10 sont disponibles) , un analogue à part entière de serveurs dédiés, lors d'une commande pour une période de 1 à 12 mois, les conditions de l'action sont ici, les abonnés existants peuvent obtenir 2 mois en bonus!

Comment construire l'infrastructure du bâtiment. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?