Par Cédric Boddi, Conseiller Principal, Développement et Technologies
La fin de semaine du 09 décembre 2021 aura vu une faille informatique émerger qui aura et fait toujours trembler beaucoup d’acteurs du secteur des TI … La nouvelle est tombée du côté de la sphère cybersécurité de Twitter : une nouvelle faille informatique, utilisant une faiblesse de Log4J rendrait vulnérable et donc attaquable les SI (Systèmes d’Information) utilisant Java. Log4J est une librairie open source populaire (sinon LA plus populaire) du monde JAVA pour tout ce qui touche aux besoins de journalisation.
CVE-2021-44228 ou Log4Shell
Le joli matricule CVE-2021-44228 n’est en fait que le nom officiel de cette faille, qu’on préfèrera appeler «Log4Shell», car plus simple et intuitif.
Son principe d’attaque est très simple. Que ce soit sur le plan théorique ou pratique : il s’agit de faire en sorte que la librairie Log4J (via un mécanisme interne de cette librairie) exécute le code malicieux de l’assaillant au moment de la tentative de journalisation. Ce qui lui permet alors d’avoir accès jusqu’au contrôle total du server attaqué, l’installation de rançongiciels, etc.
Impact de Log4Shell
Pour se faire une idée de l’impact théorique de cette faille, il faut se rappeler de la phrase vendeuse mise en avant lors de l’installation de Java sur le moindre ordinateur :
Soit: Plus de 3 milliards d’appareils utilisent Java
Ainsi, ce ne sont plus simplement les acteurs des TI seuls qui sont impactés, mais potentiellement tout ce qui est connectable à un réseau. Cela va des produits Cloud Apple aux produits Oracle, en passant par VMWare, Microsoft ou encore Tableau (une liste plus exhaustive est disponible ici contenant leur réponse immédiate à la découverte de cette faille), mais également des logiciels plus stratégiques utilisés par les gouvernements (Défense, Énergie …).
Selon une étude d’Oracle de 2018, 90% des 500 plus grosses entreprises utilisent du code JAVA.
Comment cela a-t-il pu arriver ?
Il faut se rappeler que Log4J n’est pas un produit commercial à proprement parler. Il est, en effet, sous License Apache 2.0, une license open source originalement certifiée par l’Apache Software Foundation (une fondation à but non lucratif).
Log4J est donc une librairie Java open source qui est un noyau central pour la plupart des Framework Java existant (Struts 2 entre autres) et de solutions commerciales revendues à travers le monde (SAP, VMWare, AWS, …).
Ce composant est ainsi maintenu par un nombre restreint de contributeurs (pour la très grande majorité de manière bénévole), inversement proportionnel au nombre faramineux d’utilisateurs finaux …
Le cas de Log4shell a fait grand bruit, mais le problème n’est pas encore prêt d’être résolu!
En effet, entre les SI (Systèmes d’Information) qui ne connaissent pas forcément leurs outils (peur de la migration), ne veulent pas mettre à jour leur système, car « ça marche très bien comme ça » / « les problèmes de cybersécurité n’arrivent qu’aux grands groupes pas à nous » (ou pas) ou encore tout simplement, parce qu’ils n’ont pas à disposition du personnel suffisamment qualifié pour gérer/réfléchir à cette question. Cette faille a donc encore de beaux jours d’exploitation devant elle…
Cependant, combien de logiciels utilisent des outils/ librairies open source sans savoir réellement ce qui est derrière? Ce qui est testé? Approuvé? Et par qui?
Welcome to the Jungle ou les dessous du monde de l’open source !
Dans le monde de l’open source, il est à la charge de chaque « créateur » de définir les règles à imposer sur son composant (règles de nommage, règles de sécurité, revue de code, autorisation et droits des contributeurs sur les dépôts de code source …). Aucune norme officielle n’existe pour harmoniser tout ça.
La fondation Linux a publié l’an dernier un rapport sur les 20 composants (10 JavaScript, et 10 non JS) open source les plus utilisés à travers le monde. Elle a ainsi commencé à initier une projection des standards que l’on pourrait mettre en place dans le monde de l’open source.
Plus récemment, la Maison-Blanche s’est également penchée sérieusement sur la question. En effet, elle a tenu un premier colloque le 14 janvier dernier avec de grands noms du secteur des TI (Amazon, Apple, GitHub, Google, IBM, Microsoft, Oracle, Red Hat, VMWare, …) afin de se poser la question (entre autres) de « Comment prévenir les vulnérabilités dans les composants open source ? ».
L’open source peut être une très bonne chose (sa popularité le démontre), mais tout comme l’adolescent qui finit sa période de rébellion et va vers sa phase plus adulte/mature, le modèle open source doit évoluer vers une normalisation, un standard qui le cadrera. Cela en facilitera son utilisation, sa sécurité et sera un gage de qualité supplémentaire aux yeux de ses utilisateurs.
Mais si l’open source doit mûrir, il en va de même pour nous. Nous devons changer nos habitudes et être des consommateurs responsables des composants que nous introduisons dans nos projets et en maitriser le contenu.
Combien de sociétés n’auraient pas été au fait de cette faille si cette dernière n’avait pas été médiatisée? Combien de temps et d’argent ont été, est, ou vont être utilisés pour vérifier toutes les dépendances des projets ? Combien de projets resteront encore permissibles face à ce vecteur d’attaque?
Énormément de temps, d’argent, de stress pourraient être épargnés si une maitrise des composants tiers était établie et suivie dans les projets.
L’un des moyens les plus simples (en dehors d’un fichier Excel sur un obscur répertoire réseau) et efficaces sera de passer par une étape d’intégration continue qui répertoriera les différents artefacts utilisés. D’autant plus que de nombreux outils DevOps permettent de continuellement auditer ces composants et de remonter des alertes si l’un d’eux n’est pas/plus suffisamment sécurisé!
Car désormais le nerf de la guerre en développement, ou en tout cas en livraison de produit, est la garantie suffisante d’une sécurisation des outils proposés.
Crédit photo en-tête de l’article: Lunasec (licence)