Le GPS de sa Renault Latitude de 2014 ne permettait pas de changer l’heure sans une carte SD de cartographie officielle. Un chercheur estonien a fini par contourner ces restrictions pour y exécuter ses propres scripts avec les droits d’administrateur.
Rasmus Moorats voulait simplement régler sa voiture à l’heure d’hiver. Son interface TomTom Carminat LIVE lui a pourtant imposé un détour numérique inattendu. Le menu de réglage de l’horloge dépendait en effet de fichiers présents sur la carte SD de navigation, qu’il avait choisi de ne pas récupérer lors de l’achat de la voiture. Le chercheur s’est donc plongé dans le logiciel de l’appareil pour trouver un autre accès. Et force est de constater qu’il est plutôt ingénieux…
Des protections solides, un script trop privilégié
Le GPS embarqué de sa Renault Latitude fonctionne sous une version de Linux adaptée par TomTom (noyau 2.6.28.10). Malgré son âge avancé, plusieurs protections compliquent les modifications par des utilisateurs tiers. Certaines partitions sont en effet en lecture seule ; d’autres utilisent l’option noexec, qui bloque l’exécution directe des programmes qu’elles contiennent.
La carte SD est elle aussi montée avec l’option noexec. Ses fichiers de cartographie sont également liés à son identifiant matériel, ce qui empêche de les utiliser en les copiant simplement sur une autre carte.
Après avoir échoué à faire accepter une mise à jour modifiée, Rasmus Moorats reproduit l’environnement du GPS sur son ordinateur avec QEMU, un logiciel d’émulation. Il découvre alors que l’appareil lit au démarrage un fichier nommé master.script sur la carte SD. Ce script sert à automatiser des actions dans l’interface. Son interpréteur, le programme ttn, dispose des droits root, les privilèges les plus élevés sous Linux.
Deux fonctions détournées pour contourner les restrictions
Le script propose notamment deux commandes intéressantes. SHEX peut lancer un programme déjà installé, mais sans lui transmettre d’arguments. LOG permet d’écrire du texte dans un fichier. Une faille de traversée de chemin autorise toutefois à sortir du répertoire prévu pour écrire ailleurs dans le système.
Le chercheur utilise cette possibilité pour modifier /proc/sys/kernel/core_pattern. Ce paramètre indique à Linux comment traiter les données de diagnostic lorsqu’un programme plante. Il peut notamment désigner un programme, avec des arguments, chargé de les recevoir. Rasmus Moorats le détourne pour appeler l’interpréteur /bin/sh, déjà présent sur le GPS, et lui faire lire son propre script sur la carte mémoire SD.
Pour déclencher l’opération, SHEX lance /bin/dbus-monitor, qui plante en l’absence du service D-Bus. Le noyau lance alors /bin/sh, conformément au réglage de core_pattern modifié précédemment. Cet interpréteur lit le script de la carte SD et l’exécute avec les droits root, contournant ainsi l’interdiction d’exécution directe imposée par noexec. Trois lignes dans master.script suffisent à déclencher cet enchaînement.
Les pleins pouvoirs sur le GPS, puis une heure de moins
Rasmus Moorats valide d’abord la méthode avec un script qui redémarre l’appareil. L'Estonien sauvegarde ensuite sa mémoire interne avec l’outil dd, puis repère le réglage recherché dans /mnt/flash/settings.dat. L’appareil conserve un décalage en minutes par rapport à l’heure reçue du GPS. Il suffit alors de remplacer 180 par 120 pour passer d’un décalage UTC+3 à UTC+2, correspondant à l’heure d’hiver en Estonie.
La méthode présentée nécessite toutefois un accès physique au GPS. Le chercheur doit y insérer sa carte SD, puis sélectionner Oui lorsque l’écran lui demande d’autoriser l’exécution de master.script. Une manipulation qui rappelle l’intérêt de vérifier l’origine des supports insérés et des scripts que l’on autorise dans n'importe quel appareil électronique ou informatique.
Il aura donc fallu un émulateur, de la rétro-ingénierie et les pleins pouvoirs sur le GPS pour retrouver un simple réglage d’horloge sur une Renault de 2014. Pour changer d’heure, on a connu plus simple dans l'histoire de la tech et de l'automobile…
Source : Rasmus Moorats via Cybersecuritynews
Une partition montée en lecture seule empêche toute modification des fichiers système, ce qui limite les altérations accidentelles ou malveillantes. L’option noexec bloque, de son côté, l’exécution directe de programmes ou de scripts depuis cette partition. Sur un appareil embarqué, ces mesures compliquent l’installation d’outils non autorisés et réduisent la surface d’attaque. En revanche, elles ne bloquent pas forcément l’exécution indirecte, par exemple si un programme autorisé lit un script et l’interprète lui-même.
Sous Linux, root correspond au compte administrateur avec un accès quasi total au système (fichiers, paramètres noyau, périphériques). Un programme ou interpréteur qui tourne en root peut modifier des réglages critiques, contourner des protections logicielles et accéder aux données internes. Dans un contexte embarqué, cela permet aussi d’extraire des images mémoire, de changer des paramètres de démarrage ou de remplacer des composants logiciels. C’est pour cette raison qu’un mécanisme de scripting ou de maintenance ne devrait, en principe, disposer que de privilèges strictement nécessaires (principe du moindre privilège).
core_pattern est un paramètre du noyau Linux qui définit quoi faire lorsqu’un programme plante et génère un dump (fichier de diagnostic). Selon sa configuration, il peut écrire un fichier de core dump à un emplacement précis ou envoyer les données à un programme, via une syntaxe qui permet de lancer un gestionnaire. Si un attaquant peut modifier ce paramètre, il peut parfois forcer l’exécution d’un programme légitime du système (comme un interpréteur de shell) avec des arguments. Le déclenchement se fait ensuite en provoquant volontairement un crash, afin que le mécanisme de collecte de crash exécute le gestionnaire configuré.
