Les Honda Civic et le voiturier malveillant

 (juniperspring.org)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • L'unité principale de la Honda Civic modèle 2021 peut accepter, via la voie de mise à jour USB, des mises à jour signées avec des clés de test AOSP publiques, ce qui permet à une personne ayant un accès physique d'exécuter du code arbitraire
  • Les mises à jour de Honda sont appliquées via Android recovery, et même si le binaire recovery a été modifié, la logique de vérification de signature verify_file reste conforme à celle d'AOSP par défaut
  • En signant avec les clés de test AOSP publiques et en respectant le format attendu pour la clé USB, il est possible d'installer le code de son choix sans su ni setuid, une attaque appelée EvilValet
  • Le nouvel outil ota-builder facilite la préparation de fichiers de mise à jour acceptés par l'unité principale, et apk-rebuilder convertit les fichiers de mise à jour en une arborescence de sortie utile pour la rétro-ingénierie
  • Le projet a terminé l'essentiel du travail d'investigation, mais le dépôt n'est pas abandonné et des contributions sont nécessaires sur les informations de version, la toolchain, les thèmes personnalisés et l'amélioration du mapping AIDL

Contexte de la mise à jour du projet

  • Il y a 3 ans, un premier travail pour comprendre et rétroconcevoir l'unité principale d'une Honda Civic 2021 a été publié, et cette mise à jour récapitule les progrès réalisés depuis
  • La réaction initiale a été très encourageante, et l'avancée la plus importante est venue de la compréhension du processus de mise à jour

Les clés du royaume

  • Honda prend en charge les mises à jour de l'unité principale via USB, et au final un fichier de mise à jour AOSP signé présent sur la clé USB est préparé et appliqué via Android recovery
  • Il existe plusieurs vérifications propres à Honda, mais des clés de test AOSP publiquement connues étaient encore présentes dans res/keys, et la logique de signature verify_file du binaire recovery modifié restait conforme à celle d'AOSP par défaut
  • En formatant correctement la clé USB et en signant avec les clés de test AOSP publiques, il est possible d'installer le contenu de son choix sur l'unité principale sans accès root préalable
    • Il n'est pas nécessaire d'obtenir un accès root classique en configurant setuid sur su
    • Tant que l'unité principale est alimentée et que l'attaquant a un accès physique au port USB le plus à l'avant, il est possible d'exécuter du code arbitraire sur l'unité principale via le mécanisme de mise à jour
  • Cette attaque ressemble à une evil maid attack, où quelqu'un obtient un accès physique à une chambre d'hôtel, mais comme il faut ici accéder à l'habitacle du véhicule, elle est appelée EvilValet
    • Dans le scénario d'exemple, un voiturier d'hôtel installe la mise à jour via USB et, lorsque la voiture est rendue, le conducteur ne se rend pas compte que l'unité principale a été modifiée
  • Ce billet n'est pas une documentation technique détaillée ; pour plus d'informations, voir le document Display Audio Update Files
  • Le nouvel outil ota-builder permet de préparer facilement des fichiers de mise à jour acceptés par l'unité principale
    • Il en est encore à ses débuts, mais par exemple, créer un fichier de mise à jour qui installe un binaire su avec setuid est devenu trivial
  • Il existe de solides raisons de penser que toutes les mises à jour sont signées avec des clés de test AOSP publiques, mais il n'y a pas eu accès à tous les fichiers de mise à jour officiels possibles ni à tous les systèmes de fichiers des variantes d'unité principale
    • Les unités principales vérifiées contenaient bien des clés de test AOSP dans res/keys, mais comme HondaHack avait déjà été installé, il est possible que des clés aient été injectées dans le keystore
    • Le fichier de mise à jour logicielle UE publiquement disponible MRC_EU_SW_v12_4.zip est signé avec des clés de test ; il a été téléchargé depuis un forum public et n'a pas été modifié
    • Il est très probable que toutes les mises à jour soient signées avec des clés de test AOSP, mais des contributions sont nécessaires pour étayer ou réfuter cette hypothèse

Construction des outils

  • En dehors du processus de mise à jour, le travail le plus utile a été le développement de apk-rebuilder
  • apk-rebuilder prend en entrée des fichiers de mise à jour de Honda Civic trouvés sur Internet et produit une arborescence de sortie propre qui automatise le travail qu'un spécialiste de la rétro-ingénierie devrait autrement faire à la main
    • Il effectue l'interprétation des ressources
    • Il effectue la reconstruction du code .smali
    • Il effectue le reconditionnement des fichiers APK
    • Il effectue l'extraction du ramdisk
    • Et d'autres opérations encore
  • Comme le vrai code source Honda ne peut pas être publié, apk-rebuilder sert de fonction prenant en entrée des fichiers de mise à jour que le dépôt public n'héberge pas, pour produire le code .smali Honda, les ressources d'image et autres éléments
  • Les sorties générées suivent une structure de répertoires claire et peuvent être référencées dans la documentation sans téléverser les fichiers sensibles eux-mêmes

Travail restant et appel à contributions

  • Versions connues

    • Le processus de mise à jour est vulnérable et dépend fortement du numéro de version
    • Le numéro de version peut être usurpé, il ne limite donc pas la capacité à exécuter du code non signé
    • Pour créer un fichier de mise à jour, il faut connaître la version attendue par l'unité principale
    • Des modifications du logiciel de l'unité principale qui ne correspondent pas au build en cours peuvent entraîner un comportement inattendu et une recovery loop
    • Les personnes qui conduisent une Honda Civic de 10e génération et sont à l'aise avec la technique peuvent contribuer à la section Known Versions, Display Audio Software du dépôt
    • Les plus audacieuses peuvent lire le code de ota-builder et tenter de flasher une mise à jour, mais si l'unité principale diffère de l'appareil de référence, elle peut entrer dans une recovery loop et être soft-brickée

  • Toolchain

    • Une toolchain expérimentale et en cours de construction existe sur la machine locale
    • Cette toolchain prend du code .c candidat et le compile pour ARMv7 avec la même version de compilateur et les mêmes flags de build que le binaire fournisseur d'origine
    • Cette toolchain a été essentielle pour comprendre le processus de mise à jour
    • Dans sa forme actuelle, elle utilise beaucoup Docker, reste désordonnée et très adaptée à un workflow spécifique, et l'objectif est de publier une implémentation propre

  • Thèmes personnalisés

    • En faisant du vibe-coding sur apk-renderer, une exploration partielle des thèmes personnalisés a été menée
    • Les thèmes personnalisés se trouvent dans le fork du framework AOSP de Mitsubishi, et les applications de l'unité principale semblent réduites de manière à attendre des ID de ressources codés en dur, ce qui risque de compliquer fortement le déploiement
    • Déployer des thèmes personnalisés nécessitera probablement de modifier chirurgicalement le framework fournisseur et d'écrire des outils pour automatiser cela
    • Ce travail n'est ni simple ni forcément suffisamment utile pour justifier l'effort, mais les contributions sont les bienvenues

  • Amélioration de aidl-rebuilder

    • Le travail a commencé sur un outil qui parse les fichiers .smali pour générer et cartographier toutes les interfaces AIDL de l'unité principale
    • L'outil fonctionne, mais sa précision n'a pas encore pu être suffisamment vérifiée
    • Ce travail ouvre la voie à des applications personnalisées comme un compteur de vitesse virtuel

Réflexions sur la documentation et les LLM

  • L'accent est mis davantage sur l'outillage que sur les documents de référence
  • Si des outils fiables et déterministes mappent le code de l'unité principale vers une forme plus facile à comprendre, les utilisateurs peuvent interroger cette forme avec un LLM pour obtenir des réponses à des questions précises
  • Comme le code de l'unité principale est la source de vérité, cela réduit la charge liée au maintien de documents de référence susceptibles de diverger du code réel
  • Un guide utilisateur expliquant comment se connecter à l'unité principale via ADB reste utile
  • Quand le code Java lui-même peut être exploité par un LLM, maintenir séparément une documentation sur le comportement du code Java devient une charge de maintenance

Conclusion

  • L'essentiel du travail d'investigation prévu sur l'unité principale est terminé
  • Cela pourrait rester un projet sur lequel continuer à s'investir, mais il est probable qu'un passage à d'autres projets ait lieu désormais
  • Le dépôt n'est pas à l'arrêt, et les PR sont toujours les bienvenues

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News
  • La mise à jour de la Honda Civic de 10e génération est distribuée par Honda via une clé USB à format spécial, et il s’agit en pratique d’un paquet de restauration de l’époque d’Android 4.2.2rc1 auquel Honda a seulement ajouté une vérification de version
    Cette vérification de version peut être contournée, et le paquet est signé avec les clés de test AOSP publiques, donc avec un accès physique au port USB avant il est possible de signer et flasher un paquet arbitraire, puis d’exécuter du code arbitraire sur l’unité principale
    pas besoin de root/su, cela a été testé jusqu’au bout sur une Civic 2021, et il a aussi été vérifié séparément que les fichiers de mise à jour officiels de l’UE utilisent eux aussi une signature par clé de test AOSP
    • AOSP signifie Android Open Source Project
    • Les unités principales Acura de la même période sont elles aussi basées sur Android 4.x, donc quelqu’un a voulu les analyser aussi, mais s’est retrouvé bloqué au moment d’obtenir les fichiers de mise à jour, et se demande comment ceux-ci ont été récupérés
    • Les systèmes d’infodivertissement d’autres voitures sont eux aussi assez souvent basés sur AOSP. En téléchargeant une mise à jour Hyundai, quelqu’un se souvient qu’il s’agissait en fait pratiquement d’une image Android
  • La plupart des voitures sur la route ont une sécurité de l’infodivertissement et de l’électronique embarquée médiocre, et avec les micros, caméras, récepteurs GNSS, Wi-Fi et Bluetooth présents dans les voitures récentes, elles se transforment peu à peu en plateformes de surveillance mobiles
    Dans l’Information Security Manual du gouvernement australien de mars 2026, un contrôle a été ajouté pour recommander de ne pas connecter d’appareils gouvernementaux à l’infodivertissement d’un véhicule, et de ne pas consulter de documents sensibles ni tenir de conversations sensibles dans ou à proximité d’un véhicule connecté
    https://www.cyber.gov.au/business-government/asds-cyber-secu...
    • NC n’est-il pas le niveau le plus bas dans l’échelle de sensibilité ?
    • Cela paraît acceptable. C’est l’autoradio de la voiture, pas un système central
      Les personnes susceptibles d’être vulnérables à ce genre d’attaque disposent déjà de procédures de travail et d’équipements de confiance distincts, et les agences de police américaines appliquaient déjà des règles comparables pour les voitures de location depuis l’arrivée d’OnStar
      La plupart des données télématiques dangereuses pour le grand public sont de toute façon déjà vendues
  • D’un côté, on lutte contre la diminution continue de la propriété matérielle sur la plupart des appareils de notre quotidien, mais dès qu’un appareil un peu plus ouvert apparaît, il se fait aussitôt attaquer
    En sécurité, le modèle de menace partait depuis toujours du principe que si l’attaquant a un accès physique à l’appareil et du temps, alors c’est terminé
    • Ce n’est pas vraiment ouvert au point que le grand public puisse le modifier, si ? Le fabricant doit choisir une direction : soit ouvrir complètement pour que ceux qui en ont besoin puissent le durcir eux-mêmes et connaître les compromis, soit fermer complètement et rendre le tout sûr
      L’état intermédiaire actuel est le pire : une atteinte à la vie privée qui surveille l’utilisateur pendant tout le trajet, et en même temps un appareil peu sûr qui livre ces données à quiconque s’y intéresse un minimum
    • On voit une situation comparable dans la récente vulnérabilité BitLocker. On peut se demander si du nouveau matériel de conservation maintenant déverrouillable permettra de résoudre de nouvelles affaires ou d’envoyer des gens en prison
      Si les données peuvent être saisies, mieux vaut ne pas les stocker localement, et selon la loi on peut aussi être forcé à déverrouiller, mais aux États-Unis on devrait être protégé en refusant de fournir son mot de passe
      Techniquement, Google et Apple ont beaucoup amélioré la sécurité physique, et GrapheneOS va encore plus loin sur cette base en réduisant la surface d’attaque et en ajoutant de bonnes fonctionnalités. Avec notamment l’adoption large du redémarrage automatique, on peut désormais nuancer sur les téléphones la conclusion selon laquelle « accès physique = partie terminée »
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • Cela ne veut pas dire qu’il faille abandonner la sécurité des appareils locaux. Les appareils physiques ont aussi une sécurité de connexion, et utilisent peut-être même le chiffrement complet du disque
      Ce n’est pas parce qu’un attaquant suffisamment sophistiqué et persévérant peut prendre le contrôle de n’importe quel appareil avec un accès physique qu’il faut pour autant le rendre facile pour tout le monde
  • Honda paraît ici bien plus raisonnable que les autres constructeurs automobiles
    Un voiturier malveillant ayant un accès physique à la voiture ne perdrait pas son temps à pirater l’unité principale ; il cacherait simplement un dispositif d’écoute quelque part dans le véhicule
    Et puis un conducteur de Civic a peu de chances d’être la cible de services de renseignement
    • Je ne sais pas si c’est une blague, mais cela n’a pas beaucoup de sens. Il est aussi peu probable que Honda ait conçu cela intentionnellement
      L’unité principale contient généralement des données historiques comme une base SQLite de contacts restés après synchronisation, un historique de localisation, ou d’anciennes données laissées dans la télémétrie ou les fichiers journaux
      En outre, l’unité principale a souvent accès aux bus internes du véhicule, et même lorsqu’il existe un pare-feu comme un module Gateway, il est généralement faible. Comme dans le cas célèbre chez Honda où le déverrouillage et l’autorisation de démarrage étaient possibles sans matériel cryptographique via le bus CAN des phares, l’infodivertissement peut être bien plus puissant qu’un simple dispositif de suivi
      De plus, injecter du code dans l’unité principale ou extraire les données déjà présentes laisse beaucoup moins de traces que de fixer un traceur séparé
    • Si c’est ironique, d’accord, mais sinon je ne vois pas pourquoi un conducteur de Civic ne pourrait pas être une cible des services de renseignement
      La Civic est l’une des voitures les plus courantes, donc idéale pour se fondre dans le décor, et des personnes « en apparence ordinaires » comme des scientifiques, ingénieurs, journalistes ou avocats peuvent très bien conduire une Honda Civic
      Un dispositif d’écoute caché dans la voiture peut être découvert, mais quelque chose directement installé dans le firmware du véhicule a encore moins de chances d’être trouvé
    • Vous pensez qu’un scientifique ou un ingénieur ennuyeux ayant accès à des informations confidentielles ne va pas au travail dans une Civic banale ?
  • Quelqu’un a déjà entendu un chef de produit déclarer fièrement que le firmware avait été signé par le service de signature interne de l’entreprise. En soi, c’est bien
    Mais la vraie question posée était de savoir si le firmware était signé pour satisfaire une obligation interne, pas si la procédure de mise à jour du firmware vérifiait la signature, et en réalité elle ne vérifiait rien du tout
    • Quelqu’un a déjà vu une « solution » similaire : l’algorithme de signature était exécuté directement depuis le paquet de mise à jour

« Sinon, comment mettre à jour l’algorithme de signature ? », en gros — et le pire, c’est qu’à une époque c’était correctement fait
Le mode de signature a changé quand l’équipe sécurité a exigé des signatures « post-quantiques sûres », et c’est là qu’un bug de régression a été introduit

  • Avec un nom comme BobbyTables2, j’aurais pensé qu’il penserait tout de suite à la bonne façon de vérifier les signatures PGP des e-mails
  • Je pense qu’il y a une limite entre la sécurité et le fait de garder des appareils utiles sur le long terme. La menace qu’une attaque de type femme de chambre malveillante installe un malware d’écoute dans une voiture paraît faible
    Mais quand ces voitures auront plus de 10 ans et passeront à des gens qui voudront les bidouiller, la capacité d’ouvrir le logiciel et de le personnaliser sera un énorme avantage
    Ce serait bien de voir émerger une communauté qui crée des modifications utiles et prolonge la durée de vie de l’appareil. Ça me semble bien préférable à un utilisateur final qui arrache l’unité principale d’origine pour la remplacer par une unité façon « tablette Android » d’Aliexpress, probablement pire que l’appareil de Honda en matière de sécurité et de qualité d’ingénierie
  • Cela peut aussi être un bon signe qu’ils n’avaient même pas l’intention de verrouiller le système contre le propriétaire
    • Autoriser n’importe qui entre brièvement dans la voiture à obtenir un accès root n’est pas une bonne chose. C’est comparable à laisser au bureau un ordinateur portable toujours allumé avec un shell ouvert
      Si l’on ne va pas faire confiance à toutes les mises à jour par défaut, il aurait fallu fournir un mécanisme permettant au vrai propriétaire d’approuver les mises à jour
    • Il est plus probable que ce soit le résultat d’une incompétence qu’une volonté d’être favorable aux hackers
      Si c’était vraiment intentionnel, il y aurait eu quelque chose comme un bootloader déverrouillable nécessitant une clé spéciale, ou un interrupteur difficile d’accès
  • Faire de la voiture un énorme ordinateur sur roues était peut-être une mauvaise idée. Des recherches supplémentaires sont nécessaires
  • Je me demande à quel point le reste de la sécurité tient la route. L’unité principale est probablement connectée à une passerelle CAN ; peut-être qu’on peut l’appeler via la télématique, ou qu’il existe une nouvelle façon d’exploiter CarPlay/Android Auto pour lui faire communiquer avec la maison
    • Si vous avez un accès physique à la voiture et que vous voulez qu’elle communique avec la maison, je recommanderais de mettre un traceur GPS sous le tapis de sol
      Ça marcherait sur plus de marques qu’une méthode qui ne fonctionne que sur une seule génération de Honda Civic, et ce serait probablement plus rapide à installer
  • Je vois de plus en plus de projets réduire la documentation du code en partant de l’idée que « du code bien conçu peut être interrogé avec un LLM », et se concentrer à la place sur une documentation procédurale fonctionnelle
    À un instant donné, il y a très peu de chances que toute la documentation d’un projet soit réellement à jour avec le code
    Globalement, je suis d’accord avec cette direction, mais à condition que le code soit effectivement bien conçu
    • Mieux vaut considérer les tests unitaires comme de la documentation plutôt que la documentation elle-même
      Les tests peuvent montrer l’usage prévu et des cas limites intéressants, et comme ils continuent d’être exécutés et de passer, on sait aussi qu’ils sont à jour
      C’est un avantage majeur trop souvent sous-estimé quand on ajoute davantage de tests
      Si un développeur risque de poser des questions sur un comportement ou un cas limite, il vaut mieux avoir un test qui permette de prouver directement la réponse plutôt que de l’obliger à tout redéduire