Des chercheurs extraient la clé de cryptage principale des automates Siemens

Par Lucian Constantin

Rédacteur principal CSO, CSO |

Les chercheurs en sécurité ont trouvé un moyen d'extraire une clé de chiffrement globale qui était codée en dur dans les processeurs de plusieurs gammes de produits d'automates programmables industriels (PLC) de Siemens, leur permettant de compromettre leurs communications sécurisées et leur authentification. Siemens conseille à tous ses clients de mettre à jour à la fois le micrologiciel des appareils concernés ainsi que le logiciel TIA Portal que les ingénieurs utilisent pour communiquer avec eux et déployer leurs programmes.

Selon des chercheurs en sécurité de Claroty, Siemens a introduit la cryptographie asymétrique dans ses processeurs PLC SIMATIC S7-1200/1500 il y a près de dix ans pour protéger leur configuration, leurs programmes et leurs communications. Cependant, la société a choisi de le faire en utilisant une clé privée globale codée en dur pour tous les appareils de ces familles de produits, car à l'époque, la distribution et la gestion dynamiques des clés n'étaient pas une pratique courante et un fardeau potentiel pour les clients.

"Depuis lors, cependant, les progrès de la technologie, la recherche sur la sécurité et l'évolution rapide du paysage des menaces ont fait de ces clés de cryptage codées en dur un risque inacceptable", ont déclaré les chercheurs dans leur rapport. "Un acteur malveillant capable d'extraire une clé globale codée en dur pourrait compromettre la sécurité de l'ensemble de la gamme de produits de l'appareil de manière irréparable."

Selon Claroty, les automates Siemens S7-1200 et S7-1500 utilisent plusieurs touches. Une clé « par famille » est partagée par tous les appareils d'une gamme de produits et une clé « par modèle/micrologiciel » est utilisée pour chiffrer les configurations et maintenir l'intégrité du code, et une clé de connexion qui est utilisée dans le processus d'authentification, ainsi que chiffrer les communications avec les clients. La clé de connexion est dérivée des clés de configuration et est utilisée pour le chiffrement basé sur les courbes elliptiques.

Cela signifie que les attaquants obtiennent la clé de configuration, ils peuvent potentiellement déchiffrer le mot de passe de l'utilisateur à partir de la configuration d'un automate et lancer des attaques de type "man-in-the-middle" même s'ils n'ont pas accès pour lire la configuration chiffrée.

Le problème est que cette clé de configuration à l'échelle de la famille n'est pas stockée dans le micrologiciel de l'appareil - le système d'exploitation exécuté sur l'appareil - mais dans le processeur lui-même, donc sa lecture nécessite un accès pour interagir directement avec le processeur via des opcodes. Cela ne doit être fait qu'une seule fois sur un seul appareil car ils partagent tous la clé.

L'année dernière, les chercheurs de Claroty ont découvert une vulnérabilité d'exécution de code à distance (CVE-2020-15782) affectant les automates S7 qui leur permettait d'exécuter du code natif sur les appareils. Normalement, les programmes ou la logique que les ingénieurs écrivent et déploient sur les API via le logiciel d'ingénierie spécialisé s'exécutent dans un bac à sable dans le système d'exploitation de l'API. CVE-2020-15782 a permis aux chercheurs de contourner cette couche de sécurité et de lire et d'écrire directement sur n'importe quelle adresse mémoire normalement protégée sur l'automate.

"Grâce à l'autorisation de lecture DA [accès direct à la mémoire] que nous avons obtenue, nous avons pu extraire l'intégralité du micrologiciel crypté de l'automate (SIMATIC S7-1500) et cartographier ses fonctions", ont déclaré les chercheurs. "Pendant le processus de mappage, nous avons trouvé une fonction qui lit la clé privée sur l'automate. Une fois que nous avons eu l'adresse de la fonction, nous avons réécrit la fonctionnalité d'opcodes MC7+ spécifiques avec notre code shell, les forçant à appeler la fonction native qui lit la clé privée. . Nous avons ensuite copié la clé à une adresse mémoire connue et l'avons lue à partir de là. L'exécution de la fonction écrasée nous a donné la clé privée complète de l'automate.

L'interaction avec les automates Siemens nécessite un mot de passe, mais les autorisations accordées au client sur l'appareil sont définies par quatre niveaux de protection configurables. Si le niveau de protection est inférieur à trois, un attaquant peut extraire la configuration de l'automate sans autorisation particulière. Cette configuration contient le hachage du mot de passe mais est chiffrée. Cependant, s'ils disposent de la clé privée globale, les attaquants peuvent déchiffrer le hachage du mot de passe et l'utiliser pour s'authentifier auprès de l'automate avec des privilèges plus élevés.

Si le niveau de protection est supérieur à quatre, les attaquants peuvent utiliser la clé privée pour lancer une attaque de type "man-in-the-middle" contre un client légitime à la place. La façon dont cela fonctionnerait est qu'ils simuleraient un faux automate et forceraient le client à essayer de s'authentifier auprès de celui-ci. Cela conduirait le client à envoyer une clé de connexion chiffrée à l'automate non autorisé, qui serait ensuite déchiffrée avec la clé globale extraite en possession de l'attaquant et utilisée pour se connecter à l'automate réel. Le véritable automate répondrait par une demande de mot de passe que l'attaquant renverrait au client et obtiendrait sa réponse.

La transmission de la réponse au défi à l'automate réel leur permettrait d'établir une session authentifiée avec les privilèges pour lire la configuration qui inclut le hachage du mot de passe. Le hachage du mot de passe pourrait ensuite être déchiffré à l'aide de la clé privée globale, donnant aux attaquants un accès futur sans répéter le détournement de session par l'homme du milieu.

Enfin, "un attaquant disposant d'un accès passif pour capturer le trafic vers un automate donné sur le réseau peut intercepter les lectures/écritures de configuration depuis l'automate", ont averti les chercheurs. "A l'aide de la clé privée, l'attaquant peut déchiffrer la configuration et extraire le hachage du mot de passe. Avec le hachage du mot de passe, l'attaquant peut s'authentifier auprès du contrôleur et écrire une nouvelle configuration."

"Les processeurs SIMATIC S7-1200, S7-1500 et les produits associés protègent la clé privée globale intégrée d'une manière qui ne peut plus être considérée comme suffisante", a déclaré Siemens dans un nouvel avis en réponse à ce problème. "Siemens recommande de mettre à jour les produits concernés ainsi que le projet TIA Portal correspondant vers les dernières versions. TIA Portal V17 et les versions de firmware de CPU associées ont introduit une protection des données de configuration confidentielles basée sur des mots de passe individuels par appareil et PG/PC protégés par TLS et Communication IHM."

Les appareils vulnérables incluent les versions de la famille SIMATIC Drive Controller inférieures à 2.9.2, les versions de la CPU SIMATIC ET 200SP Open Controller 1515SP PC2 (y compris les variantes SIPLUS) inférieures à 21.9, les versions de la famille de CPU SIMATIC S7-1200 (y compris les variantes SIPLUS) inférieures à 4.5.0 , la famille de CPU SIMATIC S7-1500 (y compris les CPU ET200 associées et les variantes SIPLUS) versions inférieures à 2.9.2, les versions de contrôleur logiciel SIMATIC S7-1500 inférieures à 21.9 et les versions avancées de SIMATIC S7-PLCSIM inférieures à 4.0. Toutes les versions de SIMATIC ET 200SP Open Controller CPU 1515SP PC (y compris les variantes SIPLUS) sont également concernées, mais aucun correctif n'est disponible ou prévu pour celles-ci.

Lucian Constantin est rédacteur principal au CSO, couvrant la sécurité de l'information, la confidentialité et la protection des données.

Copyright © 2022 IDG Communications, Inc.