Log4shell ou les conséquences de composants préfabriqués non sécurisés
L’exposé des faits
Dans une dépêche, Bloomberg signalait être informé qu’un courriel alarmant fut adressé à la communauté open source Apache, le 24 novembre dernier, de la part d’un employé de l’équipe de sécurité cloud de la société Alibaba Group Holding Ltd, le Dr. Chen Zhaojun. Celui-ci mentionnait, d’une manière laconique : « je souhaite signaler un bug de sécurité … La vulnérabilité a un impact majeur. ». Dans un premier temps, Gary Gregory, qui a travaillé pendant une décennie sur le projet incriminé, nommé « logging for JAVA », abrégé en Log4J, considérait que Chen Zhaojun criait au loup, puisque personne n’avait jamais rien signalé de grave au sujet de ce projet, Log4J, une bibliothèque de journalisation pour les projets JAVA, plébiscité par toutes les communautés de développeurs. La suite démontrait, qu’avec la faille Heartbleed (2014), celle de Struts (2017), les failles de Log4J (2021) constituaient les pires brèches identifiées de la décennie.
L’importance des projets JAVA
Voyons plus précisément de quoi il en retourne et d’abord mesurons l’importance des projets JAVA.
JAVA est un langage de programmation qui demeure depuis des années parmi les plus utilisés par les développeurs. A l’heure actuelle, l’indice de popularité, nommé TIOBE index, le place en permanence dans le Top 5. Ce contexte industriel implique des pratiques de mutualisation pour des composants utilitaires très ordinaires comme ceux qui assurent la traçabilité des activités, les logs. C’est le cas de la bibliothèque Log4J . Ces logs sont essentiels pour la surveillance du bon fonctionnement et pour la conformité réglementaire. Ces mises en commun permettent aux développeurs de se concentrer sur le code à valeur ajoutée des projets.
L’utilisation de composants préfabriqués
Le revers de la médaille consiste à engendrer de nombreuses dépendances entre les composants « prêt à intégrer » et les projets. Ce puzzle nécessite une gestion rigoureuse des matériaux logiciels, qui s’effectue par l’intermédiaire d’une Software Bill of Materials (SBOM), une nomenclature des logiciels, qui dresse la liste exhaustive des briques logicielles utilisées. A l’heure du Cloud et de la co-création, la communauté JAVA dispose de registres centraux publics, dont l’un des principaux est Maven Central Repository (Maven est un outil de gestion des dépendances qui facilite le bon assemblage automatisé des briques logicielles).
Les répercussions d’une faille majeure dans un composants préfabriqué très utilisé
Google, l’un des principaux sponsors de Maven Central, mentionne que 8% des packages JAVA utilisent des versions vulnérables de Log4J. Par comparaison, les failles majeures détectées jusqu’alors ne compromettaient que 2%, au plus, des packages JAVA. Ceci représente de l’ordre de 35000 packages JAVA compromis dont seulement 7000 sont directement liés à la bibliothèque Log4J. Les autres packages, la grande majorité, qui constituent des dépendances de second niveau, sont rattachés, eux-mêmes, à Log4J.
Un passe-partout offert en cadeau aux pirates fin 2021
Sans entrer dans l’analyse des mécanismes d’exploitation de ces failles, disons que l’attaque est une attaque par injection. La vulnérabilité CVE-2021-44228 / Log4Shell consiste à injecter sur un logiciel vulnérable une charge malveillante, qui va demander à Log4J d’aller chercher une valeur issue d’une source tierce, avec JNDI (JAVA Naming and Directory Interface), et via un protocole comme LDAP, DNS, RMI, CORBA… Or, dans ce cas, Log4J ne vérifie pas assez bien les données importées. Les données importées peuvent alors être du code, qui sera exécuté par Log4J sur le système. Ceci ouvre la porte à toutes sortes de malversations dont l’utilisation de ransomwares. Soulignons que divers groupes de corsaires étatiques, comme le célèbre Conti, élaborent une utilisation de grande ampleur des vulnérabilités de Log4J.
Log4shell est un véritable passe-partout mis à disposition de nombreux pirates.
