Vue lecture

Une carte SIM piégée et la borne de recharge exécute du code malveillant

Je m'intéresse à la sécurité mobile depuis un paquet d'années, et cette attaque-là, je ne l'avais jamais vue. Le point de départ n'est ni le réseau, ni un SMS piégé, ni une appli vérolée. C'est la carte SIM elle-même ! En effet, des chercheurs de l'université de Birmingham et de Fuzzware lui ont fait donner des ordres au modem qui l'héberge.

Le mécanisme s'appelle RUN AT et c'est une commande proactive puisque la carte ne se contente pas de répondre à l'appareil, mais elle lui demande aussi d'exécuter une commande AT. C'est ce même langage qui pilote les modems depuis le Hayes Smartmodem de 1981 donc autant dire qu'on a là, une vraie console générique dispo sur un bout de plastique.

Et sur une borne de recharge Autel, ça donne tout simplement une exécution de code. Le module Quectel qui l'équipe, fait passer le texte reçu dans un appel shell, avec une liste noire de caractères censée bloquer les échappements. Mais un simple retour à la ligne passe au travers... Et voilà comment 2 étapes plus loin, les chercheurs sont parvenus à faire tourner leur propre code, piloté depuis la SIM. Décidément, les bornes de recharge collectionnent les mauvaises surprises .

Autre exemple sur un smartphone OPPO Reno 14 F 5G, où une seule commande coince le téléphone en 2G... Son propriétaire ne peut alors plus revenir en arrière : ni le mode avion, ni la sélection manuelle du réseau, ni la désactivation de la SIM dans les réglages ne permet de restaurer de la 5G ou de la 4G. Or la 2G n'a pas d'authentification mutuelle, donc une fausse antenne redevient un facteur de risque sur ce genre de matos récent. Deux autres commandes éteignent même le téléphone ou tuent son modem.

Reste la condition d'entrée, et elle est lourde : la carte doit déjà être hostile. Cela passe au choix par un échange physique, un interposeur glissé sous la puce, un opérateur compromis, ou du sabotage en usine... Mais surtout, rien là-dedans n'exploite de bug exotique. En fait, cette capacité est écrite dans les spécifications cellulaires, ce qui fait dire au chercheur Marius Muench que ces attaques sont conformes au standard.

Maintenant sur votre téléphone perso, le scénario d'une telle attaque reste assez serré. Mais sur un boîtier 4G oublié dans un local technique, beaucoup moins. Sur 26 appareils testés, 9 exposent l'interface, dont 6 modems IoT sur 8, contre 3 téléphones sur 18. Par contre, ni iPhone ni Pixel ne sont faillibles et Qualcomm a préparé une configuration durcie qui la coupe par défaut. De son côté, Quectel travaille encore dessus...

Bref, si vous exploitez des équipements cellulaires sur le terrain, une seule question au fournisseur du module suffit : RUN AT est-il activé, et peut-on le couper ? Notez qu'aucune attaque de ce type n'a été signalée pour le moment.

Source

  •  

La Royal Navy et ses caméras de la Dynastie Ping

Dans la série "les gens qui assurent notre sécurité n'ont pas fait leur job jusqu'au bout", voici une chouette histoire de caméras montées sur les drones navals de la Royal Navy qui, ÉVIDEMMENT, envoyaient des signaux vers une adresse IP située en Chine. Et cette découverte ne vient pas d'une opération de contre-espionnage mais d'une simple évaluation de vulnérabilité de routine, menée par le ministère de la Défense britannique sur son propre matériel.

Ces caméras sont celles qui équipent les K3 Scout, des bateaux sans équipage que la Royal Navy et les Royal Marines utilisent pour la surveillance et la protection de force.

Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et le signal en question porte un nom que tout le monde connaît en domotique : un heartbeat. C'est le ping le plus banal qui existe, celui qui dit "je suis en ligne, je fonctionne" et rien d'autre. C'est le même que crache votre caméra IP du salon, dont je vous parlais déjà avec OpenIPC .

Le ministère britannique affirme qu'aucune donnée sensible, aucun système militaire et aucune donnée gouvernementale n'ont été consultés, compromis ou transmis hors des canaux autorisés et ajoute que ses procédures de test ont repéré le problème "tôt".

La connectivité internet des caméras a quand même été coupée puisque même si ça n'a l'air de rien, un mouchard qui se contente de dire bonjour reste un mouchard qui connaît le chemin.

Reste maintenant la question de comment ce composant est arrivé sur un engin de reconnaissance militaire. En fait, les caméras ne viennent pas de Kraken Technology Group, le constructeur britannique du K3 Scout, mais d'un sous-traitant tiers qui pourtant avait fourni des assurances sur le fait que ses caméras répondaient aux exigences de sécurité, y compris celles rattachées au National Defense Authorization Act américain.

Bref, de la paperasse, des assurances, mais pas un démontage ni une capture de trafic... Kraken dit avoir mené un audit complet avec la Royal Navy une fois les communications découvertes. J'espère bien ^^ !

Côté portée, ça concerne les 20 K3 Scout achetés dans le cadre du Project Beehive, un programme de 12,3 millions de livres, en service chez les Royal Marines depuis mars. Le Telegraph , qui a sorti l'affaire, écrit que du matériel lié à la préparation d'une éventuelle mission britannique dans le détroit d'Ormuz avait été enregistré sur ces appareils.

Par contre, ce qu'on ne sait toujours pas, c'est la marque de la caméra et la nature exacte du composant chinois car aucun rapport ne les nomme pour le moment... Mais j'espère que ça n'a pas été aussi intégré sur du matos français...

Source

  •  

Chrome sécurise votre session dans une puce, Firefox dit non

Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source

  •  

CHERRY sort deux lecteurs de carte à puce qui marchent sous Linux sans pilote propriétaire

CHERRY a annoncé deux appareils à carte à puce, un clavier complet avec lecteur intégré baptisé Smart Board 1150, et un terminal séparé, le Smart Terminal ST-1150. Ils remplacent le KC 1000 SC et le ST-1144.

Une carte à puce sert ici à prouver qui vous êtes. Vous l'insérez, elle signe électroniquement un document, elle ouvre une session sur un réseau ou elle déchiffre un fichier, sans que la clé privée qu'elle contient ne sorte jamais de la puce.

Les deux appareils s'appuient sur le pilote CCID que Microsoft livre déjà dans Windows, et sur pcsc-lite sous Linux et macOS. La norme CCID permet à un lecteur de dialoguer avec le système d'exploitation sans code maison, et pcsc-lite en est l'implémentation libre côté Unix.

Aucun pilote propriétaire à installer, donc. Vous branchez et ça fonctionne, y compris sur une machine Linux, ce qui est encore assez rare pour ce type de matériel.

Screenshot

Les deux modèles embarquent aussi un contrôleur à mémoire flash, et le firmware peut être mis à jour après le déploiement. Ce genre de lecteur était jusqu'à présent figé pour toute sa durée de vie, avec les failles qu'il avait le jour de sa fabrication.

Le communiqué ne dit hélas rien sur la signature de ces mises à jour. Sur un périphérique de sécurité, la question n'a rien de cosmétique, parce qu'un firmware modifiable est aussi un firmware attaquable si personne ne vérifie d'où vient l'image installée.

Le terminal lit et écrit les cartes, pour ouvrir une porte, se connecter au réseau de l'entreprise ou valider une transaction en ligne. Il est fabriqué entièrement en Europe. CHERRY veut clairement faire les yeux doux aux administrations et aux organismes de défense, avec les certifications américaines TAA et FIPS-201 au passage, et une base lestée en métal qui permet d'y glisser la carte d'une seule main.

Le clavier ajoute pour sa part une touche Copilot, ce qui sur un poste à données sensibles est quand même quelque peu audacieux. Il existe aussi en version conforme au Trade Agreements Act américain, pour les agences fédérales et les installations militaires soumises à des règles d'approvisionnement particulières, mais bon a priori ça ne devrait pas trop vous concerner (même si on a de plus en plus de lecteurs américains depuis que le site est traduit !).

Le Smart Board 1150 est vendu 49,99 euros. Le Smart Terminal ST-1150 descend à 34,99 euros, et les deux sont disponibles dès maintenant.

J'avoue que je ne pensais plus voir sortir de nouveaux lecteurs de carte à puce en 2026.

Source : Cherry

  •  
❌