Contexte de l’incident
Un utilisateur de Home Assistant a ouvert le ticket GitHub n°49314 en indiquant « I never authorized an integration that scans my secrets ». Le message signale qu’une intégration, non approuvée par le propriétaire du compte, aurait accédé à des données sensibles stockées dans le système. Aucun détail supplémentaire n’est fourni dans le ticket, ce qui limite la visibilité sur la nature exacte de l’intégration ou sur le moment où l’accès a eu lieu.
Mécanisme d’intégration et gestion des secrets
Home Assistant utilise un modèle d’extensions où chaque intégration s’exécute dans le même processus que le cœur du serveur. Les secrets (tokens, mots de passe, clés API) sont conservés dans le fichier secrets.yaml ou dans le magasin de chiffrement interne. L’accès à ces valeurs se fait via l’API interne hass.config.secrets, qui ne comporte pas de contrôle d’autorisation granulaire par intégration. Ainsi, lorsqu’une intégration est chargée, elle hérite des mêmes privilèges que le noyau, ce qui explique comment une extension non désirée peut « scanner » les secrets si elle est activée.
Le processus d’ajout d’une intégration repose sur le fichier configuration.yaml ou sur l’interface UI. Une fois la configuration enregistrée, Home Assistant recharge les modules sans demander de confirmation supplémentaire. Cette absence de validation explicite constitue le point d’entrée potentiel décrit dans le ticket.
Analyse des risques et recommandations
Le fait qu’une intégration puisse lire les secrets sans consentement explicite expose le système à plusieurs vecteurs d’attaque. Premièrement, un code malveillant intégré pourrait extraire les tokens et les transmettre à un serveur distant, compromettant les services connectés (ex. : plateformes cloud, API tierces). Deuxièmement, la visibilité sur les secrets facilite le contournement de mécanismes d’authentification, augmentant la surface d’exposition.
En l’absence de données précises sur l’intégration incriminée, il est recommandé de renforcer la chaîne de confiance autour du chargement des modules : implémenter une vérification d’intégrité (signature) pour chaque intégration, introduire une demande de confirmation lors de l’activation d’une nouvelle extension, et restreindre l’accès aux secrets via un rôle limité. De plus, la migration des secrets vers un coffre‑à‑sangues externe (ex. : HashiCorp Vault) permettrait de séparer les privilèges d’exécution des données sensibles.
Enfin, la communauté doit documenter les cas d’usage où une intégration nécessite réellement l’accès aux secrets, afin de créer une liste blanche et de réduire les faux positifs. Cette démarche, combinée à une surveillance accrue des logs d’accès aux secrets, offrirait une visibilité opérationnelle suffisante pour détecter rapidement toute activité non autorisée.
