Une recherche récente met en lumière un scénario préoccupant : une carte SIM malveillante peut demander à l’équipement cellulaire dans lequel elle est insérée d’exécuter des commandes choisies par l’attaquant. Dans certains modules intégrés à des appareils IoT, cette capacité suffit à compromettre l’appareil lui-même, pas seulement la connectivité.
Le cœur du problème repose sur ce que les chercheurs décrivent comme une interface AT SIM — un mécanisme standardisé permettant à la carte de provoquer l’exécution de commandes du modem. Concrètement, cela revient à donner à une carte déjà présente dans le logement SIM un accès de type console aux commandes AT, étendues par les fabricants.
Pourquoi une carte SIM peut devenir un point d’entrée
Les chercheurs ont testé 26 téléphones et modules cellulaires afin d’évaluer la capacité à exécuter du code à la demande via l’interface SIM. Sur cet ensemble, 9 appareils ont activé la fonctionnalité recherchée. Avec ces appareils, l’équipe a réussi à faire tourner son propre code sur un chargeur EV commercial.
Dans les résultats, la disparité est nette :
- 6 modules cellulaires sur 8 acceptaient les commandes.
- 3 téléphones sur 18 les acceptaient : OPPO Find X5, OPPO Reno 14 F 5G et ASUS Zenfone 9.
- Parmi les modèles testés, aucun iPhone ni Pixel ne figurait dans la liste des appareils acceptant l’interface.
Un point important : connaître le numéro de la victime n’est pas suffisant pour ce type d’attaque. Ici, tout commence par une carte hostile déjà insérée — insérée manuellement, glissée via un interposer très fin, ou introduite dans des contextes où un opérateur compromis ou un processus de production peut modifier la carte ou sa configuration.
Les équipements IoT exposés : machine-to-machine
Les chercheurs soulignent que l’exposition concerne surtout des dispositifs machine-to-machine : chargeurs électriques, routeurs industriels, unités de télématique pour véhicules et autres appareils embarquant des modules cellulaires. Les appareils sans surveillance, avec un logement SIM accessible et peu d’autres contrôles, constituent des cibles naturelles pour des attaques de type “carte en place”.
Dans l’échantillon étudié, 5 des 6 modules acceptant la commande provenaient d’un même fournisseur de modules, avec plusieurs cas tirés d’appareils liés aux voitures et à l’IoT.
Un mécanisme conforme… mais dangereux : l’interface AT
Le mécanisme en cause est décrit comme une commande proactive. L’idée est que la carte SIM n’attend pas passivement d’être lue : elle peut pousser une instruction au modem. La commande RUN AT demande au modem d’exécuter une commande AT.
Les commandes AT ont une longue histoire : elles proviennent du langage de contrôle des modems datant du Hayes Smartmodem (1981), puis chaque fournisseur les a étendues. En pratique, cela signifie que l’activation de l’interface offre à la carte un accès généraliste à des possibilités de commande souvent dépendantes de l’implémentation.
Les chercheurs expliquent aussi que la capacité est “cadre par” les spécifications techniques de la communication cellulaire. Autrement dit : le résultat n’est pas présenté comme une rupture totale avec les standards, mais comme une exposition liée à la manière dont les équipements implémentent l’interface.
Pas de correctif unique : désactiver l’interface ou renforcer la configuration
Contrairement à une vulnérabilité localisée à un seul morceau de code, il n’existerait pas “un patch unique”. Les chercheurs indiquent plutôt un ensemble de facteurs :
- Des défauts logiciels “classiques” (bugs) susceptibles d’être corrigés.
- Une interface documentée qui rend ces défauts exploitables si elle reste active.
- La décision de chaque fabricant quant à l’activation par défaut de cette interface.
Du côté des réponses :
- Qualcomm indique avoir mis en place une configuration durcie qui désactive l’interface par défaut.
- Quectel déclare avoir atténué une faiblesse liée à l’accès fichiers et travaille encore sur l’interface.
Les chercheurs ne rapportent pas d’exploitation connue à grande échelle utilisant cette interface au moment de la publication. Ils estiment toutefois qu’il faut durcir, déprécier ou désactiver l’interface — et ils recommandent aux opérateurs de flottes IoT cellulaires de vérifier, auprès du fournisseur de module, si l’interface est activée dans les firmwares livrés et si elle peut être désactivée.
Ce que montrent les cas d’étude : blocage, exécution et lecture de fichiers
Pour comprendre le potentiel d’abus, la recherche décrit plusieurs démonstrations sur des appareils acceptant la commande.
Commande qui force un basculement réseau non réversible côté utilisateur
Sur un OPPO Reno 14 F 5G (parmi les rares téléphones ayant accepté l’interface), une commande du type AT+COPS=0,,,0 a eu pour effet de verrouiller le téléphone en 2G. L’utilisateur ne pouvait pas corriger le problème via les méthodes habituelles (mode avion, sélection manuelle du réseau, changement des préférences), et la logique de sécurité liée à l’authentification en 2G est présentée comme un facteur aggravant : la victime ne peut pas “annuler” les conditions permettant à un attaquant de rejouer un scénario de fausse station de base.
Deux autres commandes décrites ont conduit à l’extinction du téléphone et à la coupure du modem.
Par ailleurs, des outils développés par les chercheurs (diffusés sous le nom CATana) ont permis d’identifier de nombreuses commandes AT joignables via la carte SIM sur cet appareil.
Injection et exécution via un composant lié au module
Un cas sur un chargeur EV commercial (identifié par un code de modèle) montre une chaîne d’attaque côté module. Les chercheurs décrivent comment un démon (atfwd_daemon) passe un texte contrôlé par l’attaquant vers un appel de shell au travers d’une chaîne de format non sûre. Un mécanisme de “liste noire” des caractères était censé empêcher des échappements, mais une combinaison liée au passage de nouvelle ligne aurait permis de contourner la protection.
En deux étapes, l’équipe obtient de l’exécution de code pilotée exclusivement par des commandes émises par la SIM.
Le texte précise que le code problématique appartiendrait au module (le fournisseur de module), et que les chercheurs auraient contacté le fournisseur du module qui a ensuite notifié ses clients.
Lecture de fichiers et envoi via des commandes AT
Un troisième cas d’étude vise la lecture arbitraire de fichiers. Le scénario implique un démon TFTP exécuté avec des privilèges élevés et qui ne vérifierait pas correctement certains cas de liens symboliques. Les fichiers seraient ensuite expédiés à l’aide des commandes AT associées au module (par exemple une commande d’envoi SMTP à travers l’interface AT du modem).
Ce type d’attaque exige des conditions supplémentaires : il faut qu’un lien malveillant soit déjà présent sur le système du module, par exemple via une carte SD ou via le flash d’une partition conçue à dessein.
Des signaux connexes : autres failles et mise à jour déjà effectuée
En préparation à ces travaux, le groupe avait également montré qu’une SIM hostile pouvait faire ouvrir une page web contrôlée par l’attaquant sur un téléphone Android verrouillé, sans interaction utilisateur. Ils citent des modèles Pixel dans cette série, et indiquent que Google a corrigé une partie distincte de ce problème sous la forme d’une référence CVE-2025-48618 publiée dans le bulletin Android de décembre 2025.
Qu’est-ce qui est probable à grande échelle ?
La recherche ne mesure que ce que les 26 appareils testés font réellement. Pourtant, les chercheurs estiment qu’un grand nombre de configurations basées sur cette famille de modules sont susceptibles d’être affectées. Ils évoquent notamment une série de modules construits autour d’un modem Qualcomm et utilisés fréquemment dans des véhicules, chargeurs et terminaux de paiement.
Ils expliquent aussi que vérifier l’impact à grande échelle est compliqué, notamment parce que certains fournisseurs de firmware de modules ne publient pas de mises à jour publiquement. Le nombre total d’équipements en service n’est donc pas quantifié dans les sources résumées.
Suivi de la divulgation : CVE, réponses des acteurs et absence d’advisories publiques
Les rapports auraient été transmis à plusieurs parties entre mars 2026 et mai 2026, dont des acteurs du mobile et des fournisseurs de modules. Les chercheurs indiquent un suivi via des identifiants de type CVE et un enregistrement côté GSMA, tout en précisant que certains enregistrements pourraient ne pas encore apparaître dans la liste publique du programme CVE.
Au moment de la publication du résumé :
- Aucune des parties mentionnées n’aurait publié d’avis public détaillant les correctifs.
- Le portail d’avis du fournisseur de modules resterait accessible uniquement avec connexion.
- Aucune exploitation n’aurait été rapportée.
Que peuvent faire les responsables de flottes et d’exploitants
Si vous gérez une flotte d’équipements cellulaires, la recherche insiste sur une action pragmatique dès aujourd’hui : demander au fournisseur du module si l’activation de l’interface associée à la commande RUN AT est présente dans le firmware livré et si elle peut être désactivée.
À plus long terme, l’objectif est de réduire l’attaque à sa surface minimale : configuration durcie par défaut sur les futurs équipements, et correctifs via mises à jour firmware lorsque cela est disponible.
Conclusion : une interface SIM qui peut transformer le modem en console
Cette étude montre qu’une interface AT SIM activée peut permettre à une carte insérée de piloter le modem avec des commandes adaptées à l’implémentation du fabricant. Une fois cette porte ouverte, des défauts techniques peuvent être déclenchés pour provoquer des comportements allant du blocage réseau à l’exécution de code.
Le message est clair : pour les équipements IoT connectés, la sécurité ne se limite pas au matériel — elle dépend aussi de la configuration des interfaces et des choix de désactivation. En identifiant si l’interface est active et en exigeant des réponses techniques des fournisseurs, les opérateurs peuvent réduire le risque dès maintenant.
Source: https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
