Voitures : de la plaque au déverrouillage à distance

Ce qui se passe

Shubham « Shubs » Shah et Sam Curry ont publié la chaîne qui leur permettait, à partir de la seule plaque d'immatriculation, d'envoyer des commandes à distance — déverrouillage, klaxon, moteur — à n'importe quel véhicule d'un constructeur. Le constructeur est volontairement anonymisé ; l'étude a porté sur des voitures que les chercheurs possédaient ou avaient l'autorisation de tester. L'angle n'est pas matériel : tout passe par les services web de la plateforme connectée.

Comment la chaîne se monte

Le point de départ est l'application mobile, décompilée depuis son APK pour reconstituer ses appels d'API. En Australie, une plaque donne le VIN (numéro de série) via les fichiers d'immatriculation ; une API du constructeur transforme ce VIN en identifiant d'abonné (GUID), puis en compte client avec l'adresse e-mail (/v1/account).

Reste à prendre la main sur le compte. Le système d'identité repose sur ForgeRock OpenIDM. Un bundle JavaScript tiers, livré au navigateur, contenait en clair les identifiants administrateur d'OpenIDM. Un pare-feu applicatif (Nginx) bloquait les API sensibles sous /openidm/, mais seulement certains préfixes : /XUI/..%2fopenidm/ renvoyait un 403, alors que /static%2f..%2fopenidm/ n'était pas couvert — un chemin trouvé par un modèle (GPT 5.6) après environ six heures d'analyse du code source d'OpenIDM. De là, une requête PATCH réécrit le mot de passe de n'importe quel compte :

PATCH /static%2f..%2fopenidm/managed/user/<id> HTTP/1.1
Host: openidm.<constructeur>.com.au
X-OpenIDM-Username: idmadmin
X-OpenIDM-Password: <REDACTED>
Content-Type: application/json

[{"operation":"replace","field":"/password","value":"Testing123!"}]

La double authentification est ensuite sautée : un jeton obtenu par le flux OAuth Resource Owner Password Credentials (grant_type=password) se rééchange, étape par étape (jeton d'identité → session → code d'autorisation), contre un jeton d'application. Avec ce jeton, la dernière requête ouvre les portes :

POST /v1/remote/route/command HTTP/1.1
Host: api.<constructeur>.com.au
Authorization: Bearer <app_access_token>

{"command": "door-unlock", "autoFixPopup": false, "beepCount": null}

Une variante plus complexe, documentée par Sam Curry, étend la prise de contrôle aux États-Unis et au Canada, où les environnements OpenIDM étaient mieux protégés.

Ce que ça change

Aucune étape n'est exotique : chacune est une erreur de configuration classique, mise bout à bout. Les trois leçons sont transférables à toute application web :

1. Un secret dans un bundle JavaScript est public. Le navigateur reçoit tout le fichier ; des identifiants admin « de staging » y sont donc lisibles, et ils marchaient en production.
2. Un pare-feu ne corrige pas une API d'administration exposée. L'investissement en règles WAF trahissait un problème connu qu'on masquait ; une traversée de chemin a suffi à passer outre.
3. Une double authentification qu'on peut sauter ne protège rien. Le flux ROPC rendait le facteur supplémentaire optionnel.

Source : shubs.io, en anglais.