Par construction, les vulnérabilités dans nos logiciels et équipements informatiques sont fortuites, involontaires, et donc relativement imprévisibles. Et comme le « bug », cette erreur de programmation ou de conception, peut se trouver partout, son effet peut prendre des formes extrêmement variées.

La détection des vulnérabilités est essentiellement basée sur l’inventaire (et secondairement, sur les tests de pénétration). C’est un processus automatisable, pour lequel des outils peuvent aider, presque en « prêt à installer ». Nous allons ici donner des exemples de vulnérabilités de nature très différentes, et voir que le processus de correction n’est lui, pas un long fleuve tranquille.

 

Des vulnérabilités dans les logiciels

Les vulnérabilités les plus courantes concernent nos logiciels de tous les jours : notre navigateur web, un lecteur de fichiers PDF, un lecteur de vidéo… Et oui, un pirate peut prendre le contrôle de votre poste, en vous incitant à ouvrir un document spécialement conçu par lui, avec un logiciel vulnérable sur le poste.

Une vulnérabilité dans le navigateur web déployé sur les postes sera plus ou moins critique, dans le contexte d’une organisation, selon la présence ou pas d’un système de protection périmétrique : filtrage web, UTM.

Une vulnérabilité sur les logiciels serveurs est tout de suite plus grave. Si elle concerne un serveur exposé à internet, la réaction peut nécessiter des actions urgentes, voire des mesures conservatoires d’arrêt du service.

Pour limiter les risques d’en arriver là, il est essentiel de gérer son parc de logiciel et de systèmes d’exploitations. Pour les produit Microsoft, on retrouve là le « Windows Update » et autres « Tuesday Patch ». Mais pour la myriade d’autres éditeurs qui interviennent dans un système informatique d’entreprise, ça dépend. Ça dépend de l’éditeur, donc c’est compliqué. Et pour autant, c’est indispensable, même si cela demande des outils et des hommes.

 

Des vulnérabilités dans les algorithmes eux-mêmes

Certaines vulnérabilités trouvent leur origine dans des « étourderies » dans le principe même du programme, parfois détectées des années après que celui-ci ait été déployé en grand nombre. C’est le cas par exemple de Zérologon, qui a affecté nos Windows à la fin de l’été 2020. La conséquence aurait pu être particulièrement gênante : il n’est même pas possible de corriger le programme, c’est le mécanisme concerné, dans ce cas un mécanisme d’authentification entre ordinateurs, qui ne doit plus être utilisé. Nous avons eu de la chance : il s’agissait d’un mécanisme ancien, et d’autres plus récents étaient déjà disponibles pour prendre le relais. Cette fois-ci…

Les attaques de type « Poodle » (yes, « caniche » in french) tirent également parti d’une erreur d’inattention dans la conception des algorithmes de chiffrement : les règles de « bourrage » des messages chiffrés, qui permettent d’arrondir la longueur du message selon les besoins du chiffrement, introduisent un moyen pour un attaquant de détecter les octets du message en clair.

En matière de vulnérabilité cryptographique, bien souvent, ce qui rend la correction possible, c’est une bonne pratique bien établie : la « suite cryptographique », c’est à dire l’algorithme utilisé et ses paramétrages, doit être réglable et modifiable (en plus de la clé de chiffrement bien entendu !)

 

Le progrès peut engendrer des vulnérabilités

Tous les administrateurs système et réseau ont entendu parler de « SHA-1 » et « MD-5 », deux algorithmes cryptographiques qui sont depuis plusieurs années considérés comme non fiables, d’une part en raison de l’augmentation de la capacité des ordinateurs (la « force brute »), et d’autre part en raison des nombreux travaux mathématiques pour en déterminer la robustesse (la « cryptanalyse »).

En 2003, le rafraichissement du principe des tables arc-en-ciel, a d’un coup renvoyé au placard certains mécanismes d’authentification des anciennes versions de Windows. Toujours est-il que, plus de quinze ans après, on peut encore trouver quelques vestiges qui constituent autant de portes d’entrée dans les systèmes informatiques mal entretenus.

C’est bien la recherche en mathématiques qui pourrait déclencher le « big one ». En effet, la très grande majorité des mécanismes de « confiance numérique » est basé sur un algorithme presque monopolistique, le fameux « RSA », lequel dépend de l’impossibilité en pratique de factoriser de grands nombres. Personne n’a jamais prouvé l’inexistence d’un algorithme de factorisation efficace. On pense même que l’informatique quantique apportera un tel algorithme. On touche du bois !

Tous ces exemples rappellent à quel point il faut rester humble et prudent devant la conception et même la programmation d’une fonction cryptographique. Car le domaine, on le voit, et un vivier de vulnérabilités.

 

Des vulnérabilités dans les « micrologiciels »

En 2018 ont été révélées des faiblesses dans les disques « Self Encryptive Drive » (SED) : on s’est parfois rendu compte que la clé de chiffrement du disque était fixe et sans rapport avec la clé fournie par l’utilisateur… Oui, on est désolé, on a oublié de changer le programme après les tests… (résumé en page 14 en haut à gauche…). Pour corriger, c’est simple : il faut changer le disque. Et essayer de négocier une ristourne sur la prochaine commande. Est-ce un bug tout à fait « sincère », ou une porte dérobée déguisée en bug ? Oui, on se demande !

Une autre affaire, cocasse seulement pour ceux qui n’ont pas été concernés : une certaine série de disques durs qui s’arrêtent de fonctionner au bout de 32768 heures, tous exactement en même temps, les données étant perdues… Imaginez celui qui a déployé une grosse baie de stockage « high end » de ces disques à usage professionnel. Dans ce cas, la solution « d’urgence » consistait à arrêter proprement et redémarrer, avant le délai fatidique. Et la solution définitive passait bien par une mise à jour du « firmware ». Ce qui n’est toujours évident à planifier.

 

Des vulnérabilités dans les concepts eux-mêmes.

En 2017, nous avons découvert la vulnérabilité « Meltdown », et toute la famille des « Spectres et ForeShadow ». Meltdown a au moins deux particularités originales :

• la faiblesse réside dans le silicium lui-même, le « hardware »
• et elle est lié aux optimisations très sophistiquées de nos microprocesseurs modernes, notamment la possibilité pour un processeur de « supposer » le résultat d’un test à venir, et d’ « abandonner » le résultat d’un bout de code s’il s’avère, a posteriori, que le bout de code ne devait pas être exécuté. Oui, c’est tiré par les cheveux, mais cela permet d’augmenter les performances. Meltdown est-il un bug ? Ce n’est pas évident : il tire juste parti de cette « exécution spéculative »

Le résultat : sur un serveur, un utilisateur peut lire la mémoire de tout le système, notamment les autres utilisateurs, y compris les informations secrètes. Meltdown est bien une vulnérabilité critique. Comment la corriger ? En achetant un nouveau processeur non affecté par le problème… Ce n’est pas possible ? Heureusement que les éditeurs de systèmes d’exploitation sont arrivés à la rescousse en intégrant des « bidouilles » pour éviter les situations à risque. Parfois au prix d’une vraie diminution de performance engendrée par ces pirouettes demandées au système d’exploitation pour bloquer les possibilités d’attaques.

 

Au coeur même de la confiance numérique

Ce que l’on appelle le « boot UEFI » consiste, lors des phases de démarrage d’un ordinateur, à ce que chaque étape de démarrage valide le code du programme à qui elle passe le contrôle pour l’étape suivante. Le « BIOS » de l’ordinateur (qui affiche les tous premiers messages sur l’écran), est chargé de valider que le système d’exploitation (par exemple Windows) est bien celui qu’on croit, avant de lui passer le contrôle. Cette chaîne de confiance est basée sur des outils cryptographique similaires à ceux utilisé pour le web (le « s » dans « https »).

L’intention était bonne, mais malheureusement, certaines implémentations de l’UEFI n’ont pas échappé à des vulnérabilités. Pourquoi ne pas nous remettre un petit bouton physique, en logique câblée, sans programmation, comme nous avions sur les disquettes 3.5 pouces le petit loquet de protection contre l’écriture ? Là, on se rend compte du tiraillement entre la construction « sans couture » d’un système sûr, et la facilité pour l’utilisateur. Pourquoi pouvons-nous mettre à jour le BIOS depuis Windows, sans intervenir physiquement dans le boitier de l’ordinateur ? Pour simplifier la vie de l’utilisateur. Et du coup, les malwares en profitent.

 

 

Mais quand cela va-t-il se calmer ? Jamais. Le monde du numérique est tellement rapide que le décideur qui délaisserait la maintenance de son SI s’expose rapidement à des problèmes. Alors, comment se défendre ?

La dernière vulnérabilité d’Exchange, en mars 2021, vient de nous faire passer quelques jours, et nuits, chargés. Et de nous rappeler quelques règles de base de la sécurité informatique :

• ne jamais faire confiance à un composant unique
• appliquer le concept de défense en profondeur
• avoir un processus réactif, outillé, staffé et prioritaire, de gestion des patchs et vulnérabilités
• pour vivre heureux, vivons cachés

Les faiblesses de la machine Enigma nous avaient bien servi en son temps. Mais aujourd’hui, ce sont bien nos données qui sont attaquées de toutes parts. Donc : à bon défendeur, salut !