C’est un fait connu, les dispositifs intégrés, en particulier ceux conçus pour l'automatisation industrielle et qui ont une longue durée de vie, utilisent un mélange de code interne et de code tiers, créé à une époque où les vulnérabilités logicielles n'étaient pas aussi bien comprises qu'aujourd'hui. Les failles critiques découvertes dans des composants propriétaires que les fournisseurs de hardware utilisent depuis des années ont de lourdes conséquences. D’autant que l'application de correctifs n'est pas toujours possible. C'est ce que soulignent les résultats obtenus au cours de l'année écoulée par les chercheurs de Forescout Research Labs et de JFrog Security Research, qui ont étudié les piles TCP/IP utilisées dans divers systèmes IoT et autres systèmes embarqués. Leur travail a permis d'identifier des failles majeures comme Ripple20, NAME:WRECK, NUMBER:JACK ou AMNESIA:33 qui impactent des millions d'appareils.

Leur dernier rapport, publié aujourd'hui sous le nom d'INFRA:HALT, couvre 14 vulnérabilités critiques et à haut risque trouvées dans une pile TCP/IP propriétaire appelée NicheStack, très utilisée dans les dispositifs de technologie opérationnelle (OT) de près de 200 fournisseurs, dont des automates programmables (PLC), comme le Siemens S7, constitutifs de l'automatisation industrielle et utilisés dans les secteurs d'infrastructures critiques.

L’énorme surface d’attaque des piles TCP/IP

Les piles TCP/IP, ou suites de protocoles Internet, consistent en des implémentations de protocoles Internet courants, notamment DNS, HTTP, FTP, ARP et ICMP qui permettent aux systèmes d'exploitation et à leurs applications d'envoyer et de recevoir des données sur les réseaux IP. Étant donné la multitude de protocoles pris en charge par ces piles et la quantité de données et de formats de paquets qu'elles traitent, celles-ci exposent une surface d'attaque importante, souvent exploitable sans authentification. Longtemps, les dispositifs de contrôle industriels communiquaient surtout via des interfaces série, mais au fil des ans, ils ont été de plus en plus équipés d'interfaces Ethernet et, implicitement, de piles TCP/IP, afin de pouvoir communiquer avec des ordinateurs et des dispositifs informatiques courants.

De nombreux appareils IoT modernes fonctionnent sous Linux et utilisent donc la pile TCP/IP de Linux, scrutée de près par les chercheurs en sécurité et les développeurs du noyau Linux depuis trois décennies. Cependant, les appareils de contrôle industriel exécutent couramment des systèmes d'exploitation en temps réel (RTOS) propriétaires qui utilisent des piles TCP/IP propriétaires avec des versions incohérentes, des modifications très personnalisées et des changements de propriétaire, ce qui complique l'identification des produits vulnérables et, en fin de compte, l'application de correctifs.

Vulnérables à du débordement de mémoire tampon

Développée à l'origine en 1996 ou avant, par une société appelée InterNiche Technologies, la pile TCP/IP NicheStack a été étendue pour prendre en charge la nouvelle technologie IPv6 en 2003. En 2016, InterNiche Technologies a été rachetée par une autre société appelée HCC Embedded qui assure toujours la maintenance de la pile. « Au cours des deux dernières décennies, la pile a été distribuée et déclinée en plusieurs « saveurs » par des équipementiers comme STMicroelectronics, Freescale (NXP), Altera (Intel) et Microchip pour être utilisée avec plusieurs systèmes d'exploitation (en temps réel) ou son propre RTOS simple appelé NicheTask », indiquent les chercheurs de Forescout dans leur rapport. « Elle a également servi de base à d'autres piles TCP/IP, comme emNet de SEGGER (anciennement embOS/IP) ».

La majorité des 14 vulnérabilités découvertes par les chercheurs de Forescout et JFrog sont des débordements de tampon et des lectures et écritures de mémoire hors limites qui résultent d'une analyse non sécurisée des paquets sur différents protocoles. Ces vulnérabilités peuvent être exploitées sur DNSv4, HTTP, TCP, ICMP ou TFTP et peuvent conduire à l'exécution de code à distance (deux vulnérabilités) et à des conditions de déni de service (huit vulnérabilités). Les autres failles résultent de numéros de séquences Initial Sequence Number (ISN) TCP prévisibles, d'ID de transaction DNS insuffisamment aléatoires et de numéros de port source prévisibles pour les requêtes DNS, ce qui permet par exemple des attaques de spoofing TCP ou de corruption de cache DNS. Toutes les vulnérabilités ont un impact sur toutes les versions de NicheStack antérieures à la version 4.3, dernière version disponible au moment où la recherche a été effectuée.

L'enfer de la coordination des vulnérabilités

Les deux failles d'exécution de code à distance sont situées dans l'implémentation DNSv4 et HTTP et ont un score respectif de 9.8 et 9.1 dans le système d’évaluation de la criticité des vulnérabilités Common Vulnerability Scoring System (CVSS), ce qui signifie qu'elles sont sérieusement critiques. Les scores de gravité des problèmes de déni de service (DoS) sont de 7,5 ou 8,2 dans le système CVSS. Cependant, il convient de noter que dans le contexte des systèmes de contrôle industriels, l'impact potentiel d'un problème de déni de service peut être grave, en fonction du type de processus industriel contrôlé par le dispositif affecté. Par exemple, pour récupérer après des attaques exploitant ces vulnérabilités, y compris des attaques DoS, il faudrait allumer et éteindre les appareils concernés. « Ce qui implique d'y avoir un accès physique », a expliqué Elisa Costante, vice-présidente de la recherche chez Forescout. « Si bien que l'impact peut être assez important. Imaginez que ce dispositif se trouve en mer pour des sous-stations ou l'extraction du pétrole ».

Il a fallu plus d’un an pour que les chercheurs se coordonnent en vue de la divulgation des vulnérabilités INFRA:HALT, bien plus que les 90 jours habituels pour les vulnérabilités logicielles. Forescout et JFrog Security Research ont contacté HCC Embedded pour l’alerter sur des failles en septembre 2020 et ils ont travaillé avec le centre de coordination CERT (CERT/CC), l’Office fédéral allemand de la sécurité des technologies de l’information (Bundesamt für Sicherheit in der Informationstechnik ou BSI) et l'équipe d'intervention d'urgence pour les systèmes de contrôle industriel Computer Emergency Readiness Team (ICS-CERT) qui fait partie de l’agence fédérale américaine Cybersecurity and Infrastructure Security Agency (CISA). Malgré cela, l'identification des appareils et des fournisseurs potentiellement touchés a été très difficile et ce travail est loin d’être achevé. En utilisant des requêtes sur le moteur de recherche SHODAN, les chercheurs ont trouvé environ 6 400 appareils accessibles au public qui utilisent NicheStack. En utilisant sa propre base de données propriétaire contenant des millions d'empreintes numériques d'appareils, Forescout a identifié 2 500 appareils potentiellement vulnérables provenant de 21 fournisseurs, les secteurs verticaux les plus touchés étant ceux des processus de fabrication, de la vente au détail et la fabrication unitaire. Près de la moitié des appareils identifiés concerne des systèmes de contrôle industriel de l'énergie et de l'électricité.

Pas d’atténuation sans visibilité

Mais l'impact réel de ces failles est bien plus large. D'après les chercheurs, un ancien site Web d'InterNiche, qui n'est plus en ligne, répertoriait près de 200 fournisseurs de dispositifs comme clients, y compris de grands fournisseurs de systèmes OT comme Siemens, Emerson, Honeywell, Mitsubishi Electric, Rockwell Automation et Schneider Electric. « Seul un petit nombre de fournisseurs émettront des avis publics, mais selon les prévisions, le nombre réel de dispositifs touchés se compte probablement en millions », a déclaré Elisa Costante. « C’est la première étude qui montre de manière aussi importante la grande variété des fournisseurs ICS impactés [...] mais peu de dispositifs OT sont réellement exposés au public, il est donc un peu plus difficile pour nous d'obtenir des informations à leur sujet ». Forescout maintient sur GitHub une liste d'avis des fournisseurs impactés par ses recherches sur les piles TCP/IP et celle-ci sera mise à jour avec les nouveaux avis liés à INFRA:HALT à mesure de leur publication.

HCC Embedded a développé des correctifs pour les vulnérabilités, mais ils ne sont disponibles que sur demande des clients, qui sont pour la plupart des fabricants de dispositifs. Les utilisateurs finaux des produits concernés doivent attendre les correctifs des fabricants de leurs appareils respectifs. Le problème est encore compliqué par le fait qu'il est peu probable que tous les fournisseurs, en particulier les moins importants, qui ont intégré cette pile TCP/IP dans leurs produits au fil des ans aient encore des contrats actifs avec HCC Embedded. De plus, certains des appareils concernés ne bénéficient plus de support technique et pourraient ne jamais recevoir de correctifs. « Un autre problème, c’est que le propriétaire de ces appareils, même si un correctif est disponible, ne sait pas toujours que ces appareils sont vulnérables », a encore déclaré Mme Costante. « Parfois, ils ne disposent pas d'un inventaire complet de tous leurs actifs, de sorte que même l'évaluation du risque est incomplète ».

Forescot a développé un script open-source que les propriétaires d'actifs peuvent utiliser sur leurs réseaux pour savoir quels appareils exécutent NicheStack ou les autres piles TCP/IP dans lesquelles la société a découvert des vulnérabilités dans le cadre d’une étude plus large baptisée Project Memoria, menée par le passé. Forescot a également mis à jour ses propres produits commerciaux afin de trouver les dispositifs affectés et de détecter les tentatives d'exploitation. Autre problème lié au déploiement des correctifs : certains des appareils concernés contrôlent probablement des processus critiques ou toujours actifs dans les usines et les installations industrielles, ou ils sont déployés sur le terrain dans des endroits éloignés, de sorte qu'ils ne peuvent pas être éteints et mis à jour sans maintenance planifiée. « Les mesures d'atténuation fonctionneront mieux que les correctifs pour la majorité des fournisseurs, en particulier pour les plus petits d'entre eux », a encore déclaré Elisa Costante.

Les conseils à suivre pour atténuer les vulnérabilités INFRA:HAL

• Appliquer des contrôles de segmentation et une bonne hygiène du réseau pour atténuer le risque lié aux dispositifs vulnérables. Limiter les voies de communication externes et isoler ou confiner les dispositifs vulnérables dans des zones en guise de contrôle d'atténuation s'ils ne peuvent pas être corrigés ou jusqu'à ce qu'ils puissent l'être.

• Surveiller la publication des correctifs par les fournisseurs de dispositifs concernés et élaborer un plan de remédiation pour l’inventaire des actifs vulnérables en tenant compte des exigences en matière de risque et de continuité des activités.

• Surveiller l'ensemble du trafic réseau pour détecter les paquets malveillants qui tentent d'exploiter des vulnérabilités connues ou d'éventuelles failles zero day. Le trafic anormal et mal formé doit être bloqué, ou au moins signalé aux opérateurs du réseau.

• Désactiver le client DNSv4 s'il n'est pas nécessaire, ou bloquer le trafic DNSv4. Étant donné que plusieurs vulnérabilités facilitent les attaques par usurpation de DNS, l'utilisation de serveurs DNS internes peut ne pas être suffisante (les attaquants peuvent arriver à détourner la correspondance demande-réponse).

• Désactiver le protocole HTTP s'il n'est pas nécessaire, ou inscrire les connexions HTTP sur une liste blanche.

• Surveiller le trafic pour détecter les paquets IPv4/TCP et ICPMv4 mal formés et les bloquer.