Lorsque Ryan Castellucci a récemment fait l’acquisition de panneaux solaires et d’un système de stockage sur batterie pour sa maison située à proximité de Londres, il a été séduit par la possibilité d’utiliser un tableau de bord open source pour surveiller et contrôler le flux d’électricité produit. Au lieu de cela, il a gagné beaucoup, beaucoup plus : environ 200 mégawatts de capacité programmable pour charger ou décharger sur le réseau à volonté. Cela représente suffisamment d’énergie pour alimenter environ 40 000 foyers.
Castellucci, dont les pronoms sont ils/eux, a acquis ce contrôle remarquable après avoir obtenu l’accès au compte administrateur de GivEnergy, le fournisseur de gestion d’énergie basé au Royaume-Uni qui a fourni les systèmes. En plus du contrôle sur environ 60 000 systèmes installés, le compte administrateur – qui équivaut au contrôle racine des produits connectés au cloud de l’entreprise – leur a également permis de répertorier les noms, adresses e-mail, noms d’utilisateur, numéros de téléphone et adresses de tous les autres clients de GivEnergy (ce que le chercheur n’a pas réellement fait).
« Mon plan est d’installer Home Assistant et de l’intégrer à celui-ci, mais en attendant, j’ai décidé de le laisser communiquer avec le cloud », a écrit Castellucci jeudi, en faisant référence au matériel récemment installé. « J’ai configuré une charge programmée, puis j’ai commencé à expérimenter avec l’API. Le soir suivant, j’avais le contrôle d’une centrale électrique virtuelle composée de dizaines de milliers de batteries connectées au réseau. »
Toujours brisé après toutes ces années
La cause du contournement d’authentification découvert par Castellucci était une interface de programmation protégée par une clé cryptographique RSA de seulement 512 bits. La clé signe les jetons d’authentification et est l’équivalent approximatif d’une clé principale. La taille des bits a permis à Castellucci de factoriser la clé privée sous-jacente à l’ensemble de l’API. La factorisation a nécessité 70 $ de coûts de cloud computing et moins de 24 heures. GivEnergy a introduit un correctif dans les 24 heures suivant la divulgation privée de la vulnérabilité par Castellucci.
Le premier exemple connu de factorisation de RSA 512 bits a été réalisé en 1999 par une équipe internationale de plus d’une douzaine de chercheurs. Il a fallu sept mois à un supercalculateur et à des centaines d’autres ordinateurs pour réaliser cet exploit. En 2009, des amateurs ont passé environ trois semaines à factoriser 13 clés de 512 bits pour protéger le micrologiciel des calculatrices Texas Instruments contre la copie. En 2015, des chercheurs ont démontré la factorisation en tant que service, une méthode qui utilisait le cloud computing d’Amazon, coûtait 75 $ et prenait environ quatre heures. À mesure que la puissance de traitement a augmenté, les ressources nécessaires à la factorisation des clés sont devenues de plus en plus réduites.
Il est tentant de reprocher aux ingénieurs de GivEnergy d’avoir basé la sécurité de son infrastructure sur une clé facile à casser. Castellucci, cependant, estime que la responsabilité devrait plutôt être attribuée aux créateurs des bibliothèques de codes sur lesquelles les développeurs s’appuient pour mettre en œuvre des processus cryptographiques complexes.
« S’attendre à ce que les développeurs sachent que le RSA 512 bits n’est pas sécurisé ne fonctionne clairement pas », a écrit le chercheur en sécurité. « Ce ne sont pas des cryptographes. Ce n’est pas leur travail. L’échec n’était pas que quelqu’un ait utilisé le RSA 512 bits. C’était une bibliothèque sur laquelle ils s’appuyaient. laisse les.”
Castellucci a noté qu’OpenSSL, la bibliothèque de code cryptographique la plus utilisée, offre toujours la possibilité d’utiliser des clés de 512 bits. Il en va de même pour la bibliothèque de cryptographie Go. Par coïncidence, la bibliothèque de cryptographie Python a supprimé cette option il y a seulement quelques semaines (la validation du changement a été effectuée en janvier).
Dans un e-mail, un représentant de GivEnergy a renforcé l’évaluation de Castellucci en écrivant :
Dans ce cas, l’approche de chiffrement problématique a été adoptée par une bibliothèque tierce il y a de nombreuses années, lorsque nous étions une petite start-up avec seulement 2 développeurs de logiciels assez juniors et une expérience limitée. Leur hypothèse à l’époque était que, comme ce chiffrement était disponible dans la bibliothèque, il était sûr de l’utiliser. Cette approche a été transmise au cours des années intermédiaires et cette partie de la base de code n’a pas été modifiée de manière significative depuis la mise en œuvre (elle n’a donc pas été soumise à l’examen de l’équipe plus expérimentée que nous avons maintenant en place).