Contexte

Lors de la conférence BlackHat qui s’est déroulée à Las Vegas au début du mois d’août, des chercheurs israéliens ont présenté une série de vulnérabilités identifiées dans le protocole « s7 comm plus » utilisé pour la programmation des automates Siemens s7-1200 et s7-1500.

Ces vulnérabilités peuvent notamment permettre de mener des attaques de types Man In The Middlebien que le protocole implémente des mécanismes d’authenticité (HMAC) mais surtout permettre de faire exécuter à un automate un programme différent de celui visible par une station d’ingénierie

Ce type d’attaque rappelle une étape de l’attaque Stuxnet lors de laquelle les attaquants avaient également modifié le programme d’un automate Siemens tout en masquant certaines valeurs à la supervision.

Présentation de s7comm plus

Les automates Siemens sont programmés depuis des stations d’ingénieries utilisant un logiciel propriétaire nommé TIA Portal. Celui-ci communiquait auparavant avec l’automate en utilisant le protocole s7. Cependant, au cours du temps, la technique d’échange utilisée a largement évolué.

Tout d’abord, c’est un nouveau protocole qui a été utilisé, nommé s7plus. Ce même protocole a connu plusieurs variantes, nommées par les chercheurs `P2-`, `P2` puis `P3`. Les différences notables entre ces versions qui sont utilisées dans le cadre du papier concernent les méthodes d’authentification et d’intégrité des paquets échangés.

  • Dans la version `P2-`, le premier paquet envoyé par le PLC vers TIA contient un nombre aléatoire, stocké sur 2 octets, qui constitue l’identifiant de session. Ce nombre doit se retrouver dans les autres messages pour considérer que la session est valide. C’est le seul mécanisme mis en place. Il ne permet donc pas de contrôler l’authentification ou l’intégrité des messages.
  • Dans la version `P2`, l’intégrité du message est assurée par l’utilisation de `HMAC-SHA256` avec une clé de session qui est calculée séquentiellement par l’automate et TIA. Concrètement, cela signifie que l’automate et la station d’ingénierie partagent une liste de clés qui est utilisée séquentiellement. Il est donc simple pour un attaquant de précalculer cette liste et d’avoir la bonne clé de session, d’autant plus que la liste de clés est indépendante de l’instance de TIA utilisée. Lors d’une attaque par Man in The Middle, l’attaquant peut donc modifier à la volée le contenu du message, car il est simple de recalculer le champ HMAC.
  • Dans la version `P3`, le mécanisme d’échange de clé de session est nettement plus avancé, c’est en revanche toujours HMAC-SHA256 (les auteurs du papier ont néanmoins noté que l’algorithme n’est pas implémenté de manière conventionnelle, ce qui le fragilise) qui est utilisé à partir de cette clé de session.

Le mécanisme d’échange de clés se déroule comme suit :

  • TIA envoie un premier message vers l’automate pour initialiser la session,
  • L’automate répond avec un message qui contient un challenge de 20 octets ainsi que sa version de firmware,
  • Cette version de firmware détermine quelle clé publique va être utilisée pour la suite de l’échange. TIA va également choisir un nombre aléatoire (Key Derivation Key, KDK) qu’il va associer au challenge de l’automate pour obtenir la clé de session. TIA envoie alors à l’automate la KDK chiffrée avec la clé publique de l’automate ainsi que d’autres informations,
  • L’automate vérifie les informations envoyées puis envoie un message d’accord à TIA,
  • Tous les messages suivants utilisent alors la clé de session pour s’assurer de l’authenticité et de l’intégrité.

Faiblesses constatées

Deux faiblesses principales sont à noter dans le mécanisme d’échange de clé utilisé dans P3 :

  • Si TIA vérifie l’authenticité de l’automate lors de l’envoi de la KDK avec sa clé publique, l’automate ne vérifie en revanche pas l’authenticité de TIA.
  • La conception du mécanisme d’échange implique que tous les automates avec la même version de firmware puissent déchiffrer la KDK envoyée avec une même clé publique. Cela signifie que tous les automates avec la même version de firmware possèdent la même clé privée. Si un attaquant parvient à extraire la clé privée d’un automate, il pourra déchiffrer la valeur de KDK transmise sur le réseau et ainsi connaître la clé de session. Une attaque de type Man in The Middleest alors possible pour tous les automates avec la même version de firmware.

Dans le papier qu’ils ont publié, les chercheurs présentent un mécanisme permettant de faire exécuter à un automate un programme différent de celui visible sur la station d’ingénierie. En analysant le logiciel TIA Portal, ils ont déterminé que lorsqu’un programme était envoyé vers l’automate, il l’était sous 2 formes :

  • Une forme binaire qui est celle qui est exécutée par l’automate
  • Une forme textuelle (plus exactement, deux objets contiennent deux versions de cette forme textuelle). Lorsqu’un ingénieur souhaite télécharger le programme se trouvant sur un automate, c’est cette version qui est retournée.

En utilisant une station TIA modifiée, il est possible d’envoyer une forme binaire qui ne correspond pas à la forme textuelle. Cela cause donc bien une différence entre le programme exécuté et le programme visible sur la station d’ingénierie.

Il est intéressant de noter que cette attaque est d’autant plus simplifiée que le mécanisme d’authentification est indépendant entre les différentes formes (HMAC distinct pour la forme binaire et la forme textuelle). Les chercheurs soulignent également qu’un chiffrement est appliqué sur les différents blocs, mais que celui-ci ne permet absolument pas d’empêcher cette attaque, à tel point qu’ils n’ont même pas eu besoin d’effectuer la rétro-conception de ce mécanisme.

L’avis des experts Sentryo

L’évolution du protocole s7comm plus illustre bien les changements qui sont en cours dans le milieu industriel. Les différentes versions implémentent des mesures de sécurité qui sont de plus en plus performantes, bien que pour le moment elles restent vulnérables. Les problématiques de la non-authentification des stations d’ingénierie et du partage de clés privées par les automates attestent d’un manque de maturité au niveau de la sécurité qui peut cependant être partiellement expliqué par les contraintes propres au milieu industriel.

Des mesures basiques peuvent néanmoins permettre de détecter ou de se défendre contre des attaques utilisant les vulnérabilités :

  • La mise en place d’un mot de passe au niveau de l’automate empêche des utilisateurs non autorisés de modifier les programmes de l’automate
  • L’utilisation de logiciels de sécurité adaptés au milieu industriel, tel que ICS Cyber Vision, permet de détecter quels équipements effectuent des modifications de programmes ou des envois de commandes vers l’automate.

Source : Rogue7: Rogue Engineering-Station attacks on S7Simatic PLCs, E.Biham et al. (https://i.blackhat.com/USA-19/Thursday/us-19-Bitan-Rogue7-Rogue-Engineering-Station-Attacks-On-S7-Simatic-PLCs-wp.pdf)