Cybersécurité - Innovations digitales et numériques

Par contre, ce n'est pas le cas des quelque 20 % de serveurs rendus vulnérables et qui ne l'étaient pas quand l'attaque a été révélée : selon une étude réalisée par le développeur de logiciels Yngve Nysæter Pettersen, il semble que certains opérateurs ont remplacé des versions sûres d'OpenSSL par des versions non corrigées. « Il est possible que le battage médiatique autour d'OpenSSL a conduit certains administrateurs à croire que leur système n'était pas sécurisé ». Plus la pression administrative et la nécessité « de ne pas rester sans rien faire », les aurait pousser « à déclencher la mise à niveau d'un serveur non affecté avec une nouvelle version non corrigée du système, probablement parce que la variante n'avait pas encore été officiellement patchée », a-t-il suggéré. Nysæter Pettersen a démarré son scan le 11 avril : au cours des deux semaines qui ont suivi, près de la moitié des serveurs vulnérables avaient été corrigés. Globalement, le nombre de serveurs tournant avec une version vulnérable d'OpenSSL a baissé de 5,36 % à 2,77 %. Cependant, l'application de correctif sur les serveurs vulnérables a presque complètement cessé. « Mercredi dernier, 2,33 % des serveurs n'avaient toujours pas été corrigés », a-t-il encore ajouté.

Le 7 avril, le projet OpenSSL a livré un correctif pour patcher ce bug, et nombre de services informatiques se sont précipités pour corriger le logiciel sur les serveurs et dans certains systèmes d'exploitation client. « Le 17 avril, une grande majorité des serveurs exposés avait été corrigés », avait déclaré Sucuri Security dans un billet de blog ce jour-là. Mais, si la totalité des 1000 premiers sites classés par Alexa étaient à l'abri, Sucuri a trouvé de plus en plus de sites exposés au fur et à mesure qu'elle élargissait son balayage. Ainsi sur les 10 000 premiers sites, 0,53 % étaient vulnérables, sur les 100 000 premiers, le taux passe à 1,5 %, et sur le premier million, Sucuri arrive à 2 % de sites vulnérables.

« Comme il nous a été douloureusement rappelé que la rectitude du code dans les bibliothèques TLS était cruciale sur Internet aujourd'hui, nous voulons nous assurer que ce code est solide comme le roc avant de le livrer à des millions d'utilisateurs de Firefox », a indiqué hier Daniel Veditz, responsable en sécurité de l'éditeur. « Nous nous intéressons principalement à des bugs qui permettent la construction de chaînes de certificat qui sont acceptées comme valides alors qu'elles devraient être rejetées, et à des bugs dans le nouveau code qui conduiraient à exploiter une corruption de mémoire ».