Tatu Ylonen : les entreprises sont menacées par leurs mauvaises habitudes avec SSH

Lorsque Tatu Ylonen a créé le protocole Secure Shell en 1995, il n'aurait pas pu imaginer à quel point il serait devenu répandu quelques décennies plus tard – ni imaginer les risques de sécurité induits par l’ampleur de cette adoption.

Ylonen avait développé SSH comme un moyen d'authentifier et de sécuriser les communications sur Internet, mais les mauvaises pratiques de sécurité ont largement produit l’effet inverse pour beaucoup d’entreprises. Selon Ylonen, les entreprises ont généré tellement de clés SSH qu'elles les ont perdues de vue. Autant de clés qui, si elles tombent entre de mauvaises mains, pourraient conduire à des brèches dévastatrices.

Quel regard portez-vous aujourd’hui sur SSH ? Comment son utilisation a-t-elle évolué au cours des 10 dernières années et comment vous le voyez utilisée aujourd'hui ?

Tatu Ylonen : le seul grand changement est que SSH est nativement présent dans de nombreux appareils. Tout Linux, tous les Unix, tous les Macs, et même les terminaux Android disposez d’un service SSH qu’il est possible d’activer. SSH est présent dans pratiquement tous les périphériques intégrés. Il est livré dans le firmware de la plupart des serveurs modernes intégrant IPMI (Intelligent Platform Management Interface). Il est partout. J’ai vu des systèmes de divertissement en vol démarrer des services SSH. Vous pouvez voir les messages pendant le démarrage. Il est partout.

Un autre changement est que SSH est utilisé dans un certain nombre d’appareils qui ne sont pas régulièrement mis à jour, comme les caméras de sécurité dont le firmware ne dispose pas de fonctionnalités de mise à jour. Et là, dès que l’on parle Internet des objets, cela doit changer. Je pense que la société s'effondrera si nous avons des dispositifs qui commencent pousser des données à quelqu'un dans le cadre d’attaques en déni de service distribué (DDoS). Je vois quelques pistes pour y remédier.

Et cela commence par la responsabilité. Il faut forcer [les fabricants d’objets connectés] à faire les choses correctement et en toute sécurité, ou à cesser leurs activités. Ensuite, utiliser vraiment de bons systèmes de mise à jour. La responsabilisation des constructeurs peut pousser à cela. Enfin, transformer en briques [les appareils non conformes à ces règles].

En faire des briques ? Que voulez-vous dire ?

Oui. Utiliser les mêmes vulnérabilités pour les arrêter de manière permanente et définitive. Bien sûr, cela implique probablement la responsabilité des constructeurs. Pour le moment, ce n'est pas légal. Mais si vous appréhendez cela du point de vue de la société, si elle est amenée à arrêter les réseaux, voire couper les télécommunications dans certains cas, ou faire face à des décès parce que les services d'urgence ne peuvent pas se rendre sur place parce que vous ne pouvez même pas les appeler… Nous ne pouvons pas permettre cela. Il faut faire quelque chose.

Mais alors, par quoi commencer ?

Bon nombre des détournements d’appareils connectés s’appuient sur des mots de passe par défaut. Je pense que c’est le correctif le plus simple à mettre en place pour les fabricants : ne pas avoir de mots de passe par défaut, et utiliser un mot de passe unique pour chaque appareil, indiqué au dos. Souvent, la sécurité commence avec des choses assez simples. Un mot de passe unique permet déjà d’avancer, mais beaucoup ne l'ont pas fait. Et SSH est utilisé de plus en plus dans ces objets connectés.

Des millions de caméras de sécurité et de systèmes de réception par satellite sont vulnérables en raison d'une mauvaise configuration. C’est trivial à corriger si vous avez un mécanisme de distribution de mises à niveau. Ceux qui ne le proposent pas risquent d’y perdre leur réputation. Mais ils pourraient aussi voir engagée leur responsabilité.

Au-delà, nous avons SSH dans les centres de calcul. Là, il est partout pour l’administration des routeurs, des commutateurs, des couches de virtualisation, etc. Là, le plus gros problème est la gestion des SSH, qui sont juste un mécanisme d'authentification. Il y a une clé cryptographique dans un fichier et l’on l’installe sur un serveur. Avec la clé, il est possible de se connecter sans avoir à taper de mot de passe. C’est utilisé pour tous les processus automatisés : gestion de confirmation automatisée, provisionnement automatisé, audits automatisés, interventions d'urgence, copie de données dans des centres de calcul de récupération après sinistre, etc.

Et il s’avère que ces clés ne sont pas gérées. Mais l'accès qu'elles offrent est fondamentalement comme des mots de passe sur le système d'exploitation. Elles donnent un accès shell généralement. Dans une banque, nous avons découvert que 10 % des clés SSH accord  aient des accès root – l'accès administratif de niveau le plus élevé, qui vous permet de lire tous les fichiers, de modifier les fichiers, d'installer de nouvelles extensions du noyau ou de reprogrammer le microprogramme de l’équipement concerné. On peut, avec de tels accès, transformer des équipements en briques. Et théoriquement, cela peut être fait à des dizaines de milliers de serveurs, ce qui pourrait affecter plusieurs entreprises et infrastructures critiques simultanément.

Dans une banque de Wall Street, opérant environ 15 000 serveurs, dont un quart relevant de l'infrastructure, et 500 applications, les plus critiques pour certaines. Nous y avons trouvé 3 millions de clés SSH. Trois millions, et 10 %, soit 300 000 de ces clés offrent un accès root. Certaines donnaient accès à des centres de calcul de reprise après sinistre, qui sont censés prendre le relais en cas de panne. Mais si quelqu'un infiltre un centre de calcul, et tombe sur un mot de passe qui permet d'accéder à un centre de calcul de repli, utilisé pour copier les données vers des systèmes de sauvegarde, et le pirate prend la main sur ces systèmes, c’est foutu.

Pourquoi y a-t-il autant de clés SSH là-bas ? À quoi sont-elles destinées ?

Dans de nombreux cas, elles ont été installées pour de bonnes raisons et de bonnes intentions, comme lorsqu’un administrateur Oracle veut juste être en mesure de se connecter à partir de son compte personnel aux différentes bases de données dans l'entreprise pour conduire des opérations d’administration et de maintenance de manière automatisée.

Le problème est qu’il s’agit de comptes assez critiques qui nécessiteraient normalement de passer par des systèmes de gestion des accès privilégiés. Et que les systèmes de contrôle d’accès sont ainsi contournés. Ainsi, une personne mal intentionnée pourrait accéder aux bases de données sans aucun recours. Y compris pour des données sensibles.

Est-ce l’omniprésence de SSH qui rend si préoccupant le manque d’administration des clés ?

Je pense que le principal problème est que les responsables de la gestion des identités et des accès n’ont pas connaissance de ces clés SSH. Historiquement, ils viennent du monde Windows ou n’ont tout simplement pas d’expérience de l’administration des environnements Unix et ne soupçonnent même pas l’existence de ces clés. Ce n'était pas décrit dans les livres. Ce n’est toujours pas mentionné dans la plupart des livres sur la gestion des identités et des accès. Ils parlent de mots de passe et d'authentifications à deux facteurs, ils parlent de SSO, mais ils ne parlent pas de clés SSH.

Je pense que c'est d’abord une question de formation. Les politiques ne couvrant pas ce dont on n’est pas au courant. Et OpenSSH, en configuration par défaut, permet à tout utilisateur qui se connecte de configurer des éléments d’authentification supplémentaires pour son compte – des informations d'identification permanentes supplémentaires. Des éléments que, en général, seul l’utilisateur légitime est susceptible de pouvoir fournir. Reste qu’il est possible de le configurer pour que seule la racine d'un système automatisé puisse installer des clés. Par défaut, ce n’est toutefois pas le cas.

Et parfois, des clés sont installées… pour rien. Dans cette banque que nous avons étudiée, 90 % de 3 millions de clés n'ont jamais été utilisées. Et nous avons surveillé l'environnement pendant des années.

Donc, ils traitaient les clés SSH comme des mots de passe jetables, sauf qu'ils ne révoquaient pas les clés ?

Oui. Un de nos ingénieurs avant-vente est allé récemment voir un organisme de santé qu'il a conseillé il y a 10 ans et a essayé une vieille clé. Et elle fonctionnait encore. Nous en sommes là. Ainsi, maintenant, presque toutes les grandes entreprises se trouvent dans une situation où elles ont des centaines de milliers, voire des millions d'informations d'identification qui permettent d'accéder à leurs serveurs. Elles ont peu de visibilité sur les accès qu’elles sont susceptibles de fournir, qui a ces clés ou a été en mesure de les obtenir au fil des ans. Pourtant, leurs systèmes sont entièrement dépendants des accès et de l'automatisation mis en œuvre avec ces clés.

Dans la banque que j’évoque, il y avait environ 5 millions de connexions SSH chaque jour, la plupart automatisées à l'aide de clés. Et cela concernait les opérations back-end sur d'autres serveurs, comme les transferts de données de journalisation, les transactions par lots, les transferts de fichiers de configuration, etc.