Point d'échec : piratage d'un terminal de point de vente avec WHIDBOARD

DE LA CAISSE À UN SHELL ROOT

Il y a quelque temps, je faisais des courses en ville lorsque je suis tombé sur un terminal de point de vente (POS) intéressant. Pendant que la caissière préparait mon sac, j’ai rapidement sorti mon téléphone et pris quelques photos pour m’en souvenir plus tard…

Une fois rentré chez moi, j’ai commencé à examiner de plus près les étiquettes situées sous le terminal de point de vente et j’ai immédiatement remarqué un détail intéressant… un numéro d’identification FCC était clairement visible (c’est-à-dire SEKMA512)! 😎

RECON passive – C'est l'heure de l'OSINT !

Grâce à cette information, j’ai pu rapidement obtenir plus de détails sur ce nouveau DUT (Device Under Test) même sans en posséder un (pour l’instant).

Dans la base de données de la FCC, j’ai pu obtenir plus de détails sur les circuits imprimés internes, le fonctionnement de l’appareil et l’existence éventuelle de fonctions anti-falsification destinées à empêcher les tentatives de piratage matériel.

En particulier, en parcourant son manuel, j’ai pu confirmer que ce terminal de paiement (à l’instar de tout autre appareil similaire traitant des données de cartes de crédit) dispose effectivement de certaines contre-mesures visant à empêcher les acteurs malveillants de manipuler physiquement le circuit imprimé, comme le montrent les images ci-dessus.

Cependant, je n’ai pas baissé les bras et j’ai continué à parcourir les documents de la base de données de la FCC afin de mieux comprendre l’ensemble du dispositif testé et de compléter mon modèle de menace initial, à la recherche de points d’entrée potentiels.

Comme vous pouvez le voir sur l'image ci-dessus, la carte mère principale comporte un certain nombre de points de test. Certains d'entre eux ont retenu mon attention, notamment parce qu'ils semblaient accessibles de l'extérieur sans ouvrir le boîtier du TPV — ce qui signifie qu'ils pouvaient être sondés sans déclencher les mécanismes anti-falsification qui effaceraient la mémoire de l'appareil.

Maintenant que j’avais identifié quelques points d’entrée potentiels, il était temps d’acheter quelques échantillons en ligne…

RECON active – Énumération des broches avec WHIDBOARD

Quelques jours plus tard, les échantillons DUT sont arrivés, et la première étape a consisté à tester les points de test à l’aide d’un multimètre afin d’identifier ceux qui étaient électriquement pertinents. Après avoir réduit la liste, j’ai ensuite utilisé la fonctionnalité d’analyseur logique intégrée à WHIDBOARD pour vérifier si des données étaient émises par le TPV.

Après avoir essayé différentes broches, comme vous pouvez le voir sur la capture d'écran ci-dessous, j'ai finalement trouvé la ligne TX d'une interface de débogage UART. 😎

Il est maintenant temps de lancer la fonctionnalité Pin Enumerator de WHIDBOARD afin de trouver également la broche RX !

Laisser le DUT terminer le processus de démarrage a conduit à quelque chose de vraiment inattendu…

Non seulement ce terminal de point de vente a exposé une interface UART pleinement fonctionnelle en dehors de sa zone de sécurité anti-falsification — ce qui indique un échec tant dans la modélisation des menaces pendant la R&D que dans la validation de la sécurité avant la production — mais cette interface de débogage a directement abouti à un shell root. 💥🤯

Mettons la main à la pâte – Interagir avec le DUT en tant que root

À ce stade, les choses se sont rapidement enchaînées. À l’aide de WHIDBOARD, j’avais identifié un UART exposé qui menait à un ACCÈS ROOT COMPLET ET NON AUTHENTIFIÉ…

J'ai ensuite exploré le système de fichiers de l'appareil, inspecté les processus en cours d'exécution et compris l'architecture interne du DUT.

Finalement, j’ai exfiltré l’intégralité du micrologiciel via une clé USB à l’aide des commandes suivantes…

Et pour prouver que j’étais capable non seulement de lire le système de fichiers, mais aussi de le modifier… j’ai effectivement apporté quelques modifications… 😎

RECON active – Analyse du réseau

À ce stade, par curiosité, j’ai également vérifié s’il y avait des services du réseau ouverts sur l’interface Ethernet de l’appareil testé. Les résultats étaient alarmants : le port Telnet 23/TCP était OUVERT… 🤯💥

Et oui… on pouvait s'y connecter (en tant qu'administrateur) SANS mot de passe !

À ce stade, j’ai décidé de vérifier sur Shodan si l’un de ces terminaux de point de vente était connecté à Internet. Résultat : au moins 61 d’entre eux étaient exposés sur Internet… 🙊🙉🙈

Conclusions

Ce dispositif testé (DUT) a été une véritable surprise : en plus de dix ans de recherche sur la sécurité des TPV, je n’avais jamais rencontré un appareil présentant autant de failles cumulées. Analysons ce qui n’a pas fonctionné et pourquoi cela est important.

Échec de plusieurs couches de défense en profondeur. Cet appareil présentait au moins quatre vulnérabilités distinctes, exploitables indépendamment les unes des autres :

1. Des points de test de débogage accessibles de l'extérieur qui contournent les protections physiques anti-falsification ;
2. Une console UART active et non authentifiée permettant d'accéder au shell root ;
3. Telnet sur le port 23/TCP avec connexion root sans mot de passe sur l'interface du réseau ;
4. Au moins 61 instances détectables via Shodan, exposées directement à Internet.

Chacune de ces failles constituerait à elle seule une découverte critique. Ensemble, elles représentent une défaillance systémique dans le cycle de vie de la sécurité du produit — depuis la modélisation des menaces et la conception sécurisée jusqu’à la mise en œuvre et aux tests de pré-production.

Implications pour l'infrastructure de paiement. Un terminal de point de vente (POS) disposant d'un accès en lecture/écriture au niveau root au système de fichiers — accessible à la fois physiquement et via le réseau — ouvre la voie à l'installation de portes dérobées dans le micrologiciel, à l'interception de données de paiement et au déploiement d'implants persistants. Dans les environnements où la conformité à la norme PCI DSS est attendue, ce type de vulnérabilité ne constitue pas une lacune marginale : il sape l’ensemble du modèle de confiance. Le fait que ces appareils soient connectés à Internet amplifie le risque, le faisant passer d’une attaque physique locale à une attaque à distance évolutive.

Le contexte réglementaire : la CRA et au-delà. Avec l’entrée en vigueur de la loi européenne sur la cyber-résilience (CRA), les produits comportant des éléments numériques mis sur le marché européen devront satisfaire à des exigences essentielles en matière de cybersécurité tout au long de leur cycle de vie — notamment une configuration sécurisée par défaut, des surfaces d’attaque minimisées et des obligations en matière de gestion des vulnérabilités. Un appareil livré avec un accès root non authentifié via UART et Telnet constituerait un scénario de non-conformité typique. Les fabricants et les importateurs devraient considérer de telles découvertes comme un aperçu de ce que les régulateurs rechercheront.

Points clés à retenir pour les professionnels. Ne sous-estimez jamais les informations OSINT accessibles au public. La base de données de la FCC a à elle seule fourni suffisamment d’informations pour établir un modèle de menace préliminaire, identifier les limites anti-falsification et localiser les points d’entrée potentiels, le tout avant même d’acheter un seul appareil. Pour les membres des équipes rouges et les chercheurs en sécurité, cela rappelle que la reconnaissance passive des documents réglementaires peut considérablement accélérer les évaluations matérielles. Pour les fabricants et les membres des équipes bleues, cela rappelle que vos soumissions à la FCC, vos démontages et vos manuels d'entretien font partie de votre surface d'attaque.