Obtention d’un shell root sur un terminal de carte bancaire
(stefan-gloor.ch)- Une tentative de reverse engineering a été menée sur le terminal de carte bancaire Worldline Yomani XR dans le cadre d’une recherche en sécurité
- Lors du démontage interne, il a été constaté que la fonction de détection d’intrusion physique était bien implémentée, mais qu’un shell root était exposé côté logiciel sur un port série externe
- Le dessoudage de la mémoire, l’extraction du firmware et son analyse ont permis d’identifier une architecture basée sur un noyau Linux 3.6 ainsi que des composants très anciens
- Il a été démontré qu’il était possible d’obtenir facilement les privilèges root et d’installer du code malveillant via le port console série, sans démonter l’appareil
- Toutes les opérations critiques liées au paiement et à l’authentification sont réalisées par un processeur de sécurité distinct, ce qui limite fortement le risque réel d’exposition de données sensibles
Vue d’ensemble du projet
- Ce projet se concentre sur le reverse engineering du modèle Worldline Yomani XR à des fins de recherche en sécurité sur les terminaux de paiement
- Largement utilisé dans toute la Suisse, ce modèle est aujourd’hui arrêté, mais reste encore en service dans de grandes enseignes comme dans de petits commerces
Premières observations et démontage matériel
- Après une enquête de base — exploration de l’interface utilisateur, scan des ports, etc. — le démontage matériel a commencé
- Plusieurs PCB, un boîtier bien conçu, ainsi qu’un processeur Arm double cœur basé sur un ASIC personnalisé témoignent d’un niveau de sécurité matérielle important
- Le SoC principal est un ASIC dédié au nom de code Samoa II, accompagné de mémoire flash et de RAM externes
Détection d’intrusion et protection contre le sabotage
- Même sans ouvrir le boîtier, un mauvais contact des connexions de carte à détection de pression (Zebra strip) ou un simple desserrage de vis suffit à déclencher un événement d’intrusion
- La détection reste active grâce à la batterie, même en cas de coupure d’alimentation
- Sur le PCB principal, des pistes en zigzag, ainsi qu’un PCB flexible enveloppant le lecteur de carte, permettent de détecter toute détérioration comme une tentative d’intrusion
- Après un démontage momentané puis un remontage, l’appareil n’affiche plus qu’un écran rouge « TAMPER DETECTED » et ne répond plus aux entrées externes en raison de la détection d’intrusion
Extraction du firmware par chip-off
- La mémoire flash embarquée a été dessoudée puis connectée directement pour extraire le firmware
- Les données n’étaient pas chiffrées, mais une structure ECC particulière et l’agencement des métadonnées du système de fichiers YAFFS2 ont été observés
- Un lecteur de système de fichiers a été implémenté afin d’obtenir la liste complète des fichiers
- Le système utilise un noyau 3.6 basé sur Buildroot version 2010, avec uClibc, busybox et de nombreuses bibliothèques anciennes
Découverte fortuite du shell root
- Après l’analyse du firmware, la mémoire flash a été reconnectée, puis les lignes de la console série ont été identifiées et les signaux capturés à l’aide d’un analyseur logique
- Une invite de connexion est apparue avec les journaux de démarrage
- En saisissant « root », il était possible d’obtenir immédiatement un shell root sans mot de passe
- En pratique, ce port série est directement accessible de l’extérieur en ouvrant simplement le cache
- Un attaquant peut donc se connecter rapidement et injecter du code malveillant sans démonter le terminal
Quelle est la gravité du problème ?
- L’analyse du démarrage et de la configuration du système montre que Linux ne gère que le réseau, les mises à jour et une partie de la logique métier
- Le paiement par carte, la saisie du PIN, l’affichage et toutes les fonctions liées à la sécurité sont pris en charge par un processeur mp1 distinct
- Linux (mp2) démarre systématiquement, puis une image signée et chiffrée est chargée dans le cœur sécurisé par le bootloader sécurisé
- En interne, la protection du cœur sécurisé fonctionne correctement et les données de sécurité critiques ne peuvent pas être exfiltrées via ce shell root exposé
Calendrier de divulgation et de signalement
- 14 novembre 2024 : découverte du shell root
- 15 novembre 2024 : notification au fabricant avec annonce d’une divulgation sous 90 jours
- 18 novembre 2024 : accusé de réception du signalement par le fabricant
- 1er juin 2025 : publication du projet
Conclusion
- L’exposition d’un shell root via un port série externe constitue clairement une surface d’attaque inutile et une erreur d’ingénierie
- Toutefois, grâce à l’architecture séparant le processeur de sécurité, le risque réel d’exposition des données de paiement reste faible
- Il est possible que l’autorisation de connexion root ait été activée par erreur dans le firmware de production, ou qu’elle varie selon les versions
- Au cours de la recherche, certains appareils ont également été trouvés avec la connexion root complètement désactivée
- Il est probable que le problème ait déjà été identifié et corrigé en interne
Ce projet a produit plusieurs résultats intéressants et montre une nouvelle fois la valeur d’une exploration approfondie du firmware
1 commentaires
Commentaires Hacker News
Un mot pour les jeunes développeurs : c’est exactement ce que signifie le mot « hacker » dans « Hacker News » ; ce billet est recommandé comme un exemple classique d’un parcours de hacker, analysé étape par étape de manière accessible ; pour voir des cas similaires, Hack-a-day vaut le détour ; l’auteur semble très curieux et doté de bases techniques particulièrement solides ; au fond, il s’agit d’enquêter sur les datasheets des puces, de dessouder sans dégâts, de recâbler avec des fils quand il s’agit de mémoire, puis de faire preuve d’improvisation et d’accepter les tâtonnements ; la prochaine fois, il pourrait aussi envisager d’utiliser une caméra sténopé en perçant peu profondément afin d’éviter les traces visibles d’altération ; certains regrettent que l’auteur n’ait pas aussi tenté de contourner les vérifications anti-effraction tout en conservant un fonctionnement normal, ce qui aurait été vraiment fascinant
Le terme « hacker » ne se limite pas à la sécurité informatique, il a un sens bien plus large et même une définition philosophique ; en citant le Jargon File compilé notamment par Guy Steele, on rappelle qu’un hacker peut être « quelqu’un qui aime apprendre les détails des systèmes de programmation et en repousser les limites », « quelqu’un qui prend un plaisir passionné à programmer », ou encore « un expert très compétent dans un programme donné » ; certains supposent que PG, le fondateur de Hacker News, avait probablement cette définition large en tête en choisissant ce nom ; et dans l’histoire du terme, The UNIX-HATERS Handbook mérite aussi d’être mentionné
Accord total avec la première phrase : s’il sort encore un wrapper de LLM aujourd’hui, ça va vraiment devenir lassant
Le fait que ce site vienne d’un incubateur de startups financées par des VC ne signifie pas forcément qu’il parle de hacking au sens sécurité ; ce serait plutôt à comprendre au sens startup de « move fast and break things », c’est-à-dire une manière de foncer en produisant du code à toute vitesse pour percer les problèmes
Après avoir lurké pendant très longtemps, quelqu’un explique n’avoir créé un compte et commencé à commenter que récemment ; selon lui, ce sont précisément des posts comme celui-ci, riches en information et en exécution concrète, qui incarnent l’esprit « hacker » de Hacker News
Quelqu’un avoue avoir voté pour l’article parce que, pour une fois, il parlait réellement de hacking ; d’ordinaire, il ne vote que pour les commentaires, mais ce billet a été une exception
Présentation de la possibilité de simuler de fausses transactions de carte de crédit/débit avec un lecteur de carte USB à 2 dollars ; toutes les spécifications et tous les protocoles sont vastes mais publics, donc en théorie on peut les implémenter en lisant la documentation ; mais pour faire approuver une vraie transaction, il faudrait envoyer les données à la banque via Internet, et cela attirerait très vite l’attention des autorités, par exemple le FBI ; les lecteurs de carte eux-mêmes auraient très peu de protections, souvent basés sur Linux avec des mots de passe faibles, et la sécurité viendrait surtout des contrats et des règles entre le commerçant et la banque
Réfutation de l’idée selon laquelle les lecteurs de carte seraient « sans protection » : en réalité, seuls des binaires signés peuvent s’exécuter, le système de fichiers exécutable est en lecture seule, le système de fichiers de données a aussi le drapeau
noexec, la connexion root est désactivée,busyboxest amputé de certaines fonctions, les clés sont chargées au démarrage depuis une zone sécurisée, l’injection de clés maîtresses n’est possible qu’en usine, le boot lui-même est très sécurisé, et en cas de détection d’altération la puce s’efface elle-même ; les terminaux bon marché non certifiés peuvent certes être presque dépourvus de sécurité, mais selon cette personne qui a travaillé sur EMV, les vrais terminaux sont pratiquement totalement verrouillésOn reconnaît en revanche que la partie disant que « la seule sécurité vient des règles entre le commerçant et la banque » est juste ; c’est aussi pour cela que les théories complotistes selon lesquelles on pourrait voler de l’argent à partir de cartes sans contact avec un lecteur portable sont difficiles à mettre en pratique ; même en créant une transaction, les étapes suivantes ou les préparatifs en amont rendent l’extraction discrète de l’argent presque impossible ; et aujourd’hui, avec les notifications push de transaction, une tentative criminelle a de fortes chances d’être repérée
Certains disent être bien plus inquiets par la possibilité qu’un lecteur soit compromis sur site pour lire les informations de carte mises en cache, ou qu’un malware de type interception y soit installé, et que c’est précisément pour cela que ce champ de recherche est important
L’affirmation selon laquelle une transaction doit être transmise à la banque par Internet pour être approuvée est corrigée : les banques n’exposent pas sur Internet d’API ouvertes pour traiter les transactions par carte
D’autres ne sont pas d’accord avec l’idée que la sécurité des lecteurs serait faible, en expliquant que les terminaux des commerçants contiennent en réalité du matériel de sécurité chargé de stocker de manière sûre les clés des banques et des réseaux de paiement ; si ces clés fuyaient, il deviendrait alors possible de forger des transactions légitimes
Retour d’expérience d’une personne ayant acheté 36 lecteurs Stripe M2, dont 7 sont tombés en panne : 2 avec une batterie qui ne charge plus, 1 incapable de lire le NFC, et 4 morts avec une erreur « altéré » ; en apparence, le taux de panne semble catastrophique, mais il faudrait aussi tenir compte du nombre de jours d’usage et de l’ancienneté ; ce qui paraît le plus grave, c’est que ces 7 pannes sont survenues alors que l’ensemble des lecteurs âgés de 1 à 3 ans n’a été utilisé au total que 9 jours ; ils sont transportés dans des coques rigides avec inserts en mousse, donc ce n’est pas un problème de stockage négligé ; malgré cela, les Stripe M2 restent encore la meilleure option disponible, et il faut donc faire avec ; il précise aussi que son entreprise gère les paiements lors de festivals, ce qui explique cet usage massif mais ponctuel
Certains imaginent que lorsqu’une protection anti-effraction physique s’active, cela pourrait justement ouvrir un shell root : soit parce que le système passe dans un mode sécurisé disposant de toutes les clés cryptographiques nécessaires, soit parce qu’il bascule en shell root à des fins de débogage ou d’analyse de panne ; avec l’espoir, bien sûr, que les clés privées importantes soient alors automatiquement supprimées
En citant le billet d’origine, selon lequel « même avec un shell root, les informations de carte ne sont pas en danger », quelqu’un le recommande comme lecture indispensable pour les concepteurs de systèmes de sécurité
Quelqu’un avance que c’est le Linux modifié qui décide de charger soit le code du « compromised mode », soit le système de sécurité mp1 ; même si le bootloader lui-même est sûr, cela dépend toujours de l’environnement dans lequel il finit réellement par s’exécuter ; un coprocesseur peut jouer le rôle d’un Secure Enclave, mais si Linux peut charger un bootloader séparé, cela pourrait constituer un problème de sécurité majeur
loadercodeetmp1.img, qu’il y ait tamper ou non, puis c’est à l’intérieur deloadercode, protégé en intégrité, qu’un branchement est effectué en fonction de l’état tamperRecommandation faite aux débutants d’essayer d’abord les terminaux de carte bancaire récents basés sur Android, avec la tentation supplémentaire du code PIN saisi sur écran tactile, jugé encore plus amusant
Réponse : le contrôleur tactile est généralement relié à un MUX contrôlé par le processeur de sécurité, et lors de la saisie d’informations sensibles, les événements tactiles sont envoyés directement au processeur sécurisé sans passer par le système d’exploitation de type Android
Même si le PIN s’affiche sur le pavé tactile, les données PIN sont gérées et chiffrées par un firmware exécuté dans une zone de confiance, et les applications intermédiaires ne peuvent pas les voir
D’autres estiment que même si l’on compromettait ce type de terminal Android, si l’architecture de sécurité reste la même, la carte elle-même effectue des opérations cryptographiques suffisamment complexes pour qu’il n’y ait en pratique aucune donnée exploitable ; une telle attaque ne fonctionnerait vraiment que s’il ne restait qu’un simple lecteur de carte, et dans ce cas, ce terminal serait déjà pour l’utilisateur un énorme signal d’alerte de skimmer
Brève remarque jugée intéressante : en Inde, des terminaux Android fonctionnent encore sous Android Oreo, dont le support a pris fin en janvier 2021
Quelqu’un s’étonne qu’en analysant le terminal, l’auteur l’ait ouvert immédiatement et déclenché le mode tamper ; il suppose qu’il ne savait peut-être pas que la plupart des lecteurs intègrent une détection d’altération ; tester en mode tamper risque de réduire l’intérêt de l’exercice, et il se demande aussi si ce mode n’ouvre pas simplement un shell destiné à la réinitialisation ; enfin, il suggère de reconsidérer l’idée selon laquelle ouvrir l’appareil dès le départ serait forcément la démarche naturelle
Éloge du fait que, malgré des protections anti-effraction très poussées, il reste encore beaucoup de pistes de contournement et d’artefacts intéressants à explorer ; la partie sécurité semble au moins conçue pour échouer de manière sûre
Il est souligné que le processeur renforcé (
mp1) reste toujours intouché ; en pratique, seuls des strings sont passés au binairedisplay_toolpour échanger des messages avec l’autre processeur ; le lecteur de carte, le clavier et les autres composants sensibles ne sont pas accessibles directement depuis Linux ; c’est le processeurmp1, complètement séparé, qui gère tout le traitement « sécurisé » lié à la carte, au PIN et à l’affichage, tandis que le Linuxmp2ne s’occupe que du réseau, des mises à jour et de la logique métierUn autre scénario avance que la partie Linux pourrait être responsable de détecter le traitement des événements tamper ; mais si les clés de sécurité ne sont supprimées qu’après une détection complète du tamper, alors il pourrait être dangereux d’obtenir d’abord un shell root, puis de contourner ensuite le déclenchement tamper
Certains trouvent frappant que ce type de terminal soit déployé partout en Europe ; pour la Suisse, ils ne sont pas sûrs, mais dans beaucoup d’endroits d’Europe qu’ils connaissent, porter une carte de crédit serait relativement rare ; comme ces terminaux lisent en réalité toutes sortes de cartes, ils estiment que l’appellation « système POS » serait plus appropriée ; en tout cas, ils ont trouvé le billet très divertissant