Rechercher

S’introduire dans un bâtiment depuis l’armoire électrique

Vous le savez déjà : nous pouvons désormais interconnecter à peu près toutes nos infrastructures et tous nos objets du quotidien au réseau local ou à Internet, que ce soit à des fins d’automatisation ou de contrôle centralisé.

Cela est également vrai pour les infrastructures et les composants liés au fonctionnement d’un bâtiment : souvent la gestion de la lumière, du chauffage, de la climatisation ; parfois les ascenseurs, le contrôle d’accès, la détection incendie, la mesure de la qualité de l’air, etc. On appelle cela la Gestion Technique de Bâtiment (GTB) ou la Gestion Technique Centralisée (GTC) et on peut la trouver dans de nombreux types de bâtiments : chez vous (ce qu’on appelle la domotique), dans vos bureaux, dans les parkings, les usines, les tunnels, les hôpitaux, les écoles ou tout autre type de bâtiment. Mais connecter ces infrastructures, c’est aussi les exposer : et rendre accessible depuis un réseau local – voire depuis Internet – des infrastructures qui ne l’étaient pas, et pour lesquelles la question de la cybersécurité ne s’était pas ou peu posée jusque-là. Nous exposons donc des infrastructures sensibles, qui permettent potentiellement d’assurer la sécurité des installations et des personnes, et dont le niveau de cybersécurité n’a pas été pensé pour cet usage.

Cet article vous propose un tour d’horizon de la cybersécurité des systèmes de Gestion Technique de Bâtiment (GTB) : Quelles sont les vulnérabilités de ces systèmes ? Comment un attaquant peut-il en profiter ? Et bien sûr : quelles contremesures peut-on envisager pour améliorer leur protection ?

“Connecter”

Avant de rentrer dans le vif du sujet, il est tout d’abord nécessaire de comprendre comment ces systèmes fonctionnent. Nous ne rentrerons pas trop dans les détails techniques ici, mais si vous souhaitez en savoir plus sur cette partie, j’ai présenté le sujet à la Defcon 2021, ici.

En premier lieu, un système GTB est constitué de composants qui permettent le fonctionnement effectif des infrastructures des bâtiments : ce qui permet à la lumière de s’allumer, à l’alarme de se déclencher, etc. Nous les appellerons ici “composants terrains”, et il en existe trois types : les capteurs, les actionneurs et les contrôleurs. Par exemple, un système de climatisation d’un bureau peut être composé :

  • De capteurs (des thermomètres) qui remonteront les informations liées à la température d’une pièce ;
  • De contrôleurs (des thermostats) qui permettent aux usagers de modifier la température d’une pièce ;
  • D’actionneurs qui vont déclencher, réguler ou arrêter la climatisation d’une pièce pour agir sur sa température.

Ces composants sont liés entre eux sur ce qu’on va appeler un “réseau terrain”. Il s’agit la plupart du temps d’une liaison filaire ou radio entre composants, utilisée pour la transmission d’informations sur leur statut ou des données de fonctionnement. Ce type de réseau est conçu pour fonctionner en autonomie et était auparavant isolé : il fallait une intervention physique – et donc souvent un accès aux armoires électriques – sur le réseau ou sur un équipement le permettant pour interagir avec lui.

Désormais, il est souvent connecté au réseau IP (réseau local, parfois Internet) via un ou plusieurs composants, que nous appellerons “passerelles”, qui sont connectés à la fois au réseau IP et au réseau terrain et qui vont traduire et relayer les données et les ordres entre les deux mondes. Ainsi, une personne connectée sur le bon réseau avec son ordinateur peut interagir avec le réseau terrain et les composants qui s’y trouvent sans même savoir où ils sont situés.

Évidemment cela nécessite quelques prérequis. Déjà, il faut pouvoir atteindre ces passerelles depuis le réseau IP (être “dans le bon réseau”). Ensuite, il faut savoir comment interagir avec ce réseau (quels outils, quelles connaissances). Nous reviendrons sur cette dernière partie dans la suite l’article, mais nous allons d’abord nous concentrer sur l’aspect réseau.

Idéalement, ces passerelles sont situées sur des réseaux ou des sous-réseaux (VLAN) “dédiés”, accessibles depuis un autre sous-réseau via une DMZ uniquement par les utilisateurs autorisés. Malheureusement ce n’est pas toujours – voire pas souvent – le cas, et il n’est pas rare de trouver des passerelles sans protection sur un VLAN accessible sans restriction.

Le schéma ci-dessous illustre le cas (qu’on rencontre de temps en temps lors d’un audit) d’un réseau d’entreprise “à plat”, où les serveurs, les postes de travail, les imprimantes et autres équipements connectés sont tous sur le même sous-réseau sans segmentation, sans contrôle d’accès. En d’autres termes : n’importe quel équipement connecté sur ce réseau peut accéder à n’importe quel autre équipement de ce réseau, y compris aux passerelles donnant accès au réseau terrain. Nous verrons dans la prochaine section ce que cela implique d’un point de vue cybersécurité.

 

Pour interagir avec une passerelle GTB et ainsi surveiller, configurer ou envoyer des commandes au réseau terrain, un opérateur légitime devra donc dans un premier temps se trouver dans un réseau lui permettant l’accès à la passerelle, et il devra ensuite s’y “connecter”.

Le mode de connexion dépendra des services disponibles sur la passerelle et des actions que l’opérateur veut effectuer. Il peut s’agir d’une interface web, d’un accès SSH, Telnet, etc. Il peut également s’agir d’un service dédié à la GTB avec accès via un logiciel spécifique installé sur le poste de l’opérateur (ETS, Sauter, Niagara, Desigo, etc.).

Pour vous donner un exemple, dans le cas d’un système de GTB “KNX”, c’est le protocole KNX qui sera utilisé sur le réseau terrain. Pour qu’il soit relié au réseau IP, il faut une (ou plusieurs) passerelle KNX/IP. Parmi d’autres services, celle-ci est susceptible d’exposer le port 3671/udp, qui est le port utilisé par le protocole KNXnet/IP. Lorsqu’un opérateur va vouloir configurer le réseau terrain, il utilisera le logiciel ETS, fourni par l’association KNX. Ce logiciel va envoyer directement des trames KNXnet/IP sur le port 3671 de la passerelle. KNXnet/IP est la version IP du protocole KNX et la passerelle va convertir les trames KNXnet/IP à destination du réseau terrain en trames KNX, et vice versa (pour plus de détails sur le fonctionnement, vous pouvez vous référer aux spécifications KNX). L’opérateur a besoin de connaître les principes de base de KNX (l’architecture et le fonctionnement) pour utiliser ETS, mais n’a pas besoin de connaître le protocole.

“Exposer”

Résumons : dans la configuration nominale d’une installation GTB nous avons un réseau terrain avec des composants qui permettent de contrôler des paramètres d’un bâtiment. Celui-ci est connecté au réseau IP via (au moins) une passerelle. Une personne qui va vouloir interagir avec cette installation sans y accéder physiquement va donc vouloir accéder à cette passerelle sur le réseau IP. C’est vrai pour les opérateurs légitimes, mais c’est également vrai dans le cadre d’une attaque ciblant la GTB : la première étape d’une attaque sera probablement de tenter d’accéder à la passerelle.

Dans la suite de cette section nous allons nous placer du point de vue d’un attaquant qui cherche à atteindre et à interagir avec la passerelle puis avec le réseau terrain. L’objectif ici est de bien comprendre comment il va procéder, ce qui va faciliter ou au contraire ralentir ses actions, et les impacts qu’il peut avoir sur une infrastructure GTB.

Premièrement, les capacités d’accès à cette passerelle et d’interaction avec elle – et potentiellement avec le réseau terrain derrière – dépendent :

  1. Des configurations réseau (exposition)

Moins elles seront restrictives et plus la passerelle sera “exposée”, et donc plus le nombre d’équipements et personnes en capacité d’atteindre la passerelle sur le réseau IP sera important. Plus l’exposition est grande, plus il sera facile pour un attaquant d’obtenir ce premier accès.

  1. Des services réseau exposés par la passerelle (surface d’attaque)

Une fois la passerelle atteignable sur le réseau IP, il sera possible d’interagir avec elle via ses services. Plus il y en a, plus il y a de portes d’entrées potentielles pour interagir avec elle. C’est ce qu’on va appeler la surface d’attaque : plus il y a de services exposés, plus la surface d’attaque est grande.

  1. De la configuration et de la robustesse des services réseaux (difficulté d’exploitation)

Si l’accès à un service peut être possible sans restriction (par exemple, sans authentification) ou si ses restrictions peuvent être contournées facilement (par exemple, si un service a été configuré avec les identifiants par défaut, trouvable par n’importe qui sur Internet), alors un attaquant ne rencontrera pas ou peu de difficulté pour utiliser ces services. L’un de ces services pourrait également être vulnérable à une attaque. Par exemple, en 2019, un chercheur a découvert une backdoor permettant d’exécuter des commandes sans authentification avec les privilèges les plus élevés sur la passerelle GTB Optenergy Proton. Il existe d’ailleurs des codes publics permettant de l’exploiter.

Si nous reprenons le schéma d’architecture réseau “à plat” de la section précédente, on voit qu’il suffirait à un attaquant de se trouver n’importe où sur ce même réseau pour accéder à la passerelle. La sécurité de l’infrastructure GTB dépend donc entièrement de la surface d’attaque et de la difficulté d’exploitation de la passerelle.

Et pour se trouver sur le même réseau, plusieurs options existent : il y a bien sûr la possibilité pour l’attaquant de brancher physiquement sa machine sur une prise brassée dans ce réseau. L’attaque pourrait aussi provenir d’un utilisateur interne. Il est aussi possible qu’un attaquant sur un autre sous-réseau ait pu accéder à celui-ci par pivot, via une machine connectée également sur notre réseau.

Enfin, il est possible que l’attaque provienne de l’extérieur, via une (ou plusieurs) machines connectées à un réseau externe ou à Internet (par exemple, via un serveur web exposé sur internet, ou avec du phishing). Cela implique que, même lorsque la passerelle n’est pas elle-même connectée à Internet, il reste envisageable qu’elle soit atteinte depuis l’extérieur si l’une des machines qui peut s’y connecter y est reliée.

Un autre scénario que nous pouvons envisager est celui où la passerelle GTB est accessible directement sur Internet. Cette fonctionnalité est utilisée notamment pour le contrôle et la supervision à distance ou pour la gestion centralisée de plusieurs bâtiments, et est de plus en plus souvent proposée par les constructeurs dans le cadre de la multiplication de l’usage du cloud. Encore une fois, sa sécurité et ce qu’un attaquant pourra en faire dépendra uniquement de sa surface d’attaque et de la difficulté qu’il aura pour l’utiliser afin d’accéder au réseau terrain ou de la compromettre, c’est-à-dire de détourner son usage ou d’obtenir un accès privilégié à celle-ci. En cas de compromission, un attaquant n’aurait pas seulement accès au réseau terrain : cela lui permettrait potentiellement d’accéder aux autres machines du réseau. La passerelle serait alors utilisée non pas pour atteindre le système GTB d’un bâtiment (ou pas que), mais également en tant que point d’entrée dans un réseau.

Malheureusement, ce phénomène n’est pas rare : il y a de nombreuses passerelles exposées sur Internet. Si nous faisons une recherche sur les deux protocoles GTB principaux BACnet et KNX sur le moteur de recherche d’objets Shodan, nous constatons qu’au 10 août 2021 qu’il y a 6730 équipements qui exposent sur Internet le port 47808 avec le mot-clé “bacnet”, et 16 386 équipements qui exposent le port 3671 pour la recherche “knx”. Évidemment ces équipements ne sont pas forcément tous des passerelles, et cela n’inclut pas les passerelles exposées sur Internet mais dont le port GTB bacnet ou knx n’est pas ouvert ou a été changé. Cela reste malgré tout un nombre élevé d’équipements, avec potentiellement autant de réseaux GTB ou de réseaux IP à atteindre derrière.

La question qui se pose maintenant est : est-il difficile d’utiliser et/ou de compromettre une passerelle ? Cela va bien sûr dépendre des services exposés sur celle-ci, de la manière dont ils sont protégés et de ce que l’attaquant cherche à faire (accès au réseau terrain et modification de son comportement, obtention d’un point d’accès au réseau IP interne, déni de service de la passerelle et/ou du réseau terrain, etc.). Nous allons ici évoquer deux scénarios, dont les modalités de réalisation sont décrites plus loin :

  1. La modification du comportement des équipements GTB sur le réseau terrain

Cela pourrait permettre par exemple d’allumer ou d’éteindre des équipements, de changer des seuils de déclenchement, de désactiver des alertes, etc. Selon les modifications apportées, cela pourrait mettre en danger la sécurité des installations et des personnes.

  1. La compromission de la passerelle

Cela permettrait de détourner l’usage prévu de la passerelle à des fins malveillantes, avec divers résultats possibles : le déni de service, l’installation de logiciels malveillants, le rebond vers un réseau interne, etc.

Pour modifier le comportement du système de GTB, il est simplement nécessaire d’utiliser les fonctionnalités de la passerelle qui permettent de le faire. Selon les services exposés, elles peuvent être de différents types. Pour rappel, nous avons évoqué précédemment l’interface web, et le protocole GTB qui est supposé être utilisé avec un logiciel adapté, mais il pourrait y en avoir d’autres.

Pour utiliser ces services, l’attaquant va d’abord devoir y accéder, et la difficulté d’exploitation va dépendre du niveau de sécurité apporté à ceux-ci : s’il y a un contrôle d’accès (authentification, signature, etc.), s’ils sont correctement configurés (valeurs par défaut changées, activation de fonctions de sécurité, etc.), ou autres protections de sécurité.

Dans le cas du protocole GTB, nous avons dit en introduction que ce type de protocole n’avait pas été conçu en prenant en compte des notions de cybersécurité dans l’optique qu’il serait un jour exposé. Bien qu’il existe des protections de sécurité (voire des extensions de sécurité dans le cas de KNX), les protocoles de base n’en implémentent souvent pas par défaut et il n’est pas rare que celles-ci soient tout simplement absentes ou désactivées sur les passerelles. Dans ces cas-là, il suffit de communiquer directement avec le port du protocole GTB – manuellement ou via un logiciel – et de lui envoyer les bonnes trames pour modifier son comportement. Il n’y a pas de vérification de l’origine des données, pas d’authentification : toute trame valide sera interprétée et exécutée, peu importe sa provenance. Cela ne permet pas par contre de changer les configurations sur le long terme, cette action nécessitant en général d’activer physiquement le mode “programmation” sur les équipements concernés en appuyant sur un bouton.

Finalement, pour compromettre la passerelle et pouvoir l’utiliser à d’autres fins que celles pour lesquelles elle a été conçue, il est nécessaire de découvrir des vulnérabilités sur celle-ci et de les exploiter. De nouvelles vulnérabilités sont d’ailleurs rendues publiques périodiquement sur ce type d’équipement. Plus la surface d’attaque est grande, plus il y a des chances qu’un attaquant découvre un jour une vulnérabilité exploitable sur une passerelle spécifique ou sur un ensemble d’équipements qui utilisent le même composant vulnérable. Il est également important de rappeler que ces équipements (y compris les passerelles) ne bénéficient pas nécessairement de protections ou de bonnes pratiques liées à la sécurité au niveau des applications, services et firmware. De plus, certaines implémentations sont anciennes et pas ou peu mises à jour, ce qui font qu’elles ne respectent pas forcément les standards de sécurité recommandés aujourd’hui.

L’une des méthodes pouvant être utilisée pour la recherche de vulnérabilités sur ce type de composants est le fuzzing, consistant à tester de manière intensive les entrées en fournissant des données malformées et invalides afin de générer des erreurs. C’est par exemple ce procédé qui a été utilisé par les chercheurs de McAfee pour découvrir une vulnérabilité permettant de prendre le contrôle d’un contrôleur GTB de la marque Delta. Une démarche possible d’utilisation de fuzzing sur des passerelles GTB est également proposée dans le papier de recherche « Sneak into buildings with KNXnet/IP ».

Que faire ?

Nous avons vu que la cybersécurité des installations GTB dépendait majoritairement de :

  • Son exposition, accrue par son interconnexion au réseau IP qui la rend accessible sur des réseaux insuffisamment cloisonnés, voire sur Internet ;
  • Sa surface d’attaque, qui dépend notamment du nombre de services activés et accessibles sur les passerelles, et donc de la façon dont elles sont configurées ;
  • La difficulté d’accès et d’exploitation aux différents éléments qui permettent d’interagir avec les passerelles, qui dépendent également de la configuration de celles-ci, mais également de la robustesse et des capacités offertes par les protocoles utilisables. Dans le cas des protocoles GTB, il est fréquent que cette difficulté soit très faible, dans la mesure où ceux-ci ne disposent d’aucune protection implémentée ou activée.

Durant nos audits, nous voyons régulièrement des installations GTB fortement exposées et où il nous est possible d’interagir illégitimement avec la passerelle et le réseau terrain. Cela est souvent dû à une méconnaissance des pratiques de cybersécurité sur ces infrastructures : celles-ci sont installées dans des sous-réseaux accessibles par tous, les configurations ne sont pas renforcées, et il est également très difficile de les maintenir à jour. Mais c’est aussi lié à l’utilisation de ces protocoles insuffisamment protégés, mais qui restent indispensables et qui sont difficilement remplaçables.

Puisqu’il n’est pas toujours possible de désactiver ou d’utiliser des versions sécurisées des protocoles GTB, ni de mettre à jour ou de migrer les composants, il est surtout recommandé de limiter leur exposition et donc les possibilités d’accès à ceux-ci. Les composants liés à la GTB présents sur le réseau IP (passerelles, serveurs de supervision, etc.) doivent dans un premier temps ne pas être exposés sur Internet. Ils doivent se trouver dans un sous-réseau dédié et correctement cloisonné : seuls les utilisateurs habilités doivent y avoir accès. Pour ce faire, il est conseillé de n’autoriser aucun flux direct entre ce sous-réseau et d’autres, et de mettre en place une DMZ qui réalisera le filtrage des flux et assurera leur traçabilité. La mise en place d’un système de surveillance réseau afin de détecter et de tracer tout comportement anormal sur le réseau vis-à-vis des infrastructures GTB est un plus.

Finalement, il est recommandé de durcir les configurations des passerelles et autres composants GTB, afin de désactiver les services inutiles et d’activer les fonctions de sécurité sur la passerelle et sur les protocoles, lorsqu’il y en a.