Obtention d’un shell root sur un terminal de carte bancaire

 (stefan-gloor.ch)
4 points par GN⁺ 2025-06-02 | 1 commentaires | Partager sur WhatsApp
  • Après démontage et analyse du firmware d’un terminal de paiement Worldline Yomani XR utilisé en Suisse, il a été possible d’obtenir un shell root en saisissant simplement root sur une console série accessible via une trappe à l’arrière
  • Le terminal disposait de protections anti-tamper détectant l’ouverture du boîtier, la perte de contact entre PCB, la coupure de pistes en zigzag et l’endommagement du PCB flexible autour du lecteur de carte, mais l’exposition du port de debug constituait une voie d’attaque distincte
  • Le firmware extrait de la flash embarquée contenait un système de fichiers non chiffré et fonctionnait avec un noyau Linux 3.6, Buildroot 2010.02, BusyBox, uClibc et un bootloader personnalisé Booter v1.7
  • Les fonctions de sécurité comme la carte, le PIN, l’écran et le clavier semblent être prises en charge par un processeur séparé mp1 et par une image mp1.img chiffrée et signée ; aucun indice n’a montré qu’elles étaient directement accessibles depuis le Linux mp2
  • Les versions de firmware vulnérables n’ont pas été déterminées et certains appareils avaient la connexion root désactivée, mais dans un contexte où quelqu’un peut monopoliser physiquement le terminal pendant un court moment, une surface d’attaque inutilement importante subsiste

Worldline Yomani XR analysé

  • L’objet de l’analyse était un terminal de paiement Worldline Yomani XR, largement utilisé en Suisse
  • Après le démarrage, l’examen de l’interface utilisateur et un scan des ports n’ayant rien révélé de notable, l’analyse s’est poursuivie par un démontage matériel
  • L’intérieur est composé de plusieurs PCB
    • Une petite carte pour les connecteurs externes
    • La carte principale
    • Une carte verticale équipée du slot pour carte
  • Le SoC principal semble être un ASIC personnalisé dual-core Arm, désigné dans le firmware par le nom de code “Samoa II”
  • D’après la documentation de Worldline, cette puce correspond à un ASIC personnalisé et non à une puce du commerce rebadgée
  • À côté du SoC se trouvent une petite flash externe et de la RAM

Architecture de protection anti-tamper matérielle

  • Aucun interrupteur classique de détection d’ouverture du boîtier n’a été trouvé ; à la place, le board-to-board interconnect lui-même servait de mécanisme de détection d’ouverture
  • Entre les cartes se trouve un Zebra strip sensible à la pression, qui nécessite que les cartes soient fermement vissées pour maintenir le contact
    • Le simple fait de desserrer certaines vis peut rompre le contact et déclencher un événement de tamper
    • Comme la détection doit fonctionner même lorsque l’alimentation est débranchée, une pile bouton est utilisée
  • Les zones sensibles du PCB sont couvertes par des pistes de détection anti-tamper en zigzag
    • Une intrusion physique coupant ne serait-ce qu’une piste de cuivre peut déclencher la détection de tamper
  • Le slot pour carte se trouve dans un boîtier interne séparé, et le PCB flexible qui l’entoure joue un rôle de protection anti-tamper
  • Après remontage, le terminal n’affichait plus qu’un grand écran rouge “TAMPER DETECTED” et, dans ce mode, semblait ne pas réagir aux entrées externes

Extraction de la flash et récupération du système de fichiers

  • L’exploration à l’exécution étant bloquée, la puce flash embarquée a été dessoudée et câblée afin d’en dumper le contenu
  • Contrairement aux attentes, le dump n’était pas globalement chiffré
  • La flash utilisait une disposition ECC inhabituelle
    • Ce n’était pas une configuration standard avec payload de 2048 octets + 64 octets ECC/spare
    • La structure comportait 3 chunks de données de 694 octets, chacun suivi de 10 octets ECC
    • Les 16 derniers octets de la spare area semblaient correspondre aux métadonnées du système de fichiers YAFFS2
  • La zone de métadonnées étant plus petite que dans un YAFFS2 classique, il a fallu patcher le système de fichiers pour prendre en charge une structure de métadonnées plus compacte
  • Après avoir implémenté un lecteur de système de fichiers compatible, le contenu du système de fichiers a été extrait avec succès

Un système Linux ancien

  • Le système de fichiers extrait a confirmé que le terminal exécutait Linux
  • Le système contenait des composants anciens
    • Linux kernel 3.6
    • Buildroot 2010.02
    • Build de février 2023
    • Bootloader personnalisé Booter v1.7
    • Scripts init, BusyBox, uClibc
    • libcrypt 0.9.26
  • Il n’a pas été possible de déterminer à quel point la version du firmware dumpé était récente, mais elle doit correspondre à un firmware publié après février 2023

Shell root sans mot de passe

  • Lorsque la puce flash a été recâblée, le terminal a redémarré tout en affichant le message de tamper
  • Pour consulter les logs de démarrage Linux, la zone autour du connecteur de debug a été examinée avec un analyseur logique, et de l’activité a été détectée sur une pastille d’un connecteur de debug non peuplé
  • Sur la console série apparaissaient les logs de démarrage Linux ainsi qu’une invite de connexion
    • Les logs de démarrage indiquaient “Reset reason: Tamper”
    • D’autres logs mentionnaient aussi dropbear is not present, la vérification de mise à jour du firmware et le démarrage d’un démon de monitoring applicatif
    • À la fin, une invite samoa login: était affichée
  • En saisissant root comme identifiant, une invite de shell ~ # est apparue sans mot de passe
  • Cet accès ne nécessitait ni chaîne d’exploits ni cassage de mot de passe par brute force

Port de debug accessible de l’extérieur

  • L’accès au shell root n’était pas limité aux cas où le terminal était ouvert
  • Le port série était accessible de l’extérieur via une petite trappe à l’arrière du terminal
  • Il était possible de se connecter au connecteur de debug sans ouvrir le terminal ni déclencher la protection anti-tamper
  • Le scénario consistant à monopoliser brièvement le terminal, se connecter au port série, s’authentifier, déposer un malware puis repartir a été jugé possible

Séparation des rôles entre processeur sécurisé et Linux

  • Le shell root exposé ne signifie pas pour autant un accès immédiat aux données de carte ou de PIN
  • Le système Linux ne constitue qu’une partie de l’architecture, et aucun élément n’a montré que l’écran, le clavier ou le lecteur de carte étaient directement accessibles depuis Linux
  • Même l’affichage semblait ne pas être géré directement par un driver framebuffer, mais plutôt par transmission de chaînes de caractères au binaire display_tool, qui envoyait ensuite des messages inter-processeurs
  • Les fonctions liées à la sécurité, comme la carte, la saisie du PIN et l’affichage à l’écran, semblent être prises en charge par un processeur séparé mp1
  • Linux, exécuté sur le second processeur mp2, est chargé du réseau, des mises à jour et de la logique métier

Flux de démarrage et image sécurisée

  • Le cœur Linux semble toujours démarrer, indépendamment de l’état de tamper
  • Ensuite, Linux charge en mémoire loadercode, le bootloader sécurisé
  • loadercode vérifie si la protection anti-tamper a été déclenchée
    • Si un tamper est détecté, il affiche un écran rouge
    • En l’absence de problème, il démarre la véritable image sécurisée, mp1.img
  • mp1.img se trouve dans le système de fichiers Linux, mais semble être chiffrée et signée par deux entités
  • L’image sécurisée qui gère la carte, l’écran et le clavier était correctement chiffrée et signée

Calendrier de divulgation et incertitudes restantes

  • Le calendrier de divulgation a été consigné comme suit
    • 14 novembre 2024 : découverte du shell root
    • 15 novembre 2024 : signalement au fabricant et notification d’une divulgation prévue 90 jours plus tard
    • 18 novembre 2024 : le fabricant confirme la réception du rapport
    • 1er juin 2025 : publication
  • Le shell root exposé représente une surface d’attaque inutilement importante, mais aucun élément n’a montré que des données sensibles comme les informations de carte pouvaient être compromises par cette voie
  • Les versions de firmware vulnérables n’ont pas été déterminées
  • Pendant la recherche, des appareils avec la connexion root désactivée ont également été trouvés
  • Il n’a pas été possible de vérifier à quel moment cette fonctionnalité de debug a été intégrée au firmware de production, ni si le fabricant l’avait déjà découverte et corrigée en interne

À lire aussi

1 commentaires

 
GN⁺ 2025-06-02
Avis sur Hacker News

  • Il est possible de créer de fausses transactions par carte de débit/crédit avec un lecteur de carte USB à 2 dollars
    Les spécifications sont entièrement publiques et le protocole est également documenté. De mémoire, le PDF fait dans les 5 000 pages, donc c’est très pénible à lire
    Mais pour valider cette transaction, il faut l’envoyer à la banque via Internet, et là des organismes fédéraux / le FBI ou équivalent peuvent venir vous rendre visite
    Le lecteur de carte lui-même n’a pratiquement pas de vraie protection ; la plupart du temps, c’est juste un petit Linux avec de mauvais mots de passe. La protection vient du contrat entre le commerçant et la banque, ainsi que de la réglementation

    • Dire qu’il n’y a pas de protection dans le lecteur de carte n’est pas exact. Seuls des binaires signés sont exécutés, le système de fichiers exécutable est en lecture seule, et le système de fichiers de données est monté avec noexec
      La connexion root est désactivée, busybox est utilisé avec beaucoup de fonctionnalités retirées, et les clés sont chargées depuis une zone sécurisée au démarrage. L’injection de la clé maître n’est possible qu’au chargement en usine, le démarrage lui-même est aussi sécurisé dans une certaine mesure, et si une altération est détectée, la puce est vidée
      Bien sûr, s’il s’agit d’un terminal Android bon marché importé d’Asie et non certifié EMV, il y a de fortes chances qu’il ait un Linux standard avec un système de fichiers racine en lecture/écriture, une connexion root, voire sudo activé pour l’utilisateur qui exécute l’application. Il peut aussi ne pas avoir de détection d’altération, le cast de l’écran peut ne pas être verrouillé, des ports peuvent être ouverts, et busybox peut être presque complet
      Pour avoir développé pendant plusieurs années des applications EMV d’acquisition carte, et en faire encore occasionnellement, même le mode développement exige que le fournisseur fournisse un ID développeur, et l’ensemble est assez solidement verrouillé
    • La partie disant que les contrats et la réglementation entre le commerçant et la banque sont au cœur de la protection est exacte
      C’est aussi pour cela que les théories du complot du type « se balader avec un lecteur de carte portable pour voler de l’argent sur des cartes sans contact » sont fausses. On peut créer ce genre de transaction, mais le problème est ce qui se passe ensuite et la configuration nécessaire en amont
      Il n’est même pas certain qu’on puisse retirer l’argent avant d’être repéré et bloqué. Aujourd’hui, beaucoup de gens activent les notifications push de transaction, donc je pense que c’est encore plus difficile
    • Ce n’est pas vrai. Les terminaux commerçants intègrent du matériel sécurisé qui stocke les clés des banques et des réseaux de cartes
      Si ces clés fuitent, quelqu’un peut se faire passer pour une transaction légitime
    • Ce qui m’inquiète davantage, c’est qu’un lecteur de carte sur le terrain soit compromis et permette de lire des informations de carte réelles mises en cache ou stockées, ou qu’un malware d’interception soit installé
      Dans ce cas précis, cela semble difficile voire impossible, mais c’est pour cela que la recherche dans ce domaine a du sens
    • Peux-tu expliquer un peu plus en détail la partie « on peut créer de fausses transactions par carte de débit/crédit avec un lecteur de carte USB à 2 dollars » ? Je ne veux pas dire « apprends-moi comment faire »

  • Je ne saurais pas quoi regarder, mais j’ai été tenté d’ouvrir un des lecteurs Stripe M2 que j’ai pour voir l’intérieur
    Le problème, c’est que sur 36 lecteurs achetés, 7 sont « morts ». Deux ne tiennent plus la charge, un ne parvient pas à scanner le NFC, et quatre affichent « tampered ». À première vue, le taux de perte est mauvais, mais il faut regarder la fréquence d’utilisation et l’âge pour avoir une vue d’ensemble
    Or la réponse est encore pire. Les appareils ont entre 1 et 3 ans, et le nombre total de jours d’utilisation est au maximum de 9. Autrement dit, après seulement 9 jours d’utilisation au total, 7 appareils sur 36 sont tombés en panne d’une manière ou d’une autre. Lors des déplacements, ils sont tous rangés dans une valise rigide avec inserts en mousse, avec un emplacement séparé pour chaque lecteur
    Je n’aime donc pas beaucoup le lecteur M2, mais cela reste la meilleure option pour moi
    [0] Pour ajouter le contexte, notre entreprise gère les paiements de festivals. Nous nous déplaçons sur les lieux des événements, traitons les paiements en personne avec des iPad et des lecteurs M2, et la plupart des paiements se font sur le web / dans l’app. C’est pourquoi il y a si peu de « jours d’utilisation » sur 3 ans

    • Il vaut mieux les charger avant de les stocker jusqu’au prochain événement. La plupart des batteries n’aiment pas rester longtemps avec un faible niveau de charge
      Et il est très probable que la détection d’altération ait besoin d’une batterie en bon état de fonctionnement

  • Il est possible que le sceau d’altération déclenche l’ouverture d’un shell root
    Autrement dit, le système pourrait être soit dans un mode sécurisé disposant des clés cryptographiques nécessaires à son fonctionnement, soit dans un mode non sécurisé avec un shell root ouvert pour le débogage et l’analyse des pannes, mais avec suppression des clés privées importantes lors de cette transition

    • C’est aussi ce que j’ai supposé. Peut-être qu’il est même possible de flasher de nouvelles clés pour rendre l’appareil réutilisable
      Je me demande s’il est possible de se procurer un terminal. S’ils sont en train d’être remplacés et retirés, trouver de l’occasion ne serait peut-être pas si difficile

  • Pour ceux qui s’emballent facilement, il est indiqué que « le shell root exposé ne semble pas représenter un risque aussi important qu’on le craignait initialement. Nous n’avons trouvé aucune preuve que des données sensibles comme les informations de carte puissent être compromises de cette façon »
    Cela reste malgré tout une bonne lecture pour un architecte sécurité

    • Avoir un accès physique au terminal, obtenir les droits root, et malgré tout ne pas pouvoir lire les numéros de carte bancaire, c’est très suspect
      En sécurité, l’accès physique — et, dans une moindre mesure, l’accès root — revient pratiquement à une compromission réussie

  • Si le Linux compromis décide quoi charger entre le code du « mode compromis » et le système de sécurité mp1, cela semble être une piste à explorer
    Le bootloader lui-même est censé être sûr, mais s’il est chargé dans un environnement compromis selon l’endroit où il s’exécute réellement, cela peut ne pas vouloir dire grand-chose
    On pourrait considérer le coprocesseur comme une sorte de Secure Enclave, mais le fait que Linux puisse charger et exécuter un bootloader séparé est préoccupant

    • Il ne peut pas charger de bootloader séparé. J’ai essayé de modifier le bootloader « sécurisé » appelé loadercode, mais il n’a pas démarré
      J’en déduis donc qu’un tiers, probablement la ROM de démarrage, le vérifie
      En outre, Linux semble toujours charger loadercode et mp1.img, quel que soit l’état d’altération. Le chemin de code différent selon l’état d’altération semble être choisi à l’intérieur de loadercode, qui est protégé en intégrité

  • Si vous voulez le mode facile, il suffit de regarder les terminaux de paiement basés sur Android qui sortent ces temps-ci
    D’autant plus qu’on saisit le PIN directement à l’écran, il y a de bonnes chances que ce soit beaucoup plus gratifiant

    • Le contrôleur tactile est généralement relié à un multiplexeur piloté par un processeur sécurisé
      Lors de la saisie de données sensibles comme un PIN ou un PAN, la sortie du contrôleur tactile contourne le système d’exploitation de la famille Android chargé de l’interface graphique et est routée directement vers le processeur sécurisé
    • Même si les données du PIN sont affichées sur le pavé tactile, elles restent chiffrées et utilisent une interface utilisateur contrôlée par un firmware exécuté dans une zone de confiance
      Les applications intermédiaires accessibles dans ce type d’attaque ne peuvent donc pas voir le PIN
    • On pourrait ainsi obtenir le PIN assez facilement, mais si les éléments importants sont conçus de la même manière pour être délégués au coprocesseur de sécurité, il n’y a toujours pas grand-chose à faire avec la carte
      Les cartes modernes effectuent beaucoup d’opérations cryptographiques en interne pour empêcher ce genre d’attaque
      Cette attaque ne fonctionnerait sans doute que sur un terminal dont seul le lecteur de carte magnétique reste utilisable parmi les options de paiement ; or un tel terminal devrait déjà déclencher tous les signaux d’alerte au skimmer bien avant l’affichage de l’invite de PIN
    • Je ne sais pas quels terminaux Android sont utilisés selon les régions, mais en Inde ils semblent tourner sous Android Oreo. Le support a pris fin en janvier 2021

  • Excellent. J’aime réfléchir à des façons de contourner et d’exploiter ce genre de restrictions matérielles étendues de protection contre la falsification, mais j’avais toujours pensé qu’une fois déclenchées, la partie était terminée
    Or ce n’est pas forcément le cas, et il restait encore beaucoup d’aspects intéressants à examiner. Cela dit, il est bien sûr normal que la partie sécurité soit correctement désactivée. Sinon, j’aurais perdu toute confiance dans les concepteurs

    • Pour le processeur renforcé, cela peut toujours être vrai. L’article original précise aussi que ce n’est pas cette partie qui a été compromise
      Seules des chaînes de texte sont transmises à un binaire appelé display_tool, qui semble envoyer des messages entre processeurs. Même chose pour le clavier et le lecteur de carte. Je n’ai trouvé aucune preuve que ces périphériques soient directement accessibles depuis Linux
      À la place, un processeur totalement séparé, appelé mp1, semble gérer les tâches « sécurisées » comme le traitement des cartes, la saisie du PIN et l’affichage d’informations à l’écran. Le Linux « non sécurisé » qui tourne sur un second processeur, mp2, ne gère que le réseau, les mises à jour et la logique métier
    • À la lecture de la description, on aurait pu croire que la partie Linux jouait un rôle dans le traitement des événements de falsification
      J’espère tout de même que l’architecture se contente de lui permettre de voir qu’une falsification a eu lieu. Sinon, on pourrait d’abord obtenir un shell root, puis avoir l’occasion d’empêcher l’événement de falsification de provoquer la suppression des clés de sécurité

  • En lisant tout ce qui concerne la détection de falsification sur l’appareil, je me suis demandé quelle serait la méthode la plus simple pour déclencher le mode de falsification
    Après tout, si l’on peut mettre seulement quelques-uns de ces appareils dans cet état, cela peut devenir une attaque par déni de service efficace contre un magasin où la plupart, voire la totalité, des paiements passent par ces terminaux

    • Le faire tomber par terre ou verser de l’eau dessus

  • C’est intéressant d’examiner ce genre d’appareil, mais je ne comprends pas pourquoi l’ouvrir immédiatement et déclencher l’état de falsification. Ils ne savaient pas que la plupart des lecteurs avaient ce genre de mécanisme ?
    Les tests réellement effectués en état de falsification n’ont peut-être aucun sens. Il est possible que l’appareil ouvre un shell lorsqu’il passe en état de falsification à des fins d’initialisation
    À première vue, ouvrir l’appareil semble être quelque chose à tenter en dernier

    • J’ai d’abord eu l’impression qu’il fallait que je comprenne ce que j’avais entre les mains : le matériel, le SoC utilisé, les interfaces, la flash, etc.
      Sinon, on est vraiment dans le noir. Bien sûr, avec le recul, j’aurais pu simplement me connecter au connecteur de debug et m’arrêter là
      Et j’ai aussi obtenu un shell sur un second appareil qui n’avait pas été falsifié

  • Ce genre d’appareil est partout en Europe. Je ne sais pas pour la Suisse, mais dans une bonne partie de l’Europe que je connais, les gens ne possèdent pas vraiment de cartes de crédit, ou ne les utilisent pas beaucoup
    J’appellerais cela un POS, c’est-à-dire un système de point de vente. Ce type d’appareil peut lire toutes sortes de cartes. Quoi qu’il en soit, bon article

    • En réalité, on les utilise beaucoup. Je n’aime pas devoir emporter toutes ces cartes dans mon portefeuille. J’ai déjà, pour diverses raisons, plein de cartes qui ne servent pas au paiement, donc je n’ai même plus la place d’y mettre une carte de débit ou autre
      Je ne vois pas non plus l’intérêt de mettre encore plus de choses dans un téléphone ou une smartwatch. Je préfère les montres mécaniques, et perdre mon téléphone serait déjà une catastrophe suffisante du point de vue de la vie privée. Bien sûr, ce n’est que mon cas