Comme cadeau de fin d’année, on a vu mieux. Révélée la semaine dernière, la faille Log4Shell a provoqué un branle-bas de combat dans les services informatiques qui risquent de passer une partie de la période des fêtes à gérer cet épineux problème. Car cette faille est non seulement très dangereuse — un score de criticité de 10/10 — mais aussi difficile à patcher. En effet, le bug se loge dans un module standard de Java et se retrouve donc dans un grand nombre de logiciels.
« La première grande difficulté à laquelle sont confrontées les entreprises, c’est de réaliser un inventaire de leurs actifs logiciels pour savoir où il faut agir », nous explique David Grout, directeur des technologies pour l’Europe chez Mandiant. En fonction de la complexité du système d’information, cela peut prendre quelques heures à quelques jours, voire plus.
Le jeu des poupées russes
Il faut ensuite attendre le (bon) patch. Certes, la fondation Apache a rapidement mis à disposition un correctif pour le module défectueux (log4j v.2.15), mais il s’est avéré qu’il n’était pas suffisant. Depuis, deux autres ont été publiés (v2.16 et v2.17). Ceux qui se sont dépêchés au tout début vont donc pouvoir s’y recoller. Ensuite, tout dépend de la profondeur logicielle du module défectueux. L’appli vulnérable peut avoir un lien de dépendance direct ou indirect avec log4j. Et dans ce second cas, il n’est pas rare d’avoir plusieurs niveaux d’interdépendance. Ainsi, l’appli à patcher peut par exemple contenir un module qui contient un module qui intègre log4j. « C’est un peu comme les poupées russes », glisse David Grout.
Le patch final ne peut arriver que lorsque tous les niveaux précédents ont été résolus. Ce qui peut prendre du temps, surtout s’il s’agit de projets open source. Les ingénieurs de Google ont jeté un œil à la plate-forme Maven Central, le principal dépôt de logiciels open source du monde Java. Il s’avère que 35 563 paquets logiciels sont affectés par Log4Shell, soit 8 % de l’ensemble des codes référencés. Et pour 80 % d’entre eux, la dépendance est indirecte. Pour la majorité d’entre eux, il y a même plus de cinq niveaux d’interdépendance !
En moins d’une semaine, les développeurs ont réussi à patcher 4 620 paquets. C’est très impressionnant, mais cela ne représente que 13 %. Il faudra des mois, voire des années avant que l’ensemble des paquets affectés soient corrigés. Évidemment, les paquets les plus utilisés et les plus importants sont traités en priorité, c’est pourquoi il ne faut pas non plus sombrer dans la dépression.
A découvrir aussi en vidéo :
Mais même quand le patch final d’une application est disponible, ce n’est pas fini. « On ne peut pas mettre à jour un système d’information comme on met à jour un smartphone. Il faut d’abord tester le patch et vérifier qu’il n’y aura pas d’impact négatif sur la production. Dans certains cas, cela ne sera pas possible et il faudra trouver d’autres solutions. C’est un processus qui va certainement durer encore des semaines. C’est une course de fond qu’il faut bien organiser pour ne pas cramer les équipes », souligne David Grout.
En attendant, les pirates vont évidemment tenter de profiter au maximum de cette période de transition pour exploiter la faille en question. Les premières attaques ont déjà commencé, avec l’installation de mineurs de cryptomonnaie, de portes dérobées et de rançongiciels. Et ce n’est pas fini. Les variantes ne cessent de se multiplier. La dernière en date a été trouvée par les chercheurs en sécurité de Blumira. Ainsi, la faille peut désormais être exploitée par l’intermédiaire d’une simple page web vérolée. « Ce vecteur étend considérablement la surface d’attaque et peut avoir un impact sur les services même exécutés en localhost et sans être exposés à aucun réseau », souligne Blumira. Pour les pirates, c’est sûr, la fin d’année sera une sacrée fête.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
