Vue lecture

Quand personne ne vérifie la date d'expiration de votre CB

Trois chercheurs de l'université du Massachusetts à Amherst ont réussi à régler pour 3,19 dollars d'achats dans un supermarché avec une carte bancaire périmée !

Leur secret ?

Glisser une app maison entre la carte et le terminal qui trafique la date d'expiration de la carte.

En fait, leur montage relaie les échanges NFC et modifie au passage un champ que personne ne protège : la date d'expiration lue par le terminal. Leur papier s'appelle Zombie Cards Back Online , et a été présenté à USENIX Security 2026.

La mécanique tient en réalité à une bizarrerie du réseau Visa. Une carte annonce sa date d'expiration à deux endroits différents, et sur le kernel Visa, la date que le terminal consulte pour ses contrôles locaux n'est reliée à aucune signature. La banque, elle, regarde l'autre. Les deux devraient être liées cryptographiquement mais elles ne le sont pas.

Pire, ce kernel transmet à la banque un TVR entièrement à zéro. Le TVR, c'est le champ qui raconte ce que le terminal a vérifié et ce qui a coincé. Rempli de zéros, il ne raconte plus rien, du coup, la banque autorise une transaction sans savoir que les contrôles d'en face ont été contournés.

Reste que la portée est plus étroite que le tour de force le laisse croire. Sur cinq banques américaines testées, une seule a validé l'opération de bout en bout dans des conditions de laboratoire, permettant de payer jusqu'à 500 dollars. Une autre a laissé passer le terminal puis refusé côté banque. De leur côté, les kernels Mastercard, American Express et Discover, eux, ont rejeté les modifications.

Il faut aussi avoir la carte expirée à portée de NFC, et que la banque ait réémis la nouvelle avec le même numéro de compte, ce que les auteurs décrivent comme une pratique d'émetteurs américains.

Bref, c'est pas si simple et tous les essais ont eu lieu aux États-Unis donc rien ne dit non plus ce que ça donnerait sur un terminal français, où le sans contact plafonne de toute façon à 50 euros par paiement, 150 euros cumulés et 5 opérations avant que ça ne réclame le code. Puis de toute façon, le numéro de CB change intégralement à chaque renouvellement de carte, donc bon...

Six ans plus tôt, l'équipe de David Basin publiait The EMV Standard: Break, Fix, Verify , une application Android en relais sur du Visa sans contact, ce qui permettait de payer sans saisir de code. C'est vrai que les failles du paiement sans contact ne datent pas d'hier mais ce qui est neuf ici, c'est cette histoire de faiblesse au niveau de la date d'expiration.

Voilà, comme d'hab, Visa a été prévenu en mai 2025, relancé en décembre mais ni Visa ni les banques n'ont annoncé le moindre correctif pour le moment...

Source

  •  

GitLab - la faille qui a fait rouvrir une version morte

GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

  •  
❌