Des dizaines de failles non sécurisées par conception trouvées dans les produits OT des fournisseurs

Une nouvelle tâche de recherche a révélé 56 vulnérabilités dans la technologie fonctionnelle (OT ) appareils de 10 fournisseurs différents, qui découlent tous de performances créées ou mises en œuvre de manière non sécurisée au lieu d’erreurs de programmation.

Cela souligne que, quelle que soit l’attention accrue que ce type de gadgets cruciaux a suscitée au cours des dernières années de la part des deux chercheurs en sécurité et les agresseurs malveillants, le marché ne suit toujours pas les concepts fondamentaux de sécurité dès la conception.

 » En utilisant ces vulnérabilités, les agresseurs ayant un accès réseau à un gadget cible peuvent exécuter du code à distance, modifier le raisonnement , des fichiers ou des micrologiciels d’appareils OT, contournent l’authentification, compromettent les qualifications, déclenchent des dénis de service ou ont divers impacts opérationnels « , ont déclaré les scientifiques de la société de sécurité Forescout dans leur tout nouveau rapport.

Les problèmes de sécurité déterminés, coll eectivement appelé OT : ICEFALL, découle de procédures d’ingénierie non sécurisées, d’applications cryptographiques faibles ou de schémas d’authentification endommagés, de systèmes de mise à jour de micrologiciels non sécurisés et de fonctionnalités natives mal protégées qui peuvent être utilisées de manière abusive pour l’exécution de code à distance.

14 % des vulnérabilités révélées peuvent entraîner l’exécution de code à distance et 21 % supplémentaires peuvent conduire à un ajustement du micrologiciel.

Une autre découverte intrigante de cette recherche est qu’un certain nombre de les appareils sensibles avaient été homologués conformément à diverses normes relatives aux environnements OT telles que CEI 62443, NERC CIP, NIST SP 800-82, CEI 51408/CC, CEI 62351, DNP3 Security, CIP Security et Modbus Security.

« Bien que ces efforts de renforcement axés sur les normes aient en fait certainement contribué à des améliorations majeures dans les domaines de l’avancement du programme de sécurité, de la gestion des risques et des activités de conception et de combinaison au niveau de l’architecture, ces efforts ont en fait moins réussi à faire mûrir des cycles de vie d’avancement sûrs et sécurisés. pour les systèmes et éléments individuels « , ont conclu les chercheurs.

Une histoire de l’insécurité par conception dans OT

Les chercheurs de Forescout établissent des comparaisons entre leurs conclusions et celles du projet Basecamp, un travail de recherche d’il y a dix ans qui s’est concentré sur l’exposition des problèmes d’insécurité par conception dans les systèmes de terminaux distants (RTU), les contrôleurs de raisonnement programmables (PLC) et d’autres contrôleurs qui composent les systèmes SCADA (Supervisory Control and Data Acquisition) utilisés dans les installations commerciales.

Puis, suite à la découverte de risques sophistiqués comme Stuxnet développé par les États-nations pour cibler les automates programmables, les scientifiques qui ont participé à Job Basecamp ont entrepris de modifier ce qu’ils affirmaient avoir été  » une décennie d’inactivité  » par les producteurs et les propriétaires d’ICS après le 11 septembre.

Une décennie plus tard, OT : ICEFALL montre qu’une grande partie des mêmes problèmes, tels que des protocoles exclusifs obscurs qui n’ont pas d’authentification et de cryptage appropriés, continuent d’être un événement courant dans les appareils qui exécutent notre infrastructure vitale.

 » Les produits concernés par OT : ICEFALL sont connus pour être répandus sur les marchés qui sont l’épine dorsale des installations critiques telles que le pétrole et le gaz, la chimie, le nucléaire, la production et la distribution d’électricité, la production, l’eau traitement et distribution, exploitation minière et automatisation des structures », ont déclaré les scientifiques de Forescout dans leur rapport.  » Beaucoup de ces articles sont vendus comme « sécurisés par style » ou ont été concédés sous licence avec des exigences de sécurité OT. « 

Bien que cet état d’insécurité par défaut se soit poursuivi dans le monde OT, le nombre d’attaques a seulement augmenté et développé.

Étant donné que Stuxnet, nous avons vu l’attaque Industroyer qui a provoqué des coupures de courant en Ukraine en 2016, le logiciel malveillant TRITON qui a été utilisé lors d’une tentative de sabotage d’usines pétrochimiques en Arabie saoudite en 2017, le logiciel malveillant Industroyer2 qui a été utilisé contre la sous-station électrique en Ukraine cette année, et la boîte à outils INCONTROLLER APT.

La société de sécurité ICS Dragos suit 19 groupes de menaces qui ciblent les environnements ICS, dont trois ont été découverts l’année dernière et ont révélé la capacité d’accéder aux réseaux ICS/OT.

L’OT : ICEFALL les défauts affectent les appareils de Bently Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens et Yokogawa. Ils se composent de moniteurs d’état, de systèmes de contrôle distribués (DCS), de postes de travail d’ingénierie, de RTU, d’automates programmables, de contrôleurs en développement, de systèmes instrumentés de sécurité (SIS), de systèmes SCADA, de procédures et même d’un temps d’exécution logique.

Le temps d’exécution logique est l’application logicielle qui interprète et exécute la logique à relais – le code écrit par les ingénieurs pour agir sur les entrées et les sorties du gadget. Le runtime ProConOS de Phoenix Contact, par exemple, est utilisé dans plusieurs automates programmables de divers fournisseurs, ce qui rend les défauts qu’il contient – le manque d’authentification cryptographique du raisonnement téléchargé – un risque potentiel pour la chaîne d’approvisionnement qui entraîne l’exécution de code arbitraire.

« En raison de l’absence de dépenses logicielles des produits (SBOM) et de la complexité des chaînes d’approvisionnement des produits, il est souvent difficile de savoir immédiatement quel temps d’exécution un automate spécifique utilise », ont déclaré les chercheurs dans leur rapport.

 » Les runtimes ont généralement des versions différentes avec des différences de protocole correspondantes et subissent des choix de combinaison OEM. Un fabricant d’API peut choisir d’utiliser le runtime mais pas les protocoles, choisir d’utiliser le sien, ou peut choisir d’utiliser la procédure sur un port autre que celui par défaut ou peut choisir de renommer ou de modifier complètement le runtime.

 » Absence d’efforts proactifs et coordonnés de la part des fournisseurs, des autorités de numérotation CVE et des CERT pour propager la connaissance des vulnérabilités de la chaîne d’approvisionnement à toutes les parties concernées , le voisinage de sécurité est obligé de les découvrir occasionnellement et au hasard, ce qui entraîne une duplication CVE et complique l’analyse des causes profondes. « 

Par exemple, deux CVE attribués dans le passé à des problèmes dans le runtime ProConOS– CVE-2014-9195 et CVE-2019-9201– étaient simplement connectés aux automates Phoenix Contact alors qu’ils affectaient d’autres fournisseurs Un problème a été trouvé plus tard dans les contrôleurs Yokogawa STARDOM et a été nommé CVE-2016-4860, mais c’est en fait exactement le même problème que CVE-2014-9195, ont déclaré les scientifiques.

Le problème est encore intensifié par le fait que dans le passé, de nombreux problèmes non sécurisés par défaut comme ceux inclus dans OT : ICEFALL n’ont pas du tout reçu d’identifiants CVE car ils n’étaient pas considérés comme des vulnérabilités conventionnelles, ce qui rend difficile pour les consommateurs de les suivre.