Comme le Covid, qui semble ne jamais en finir, le virus informatique Log4Shell va-t-il pourrir la vie des entreprises encore longtemps ? C'est bien parti pour en tout cas. Car six mois après son apparition, la plus grande faille informatique de l'histoire est toujours loin d'être résolue pour des milliers d'entreprises dans le monde, qui en subissent encore les conséquences.

Tout a commencé le 24 novembre 2021. Ce jour-là, des chercheurs découvraient une vulnérabilité informatique majeure, qualifiée "d'incident épidémique" comme le qualifiait dans les colonnes de La Tribune Erka Koivunen, responsable de la sécurité chez F-Secure. Située sur le composant logiciel Log4j, la faille rapidement nommée "Log4Shell" avait déclenché un véritable branle-bas de combat dans les équipes de sécurité des entreprises. Et pour cause : Log4j était utilisée par des milliers d'applications codées en Java (un des langages informatiques les plus utilisés au monde) et l'incident concernait donc des millions de machines appartenant à des milliers d'entreprises.

6 mois plus tard, bien qu'éclipsé par les craintes liées à la guerre en Ukraine, la menace Log4Shell n'a pas disparu. Le pic de la crise est passé mais la vulnérabilité entame désormais un nouveau cycle de vie. "Nous arrivons aujourd'hui au bout de la queue de la comète", explique à La Tribune Samuel Hassine, Directeur Stratégie et Opérations de cybersécurité de l'éditeur Tanium. Autrement dit, l'étape de la réponse à incident -particulièrement longue en raison des particularités de la faille- ne se termine que maintenant. Mais pour autant, l'exploitation de Log4Shell par des acteurs malveillants n'en est qu'à ses débuts.

Une vulnérabilité longue à corriger

Samuel Hassine fait état d'un début d'accalmie après des mois très compliqués pour certaines entreprises, qui ont peiné à traquer la faille dans leurs réseaux informatiques. "Chez certains, la remédiation de la faille n'a pris que quelques jours. Mais chez d'autres, dépendants d'éditeurs extérieurs, elle a traîné dans le temps", développe-t-il. L'Apache Software Foundation, qui diffuse Log4j, a publié un correctif pour réparer la faille dès que celle-ci a été connue. Le problème, c'est que c'était ensuite à chaque éditeur utilisant Log4j de déployer lui-même ce patch. Certains s'y sont attelés immédiatement, d'autres ont traîné, soit par désintérêt, soit par méconnaissance du composant. Et c'est ici que la crise est passé à deux vitesses.

D'un côté, des entreprises qui n'utilisent qu'un petit nombre d'applications, le plus souvent populaires et récentes. Les éditeurs de ces applications les ont immédiatement mises à jour, et la crise n'a donc duré pour elles qu'une poignée de jours. De l'autre, des entreprises de plus grande taille, au réseau informatique plus complexe et divers. "Dans la santé par exemple, de nombreux logiciels sont codés en Java, et parmi eux, certains sont très anciens et répondent à des tâches très spécifiques. Le problème, c'est que ces vieux logiciels ne sont parfois plus mis à jour, et leurs éditeurs ne sont même plus joignables dans certains cas.", développe Samuel Hassine.

Pour cette seconde catégorie d'entreprises, un véritable casse-tête a démarré : il leur a fallu lister les applications utilisées sur leur parc informatique, trouver celles qui utilisent Log4j, s'assurer que les éditeurs ont déployé le patch, et mettre les applications à jour. Problème : le processus de mise à jour n'est pas si simple qu'il n'y paraît. "Dans certains cas, il faut mener au préalable une analyse d'impact pour être sûr que le patch ne va pas tout casser", tempère Antoine Richer, expert en sécurité applicative au sein d'Accenture Technology en France. "S'il n'est pas envisageable de déployer le patch, il est aussi possible de déployer un patch virtuel, en supprimant la fonctionnalité responsable de la vulnérabilité au niveau de l'application", complète-t-il. Autrement dit, les responsables de la sécurité des entreprises concernées ont dû juger de chaque application au cas par cas. Un travail de dentelle chronophage et exigeant.

Une faille bien intégrée à l'arsenal des cyberattaquants

Conséquence directe de cette difficulté à remédier à Log4Shell, en avril, les chercheurs de Rezilion alertaient que la faille était encore présente sur 90.000 applications et 68.000 serveurs exposés à Internet (et donc vulnérable aux attaques). Et encore, il ne s'agissait que de "la face émergée de l'iceberg". Ces milliers de machines vulnérables sont autant de portes d'entrée pour les cybercriminels. Résultat, les alertes à l'exploitation de Log4Shell se sont multipliées à intervalles réguliers.

Pas plus tard que le 23 juin, le Cisa -le gendarme américain de la cybersécurité- a averti que Log4Shell était exploitée par des acteurs malveillants pour atteindre des serveurs de VMware Horizon (un logiciel de virtualisation de poste de travail), très utilisé par les entreprises. Une fois introduits sur ces serveurs, les attaquants peuvent se déplacer sur les postes informatiques de leurs victimes, à la recherche de systèmes internes qui pourraient contenir des données sensibles. Trois mois plus tôt, les chercheurs de Mandiant accusaient le groupe de hackers APT41, connu sous le nom de Halfnium et affilié au gouvernement chinois, d'avoir exploité avec succès Log4Shell pour espionner les gouvernements de "au moins" six Etats américains.

Plus généralement, de nombreux groupes cybercriminels -aux objectifs pécuniers pour certains, stratégiques pour d'autres- ont inclus Log4Shell dans leurs kits d'attaques, c'est-à-dire dans le trousseau de combines qu'ils tentent d'exploiter systématiquement pour entrer dans le réseau de leurs cibles. Concrètement, ils scannent les machines connectées à Internet de leurs cibles à la recherche de tout un ensemble de vulnérabilités très répandues (à l'instar de Log4Shell) dont ils possèdent les méthodes d'exploitation.

D'après l'expert Jamie Moles de l'éditeur ExtraHop, ces fonctionnalités sont même directement incorporées dans les botnets -des réseaux de machines informatiques infectées disponibles à la location pour lancer des cyberattaques coordonnées. Résultat : ExtraHop comptait 147.000 scans de la faille Log4j rien qu'en mai, et presque autant les mois précédents. Les cybercriminels cherchent avant tout à trouver l'accès le plus facile (et le moins onéreux) au réseau de leurs victimes, et Log4Shell est une porte particulièrement facile à emprunter.  "Java est un des langages les plus répandus dans les applications web, qui sont par définition exposées à Internet", rappelle Antoine Richer.

Les développeurs téléchargent massivement des versions vulnérables de Log4j

Si Log4Shell continue d'être exploité, ce n'est pas seulement à cause d'un retard dans le déploiement de correctifs. L'éditeur Sonatype observe depuis plusieurs mois un étrange phénomène qui ne faiblit pas : plus d'un tiers des versions de Log4j téléchargées sur Mazen (un des répertoires de référence) ne sont pas à jour, et contiennent donc la faille. Autrement dit, les développeurs intègrent un composant logiciel vulnérable aux attaques. En février, le CTO de l'entreprise Brian Fox affirmait au Wall Street Journal que les développeurs concernés "ne savent pas ce qu'il se passe dans leurs logiciels". Depuis, il présente régulièrement ses observations, sans parvenir à faire changer le statu quo.

Interrogé par une commission sénatoriale américaine en février, le président de l'Apache Software Foundation a rappelé qu'il existait plusieurs scénarios justifiant l'appel à d'anciennes versions de Log4j, par exemple pour faire de la recherche en sécurité ou parce que d'autres composants nécessitent de garder une version périmée. Mais ces cas particuliers ne suffisent pas à expliquer les plus de 33% de téléchargements de versions vulnérables.

Pour éviter de continuer dans cette voie, les professionnels tâchent de tirer des enseignements des incidents de sécurité comme Log4Shell. "Le milieu de la sécurité applicative s'intéresse de plus en plus à la supply chain", explique Antoine Richer, "on prend conscience qu'une grande partie du code des applications que l'on développe provient de bibliothèques qui viennent de l'extérieur. Il faut savoir ce qu'on importe dans son code, pour maîtriser son application et réagir plus efficacement en cas d'incident." Ces bonnes pratiques s'installent progressivement, mais les failles, elles, continuent d'être découvertes à un rythme effréné.

François Manens

27 Juin 2022, 9:25

Partager :