LuxHawk.lu (+352) 27 52 67 45

← Retour aux connaissances

La GTB et la domotique : le cerveau du bâtiment livré à Internet

Bâtiment et copropriété 11 min Auteur : Arnaud Colin Mis à jour : 19/09/2026

Résumé

Une GTB ou une domotique d’immeuble devient attaquable dès que sa passerelle ou son interface de supervision répond depuis Internet. En 2021, des installations KNX ont été verrouillées par une clé posée par l’attaquant (CVE-2023-4346, score 7,5, sans correctif possible) ; en 2013, la supervision d’un immeuble de Google à Sydney a été lue grâce à des failles corrigées neuf mois plus tôt. Avant de signer, il faut exiger une télémaintenance derrière VPN, une clé BCU posée et remise au propriétaire avec le projet, la dépose des passerelles de chantier et un responsable nommé pour les mises à jour.

Un immeuble se pilote désormais par le réseau

Dans un immeuble récent, l’éclairage des parties communes, les volets, la ventilation, le chauffage et parfois les portes sont reliés à une installation commune : la gestion technique de bâtiment (GTB) dans le tertiaire, la domotique dans le résidentiel. Cette installation a un cerveau — des automates, une supervision — et, de plus en plus souvent, une passerelle qui permet à l’installateur d’intervenir sans se déplacer. La commodité est réelle. La question qu’un syndic, un gérant ou un dirigeant doit se poser est ailleurs : que se passe-t-il lorsque cette passerelle est joignable depuis Internet par quelqu’un d’autre que l’installateur, et comment le vérifier avant de signer ?

Deux cas documentés y répondent avec précision. Le premier, en Europe germanophone à partir de 2021, a rendu inutilisables les trois quarts des composants d’un immeuble de bureaux sans qu’aucune rançon soit demandée. Le second, à Sydney en 2013, a donné à deux chercheurs la main sur la supervision d’un immeuble de Google, neuf mois après la publication du correctif qui aurait suffi à l’empêcher.

KNXlock : l’immeuble verrouillé par sa propre clé (2021-2026)

KNX est un standard d’automatisation du bâtiment largement déployé en Europe, comme le rappelle Dark Reading. Chaque composant — interrupteur, détecteur de mouvement, commande de volet — peut être protégé par une « clé BCU », un mot de passe de programmation de quatre octets destiné à empêcher un tiers de reprogrammer l’installation. La campagne dite KNXlock retourne cette protection contre le propriétaire.

En octobre 2021, un bureau d’études allemand, selon Dark Reading, contacte la société autrichienne Limes Security après avoir perdu la main sur l’installation KNX d’un immeuble de bureaux de son client — « un site de taille moyenne », écrit Limes dans son compte rendu. À la mi-décembre 2021, un second bureau d’études européen signale un cas identique ; l’attaquant est entré par une passerelle IP de chantier oubliée, rapporte Dark Reading. Le 30 mars 2023, la technique est ajoutée à la base MITRE ATT&CK for ICS sous la référence T0892, « Change Credential ». Le 24 août 2023, l’agence américaine CISA publie l’avis ICSA-23-236-01 : la vulnérabilité reçoit l’identifiant CVE-2023-4346, score CVSS 7,5, et l’agence écrit avoir reçu des signalements d’exploitation active. Le 30 janvier 2024, Limes décrit une variante de la campagne, avec des clés aléatoires et des messages « system hacked bcu key … », qui touche des particuliers comme des exploitants ; la société publie à cette occasion l’outil KNXunlocker. Le 15 juillet 2026, enfin, la CISA inscrit CVE-2023-4346 à son catalogue des vulnérabilités exploitées, avec une échéance de traitement au 29 juillet 2026 (directive BOD 26-04).

Le vecteur tient en une ligne : une passerelle KNXnet/IP exposée sur Internet. L’attaquant « décharge » les composants, puis pose une clé BCU qu’il est seul à connaître. La CISA classe le défaut comme un mécanisme de verrouillage trop restrictif (CWE-645) et précise qu’il concerne tous les appareils KNX utilisant le mode d’autorisation « Option 1 Style » sur lesquels aucune clé n’est encore posée, toutes versions confondues. Aucun correctif logiciel n’est proposé : l’avis ne liste que des mesures opérationnelles. Une fois la clé posée par un tiers, la plupart des appareils ne permettent ni de la réinitialiser ni de la récupérer, même avec un accès physique, écrit Limes. Ce qui a rendu l’attaque possible n’est donc pas une prouesse technique, mais deux absences : une passerelle qui n’aurait jamais dû être joignable de l’extérieur, et une clé que l’intégrateur n’avait pas posée.

L’impact, dans le premier immeuble, est matériel. Environ les trois quarts de plusieurs centaines de composants — interrupteurs, détecteurs, commandes de volets ; aucune source ne cite le chauffage ni la ventilation — sont devenus inutilisables. L’immeuble a fonctionné plusieurs semaines sur ses disjoncteurs, et certains composants ont été recâblés. Les quatre fabricants concernés ont répondu qu’ils ne pouvaient pas récupérer la clé. Limes estime que le remplacement du matériel, installation et vérification comprises, aurait coûté plus de cent mille euros. Aucune rançon n’a été demandée et aucun indicateur de rançongiciel n’a été trouvé ; Limes évoque l’hypothèse d’un vandalisme numérique, ou d’un attaquant qui n’a pas su identifier l’exploitant. En août 2023, des balayages d’Alpha Strike Labs, cités par Limes, comptaient plus de 16 000 systèmes KNX potentiellement vulnérables exposés sur Internet dans la zone germanophone.

La réponse a été artisanale. Peter Panholzer et Felix Eberstaller, de Limes, ont extrait physiquement la mémoire du processeur d’un composant — ce qui n’est possible que sur les appareils dépourvus de protection du processeur —, réduit l’espace de recherche et retrouvé la clé par force brute en 45 minutes, la même clé ayant été posée sur tous les composants ; l’installation a ensuite été reprogrammée en trente minutes. KNXunlocker, l’outil publié en 2024, permet une récupération « en quelques heures sur un PC ordinaire » lorsque la clé suit un motif prévisible ; lorsqu’elle ne peut pas être retrouvée, le matériel reste définitivement inutilisable. Les recommandations de la KNX Association, reprises par la CISA, tiennent en deux phrases : toujours poser la clé BCU dans chaque projet KNX, et la remettre au propriétaire du bâtiment avec la documentation du projet.

Tridium Niagara : la supervision d’un immeuble de Google lue depuis Internet (2013)

Tridium Niagara (Honeywell) est la plateforme d’intégration la plus répandue en GTB : elle réunit chauffage, ventilation, éclairage, énergie et contrôle d’accès derrière une interface web. Le cas qui suit n’est pas une démonstration de laboratoire : deux chercheurs ont pris la main sur la supervision d’un immeuble en exploitation.

La chronologie commence un an avant l’intrusion. Le 13 juillet 2012, l’ICS-CERT américain publie l’alerte ICS-ALERT-12-195-01 à la suite d’une enquête du Washington Post citant les chercheurs Billy Rios et Terry McCorkle. Le 15 août 2012, l’avis ICSA-12-228-01 détaille les vulnérabilités et Tridium publie un correctif le même mois. En mai 2013, Rios et McCorkle, alors chez Cylance, repèrent sur Internet la GTB de l’immeuble Wharf 7 de Google à Sydney, rapporte The Register le 6 mai : elle tourne sur une version ancienne de Niagara AX, embarquée sur QNX, qui n’a pas reçu le correctif, environ neuf mois après sa publication.

Le vecteur n’exige aucune vulnérabilité nouvelle : les failles de 2012 suffisent. Une traversée de répertoire sur l’interface web (CVE-2012-4027) donne accès au fichier de configuration config.bog, dans lequel les identifiants de tous les comptes sont stockés (CVE-2012-4028). L’avis en signale deux autres : des identifiants encodés en base64 dans un cookie (CVE-2012-3025) et des identifiants de session prévisibles (CVE-2012-3024). Des exploits publics circulaient, pour plus de 300 000 installations dans le monde. Ce qui a rendu l’attaque possible tient là encore en deux absences : une interface qui n’aurait pas dû répondre depuis Internet, et une mise à jour disponible depuis neuf mois qui n’avait pas été appliquée.

Le déroulé est décrit par SecurityWeek. Les chercheurs récupèrent le fichier de configuration — le mot de passe administrateur était « anyonesguess » — et accèdent aux écrans de supervision : le plan du troisième niveau avec le tracé des canalisations d’eau, l’état des cuisines, dont une fuite en cours dans la cuisine sud, et un bouton « after hours » marqué d’un marteau qu’ils se gardent de tester. Ils disposaient, selon le même article, d’un contrôle complet sur les commandes de sécurité et de chauffage-ventilation de l’immeuble ; ils n’ont rien modifié. L’impact se limite donc à une prise de contrôle démontrée, sans dégât. Cylance indiquait alors avoir trouvé plus de 25 000 systèmes Niagara exposés sur Internet, contre plus de 2 500 lors de la divulgation de 2012. Les chercheurs ont signalé leur découverte à Google par son programme de récompense des vulnérabilités. Le cas est également rapporté par Infosecurity Magazine et The Register. Les sources consultées ne rapportent ni déclaration de Google ni date de déconnexion du système.

Des avis qui continuent de paraître

Ces deux cas n’appartiennent pas au passé. Le 23 juillet 2025, Nozomi Networks a publié treize vulnérabilités, réparties sur dix identifiants (CVE-2025-3936 à CVE-2025-3945, score maximal 7,7 pour CVE-2025-3937), dans les versions 4.10u10 et 4.14u1 de Niagara Framework et antérieures. Elles ne sont exploitables que sur un système mal configuré, chiffrement désactivé ou journalisation Syslog non chiffrée ; Tridium a corrigé et aucune exploitation n’a été constatée. Le 10 mars 2026, la CISA a publié l’avis ICSA-26-069-03 sur les contrôleurs Honeywell IQ4x : CVE-2026-3611, score 9,8, une interface web sans authentification par défaut, sans exploitation publique connue. Ce sont des risques, pas des incidents ; ils rappellent que la question des mises à jour ne se règle pas une fois pour toutes.

Le BSI, l’office fédéral allemand de la sécurité de l’information, décrit le même paysage dans un avertissement du 4 avril 2023 issu d’un test de terrain, sans nommer KNX : des accès de télémaintenance posés par les prestataires et non documentés, une absence de gestion des correctifs, une GTB laissée hors du périmètre de sécurité de l’organisation, et un risque de manipulation des asservissements de portes et de détection incendie — tout en indiquant n’observer « pas encore d’incidents graves ».

Ce que cela apprend à un immeuble ou une copropriété au Luxembourg

Au 18 septembre 2026, aucun cas luxembourgeois de piratage de GTB ou de domotique d’immeuble n’est documenté dans une source de premier rang. Les 16 000 systèmes KNX potentiellement vulnérables exposés dans la zone germanophone voisine ne l’étaient pas en raison de leur pays, mais parce que leur passerelle répondait depuis Internet. Les gestes qui suivent découlent directement des deux cas.

  • Au contrat et à la réception du chantier : exiger que l’intégrateur pose la clé BCU sur chaque composant et la remette au propriétaire, documentée, avec le fichier de projet ETS. La KNX Association et la CISA le formulent ainsi ; sans cela, le premier venu pose la clé à votre place, et la récupérer n’est pas garanti.
  • La passerelle « temporaire » de chantier : c’est par elle qu’est entré le second cas de 2021. L’inscrire à l’inventaire et exiger sa dépose au procès-verbal de réception.
  • Aucune passerelle KNX/IP ni interface de supervision joignable depuis Internet : la télémaintenance passe par un VPN, et le réseau technique est séparé de la bureautique du syndic comme du wifi des résidents. Une supervision accessible de l’extérieur peut être trouvée par un moteur de recherche d’appareils ; celle de Sydney a été repérée depuis Internet.
  • Les mises à jour ont un responsable : le correctif Niagara existait depuis août 2012 et n’était pas appliqué neuf mois plus tard. La question à poser au syndic ou au gestionnaire technique est simple : qui met à jour la supervision, et quand ?
  • Le fichier de configuration est le trousseau de l’immeuble : un mot de passe administrateur comme « anyonesguess », ou une interface livrée sans authentification comme la CISA le relève sur les Honeywell IQ4x, se change avant la mise en service, pas après.
  • Une copie du projet et de la clé hors de l’installation : conservée par le propriétaire, pas seulement par l’installateur, de façon à pouvoir reprogrammer l’installation si celui-ci disparaît ou cesse son activité.
  • Un mode dégradé connu de tous : l’immeuble de 2021 a vécu plusieurs semaines sur ses disjoncteurs. Savoir qui rallume la lumière, ouvre les volets et remet la ventilation en marche sans la domotique fait partie du plan de continuité, au même titre que la clé mécanique d’une porte.
  • Pour CVE-2023-4346, il n’y a pas de correctif : seule l’architecture protège — pas d’exposition sur Internet, clé posée, et KNX Secure pour les installations neuves.
  • Le vandalisme numérique existe : aucune rançon n’a été demandée en 2021, et l’immeuble était pourtant en panne. Raisonner uniquement en termes de fraude ou de rançon laisse ce scénario de côté.
  • Une exploitation reconnue par une autorité : la CISA l’a écrit dès août 2023 et n’a inscrit la vulnérabilité à son catalogue qu’en juillet 2026. Attendre l’inscription officielle pour agir aurait signifié attendre trois ans.

La notion de vulnérabilité, de score et de correctif est expliquée dans l’article Qu’est-ce qu’une faille de sécurité informatique ?.

Sources