Deux chercheurs ont pris la main sur des comptes utilisateurs en découvrant une console oubliée derrière un pare-feu mal appliqué. Des identifiants d’usine ont permis d’ouvrir les portières, démarrer les moteurs et modifier les notifications. La faille a été corrigée en deux heures, rappelant l’urgence de verrouiller les interfaces internes hors production.
La sécurité de millions de véhicules connectés a encore révélé des faiblesses inattendues. Deux experts ont pris le contrôle total des comptes clients de deux marques, puis déverrouillé les portières et lancé les moteurs à distance. Rien de mystérieux, aucun matériel particulier. Le point d’entrée était la combinaison la plus ancienne de l’histoire de l’informatique: « admin » comme utilisateur et mot de passe.
Le problème venait de la couche de gestion des identités partagée par les applications mobiles des deux marques, bâtie sur la plateforme ForgeRock. En étudiant le trafic, les experts ont trouvé une console administrative Apache Felix Web Console oubliée sur le serveur OpenIDM. Cet outil interne aurait dû être désactivé ou protégé avant la mise en production, mais il est resté accessible avec les identifiants par défaut.
Un filtre de sécurité dupé a ouvert les portes
La console n’était en principe pas exposée au public, une barrière de sécurité applicative devait bloquer les requêtes externes. Le souci tenait à une divergence d’analyse des chemins entre le serveur et le filtre. Quelques caractères spéciaux et barres codées dans l’URL ont suffi pour faire passer la demande comme un fichier statique anodin. En arrière-plan, le serveur web a traité l’adresse réelle et remis le tableau de bord sur un plateau.
Une fois à l’intérieur, les chercheurs ont employé le planificateur de tâches pour injecter et lancer leurs propres scripts directement sur le serveur abritant les fiches clients. Cet accès leur a donné des droits d’administration locaux, franchissant toutes les barrières réseau. À ce niveau de contrôle, l’équipe pouvait lire et modifier les données de n’importe quel compte lié aux deux constructeurs.
Du serveur aux clés du véhicule
Avec les commandes système en main, les experts ont modifié l’adresse e-mail et le mot de passe d’un compte d’essai. Ils ont ensuite réalisé une connexion normale via l’application mobile officielle, obtenant les jetons d’accès légitimes. Pour le système du véhicule, la demande semblait provenir du véritable propriétaire.
Les essais de validation se sont déroulés aux États-Unis sur des véhicules personnels et sur ceux de volontaires ayant autorisé la procédure. À proximité du véhicule réel, les analystes ont transmis des commandes distantes via l’API officielle: déverrouillage des portières, démarrage du moteur, puis nouveau verrouillage complet. Le titulaire initial ne recevait même pas d’alerte sur son téléphone, car les notifications pouvaient être redirigées discrètement côté serveur.
Des failles parallèles ont permis de reproduire des commandes identiques sur des systèmes destinés aux marchés australien et canadien, à cause d’identifiants de test laissés dans le code de l’application. Les deux constructeurs ont corrigé les autorisations et renouvelé les clés touchées environ deux heures après l’alerte. La leçon reste claire pour les administrateurs systèmes: compter seulement sur un pare-feu pour masquer une interface critique dotée de mots de passe d’usine ne constitue pas une stratégie de défense viable.