Le jeton GitHub fuité d'une caméra révèle un problème récurrent de l'IoT

Un internaute qui inspectait la page de connexion web d'une caméra de sécurité de marque Hanwha est tombé sur quelque chose qui n'aurait jamais dû s'y trouver : un jeton d'administration GitHub parfaitement fonctionnel, exposé en clair dans le code côté client de la page. Cette découverte, partagée sur Hacker News sous le titre « My security camera shipped a GitHub admin token in its login page », illustre à petite échelle l'une des failles les plus courantes — et les plus évitables — de l'industrie des objets connectés : un secret censé rester sur un serveur se retrouve à la portée de quiconque clique sur « afficher le code source » dans son navigateur.

Le mécanisme qui mène à ce genre de fuite est presque toujours banal plutôt qu'exceptionnel. Pendant le développement, les ingénieurs configurent fréquemment des scripts ou des utilitaires de débogage avec de vraies informations d'identification pour tester rapidement contre des services réels : un jeton GitHub pour un dépôt privé, une clé d'API pour un tableau de bord dans le cloud, un mot de passe pour des données de test. Le problème survient lorsque ce même code, identifiants toujours attachés, se retrouve intégré à ce qui part en production — une image de micrologiciel, une application mobile ou, comme ici, le JavaScript que la caméra sert au navigateur lors de la connexion.

Laisser traîner un jeton d'administration GitHub n'est pas un détail anodin. Selon son périmètre, il peut donner un accès en lecture et en écriture à des dépôts de code source privés, la capacité de pousser de nouveaux commits, de gérer des webhooks, de modifier la configuration CI/CD, voire d'ajouter ou de retirer des collaborateurs. Pour un fabricant de matériel, cet accès au dépôt ne signifie pas seulement « quelqu'un pourrait lire notre code » — c'est une porte ouverte sur les systèmes qui compilent et signent le logiciel exécuté sur chaque appareil vendu par l'entreprise.

C'est précisément ce qui transforme un jeton GitHub divulgué d'une simple gêne en un risque pour la chaîne d'approvisionnement logicielle. Si un attaquant peut soumettre du code à un dépôt de micrologiciel ou altérer une chaîne de compilation, il ne s'attaque plus à une seule caméra, mais potentiellement à chaque exemplaire qui téléchargera une future mise à jour. Des compromissions de chaîne d'approvisionnement de ce type précis — où une infrastructure de mise à jour légitime sert à diffuser du code malveillant — comptent parmi les incidents de sécurité les plus dommageables de la dernière décennie, bien au-delà de l'électronique grand public.

Les secrets codés en dur continuent d'apparaître dans les produits livrés parce que les incitations qui les produisent sont structurelles, non accidentelles. Les équipes de développement travaillent sous la pression des délais, le firmware IoT est vendu comme un produit mais construit avec les habitudes informelles d'outils internes, et il est facile de supposer que « personne ne regarde ce code » lorsque le public visé est une page de connexion livrée avec un appareil. En réalité, le JavaScript côté client, les binaires d'applications mobiles et les images de micrologiciel sont entièrement extractibles par quiconque fait preuve d'une curiosité technique modeste — un secret cesse d'être « caché » dès qu'il a quitté le serveur.

Ce type de découverte survient généralement par l'une de quelques voies familières : un chercheur ou un amateur ouvre par curiosité les outils de développement de son navigateur, quelqu'un exécute la commande « strings » sur une image de micrologiciel extraite, ou un outil automatisé d'analyse de secrets — y compris ceux que GitHub exécute lui-même sur les dépôts publics et privés — signale un motif de jeton avant ou après qu'il devienne public. Des plateformes communautaires comme Hacker News sont devenues un lieu privilégié pour ce genre de révélations, car un seul utilisateur curieux muni du panneau d'inspection de son navigateur peut trouver ce qu'un audit formel aurait pu manquer.

Une fois un jeton codé en dur découvert, la réponse à l'incident immédiat est simple, quoique urgente : révoquer ou renouveler sans délai l'identifiant exposé, vérifier précisément à quoi il donnait accès, et examiner s'il a déjà servi à quelque chose d'inattendu. La question la plus difficile est de savoir combien de temps le jeton est resté là sans être remarqué, et s'il était limité à un périmètre assez étroit pour que les dégâts, en cas d'usage malveillant, restent contenus — c'est précisément le choix de conception que la plupart des organisations font mal.

Une pratique responsable part d'un principe simple : rien de ce qui atteint un appareil final ou le navigateur d'un utilisateur ne devrait jamais contenir un identifiant capable de rebondir vers des systèmes internes. Cela signifie utiliser des outils dédiés de gestion des secrets ou des coffres-forts numériques pour conserver les identifiants côté serveur, les injecter dans les services au moment de l'exécution plutôt qu'au moment de la compilation, et émettre des jetons limités au périmètre le plus étroit possible pour la tâche la plus étroite possible, plutôt que de réutiliser un jeton d'administration à large portée simplement parce que c'était pratique pendant le développement.

Pour les fabricants de caméras de sécurité en particulier, l'enjeu est plus lourd encore. Ce sont des appareils vendus explicitement sur la promesse de protéger ceux qui les achètent, souvent avec une vue directe sur des domiciles ou des commerces. Dans ce cas précis, la faille liée à l'identifiant codé en dur n'expose pas les images de la caméra, mais elle témoigne de la même négligence sous-jacente qui, lors d'autres incidents dans le secteur, a exposé des flux vidéo en direct, des mots de passe par défaut et des réseaux locaux non chiffrés — un schéma qui a fait du matériel de sécurité « intelligent » un sujet récurrent de la recherche en sécurité plutôt qu'une exception.

Rien de tout cela n'exige une ingénierie exotique pour être évité. Des outils d'analyse de secrets qui bloquent un commit avant sa fusion, des listes de vérification de revue de code qui demandent explicitement « ceci touche-t-il un identifiant ? », et une règle générale selon laquelle rien de ce qui est livré à un client — micrologiciel, application ou page web — ne devrait bénéficier de plus d'accès que le client lui-même, permettraient de repérer l'immense majorité des cas comme celui-ci. La caméra en question n'est qu'un incident isolé, mais le schéma qu'elle illustre est celui que chaque fabricant d'objets connectés continuera de rencontrer tant que la gestion des secrets ne sera pas aussi routinière que n'importe quel autre poste d'un processus de compilation.