Si, en cette fin d’année, vous entendez des cris et des plaintes dans la salle des serveurs à la place du clinquement des verres de Champagne, si vos informaticiens semblent préoccupés, même quand Amazon Web Services (AWS) fonctionne, et si les administrateurs système et les développeurs semblent épuisés quand vous arrivez au bureau, il y a une raison à cela : les vulnérabilités Log4j. Beaucoup d’articles généraux ont été publiés ces deux dernières semaines à ce sujet, et la plupart ont compris que c'était une mauvaise nouvelle. Comme l'a déclaré Jen Easterly, directrice de l'Agence américaine de cybersécurité et de sécurité des infrastructures (US Cybersecurity and Infrastructure Security Agency, CISA), « la vulnérabilité Log4j est la plus grave que j'aie vue au cours de ma carrière de plusieurs décennies ». Exerçant dans ce domaine depuis plus longtemps que Mme Easterly, selon mon avis - jamais très humble - sur Twitter, « #Log4Shell pourrait, sans exagération, être le pire problème de #sécurité informatique de notre génération ». Et si cela vous paraît effrayant, c'est parce que ça l’est vraiment.

Mais de quoi s'agit-il exactement ? Á ce niveau de l'histoire où il faut parler de « sécurité », « d’administrateur système » ou « de développeur », je renvoie au billet de blog publié sur le site New Stack, intitulé : « Log4Shell : We Are in So Much Trouble » (« L’énorme problème posé par Log4Shell »), qui fourmille de détails peu rassurants. Si vous êtes un simple mortel, voilà ce qui se passe et pourquoi ce problème est si difficile à gérer. Apache Log4j2 - dernière itération de Log4j - est une bibliothèque de journalisation Java open source extrêmement populaire. Si votre programme Java enregistre à peu près n'importe quoi, du nom de l'utilisateur au nombre de fois où il appelle un autre programme pour obtenir de l'aide, il est probable qu'il utilise Log4J2 pour faire ce travail. C'était bien. C'était formidable. Tout le monde était content. Mais, il y a quelques semaines, des chercheurs en sécurité ont découvert au cours d’une de leurs enquêtes que si l'on pouvait lui faire enregistrer une ligne de code malveillant, de mauvaises choses pouvaient se produire. Comment est-ce possible ? Apache Log4j2 n’a pas obtenu un score CVSS (Common Vulnerability Scoring System) « parfait » de 10 sur 10 ?

Une dernière mise à jour 2.17.1 de Log4j à appliquer d'urgence

En réalité, il s'agit de la plus mauvaise vulnérabilité en matière de sécurité qui puisse exister. Si l'un de vos programmes contient une version vulnérable de Log4j2, il peut être frappé par une attaque par défaut d'exécution de code à distance. S'il réussit, un attaquant peut faire n'importe quoi : jouer à Doom sur vos serveurs (sérieusement), infecter toutes les machines de votre réseau avec le botnet Mirai ou vous arnaquer avec un ransomware. Ah, j’oubliais : les pirates parrainés par des gouvernements exploitent également la vulnérabilité Log4j. Il suffit de demander au ministère belge de la Défense, qui se remettait encore d'une attaque la semaine dernière. Autre bonne question : celle des programmes susceptibles d’être ciblés. Eh bien, des milliers de programmes commerciaux largement utilisés sont tous des cibles potentielles. Parmi eux, on peut citer Apple iCloud, de nombreux programmes Cisco, le client et le serveur Minecraft, Steam, Twitter et de nombreux programmes VMware. Et si votre équipe ou des fournisseurs de logiciels indépendants (ISV) ont écrit vos programmes avec des composants logiciels comme Apache Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark et Struts, ces programmes peuvent également être attaqués. Et l’impact de cette faille de sécurité ne cesse de s'étendre

La bonne nouvelle, c’est qu'il existe un correctif - quatre correctifs en fait - pour les vulnérabilités de Log4j2. En bref, si vous mettez à jour toutes les copies de cette bibliothèque logicielle à la version 2.17.1 de Log4j, tout ira bien. Enfin presque. Car, c'est là que le bât blesse. Il faut mettre à jour toutes les copies jusqu'à la dernière. Et voici la partie la moins agréable : Log4j est caché dans des millions de programmes. Sans une nomenclature logicielle (SBOM), qui répertorie la liste de composants de chaque application, il n’est pas certain de pouvoir les trouver toutes. Et le SBOM est un concept nouveau. Personne n'en fabriquait l'année dernière, et encore moins il y a sept ans, lors de la sortie de Log4j2. Il faut donc les chercher. Et, parce que les programmes Java cachent leur code dans des structures emboîtées comme des poupées russes, par exemple les fichiers d'archive Java (JAR), trouver le programme qui nécessiterait un correctif peut être un véritable casse-tête.

Des équipes IT et sécurité sur le pont

Certes, il existe de nombreux outils, dont le CISA CVE-2021-44228_scanner, qui peut simplifier la vie des équipes de sécurité et de développement, mais cela représente toujours beaucoup de travail. Imaginez que quelqu'un vous demande de trouver toutes les références présentes dans des documents transmis à votre CEO depuis 2014… sans outils de recherche de texte faciles à utiliser. Ce serait un cauchemar, non ? Imaginons que vous ne les trouviez pas ? L'infrastructure IT de votre entreprise s'effondrera dans un désordre épouvantable. Alors, soyez gentil avec votre personnel IT. Au lieu de boire une coupe de Champagne le soir du Nouvel An, ils seront probablement encore en train de chercher et de nettoyer ce désordre. Et cela risque de prendre du temps. D’autant qu’ils auront encore beaucoup d'autres attaques à repousser avant que tout ne soit terminé. Bonne année ?