Les révélations entourant Log4Shell en décembre 2021 ont mis en évidence une vulnérabilité critique dans Apache Log4j, une bibliothèque de journalisation utilisée par des applications Java. Identifiée par CVE-2021-44228, elle pouvait permettre l’exécution de code à distance dans les logiciels concernés. Des organismes de cybersécurité ont publié des alertes pendant l’identification des produits vulnérables.
Identifier le composant, pas seulement le langage du site
Log4j est une bibliothèque Java. Log4Shell ne constituait pas une faille de PHP lui-même. Le nom Apache ne signifiait pas non plus que toutes les installations d’Apache HTTP Server étaient touchées. Il fallait déterminer si une application ou un service dont elle dépendait intégrait le composant concerné.
Un site peut utiliser d’autres logiciels pour la recherche, les rapports ou les traitements d’arrière-plan. Examiner uniquement l’application publique peut laisser de côté une dépendance. À l’inverse, la présence d’un site ne prouve pas que Log4j est installé ou vulnérable.
Suivre la méthode de correction de l’éditeur
Apache a identifié les composants et versions affectés. D’autres problèmes Log4j et des correctifs révisés ont suivi la première divulgation. Les indications actuelles de l’éditeur étaient donc préférables à un contournement ponctuel ou à la première version d’urgence considérée comme solution définitive.
Un logiciel distribué avec ses dépendances peut nécessiter une mise à jour applicative pour remplacer la bibliothèque intégrée. Mettre à jour Java ne remplace pas nécessairement Log4j dans le produit. Le responsable doit confirmer la méthode prise en charge et vérifier la version obtenue.
Les questions utiles aux responsables applicatifs
Conservez un inventaire des applications et de leurs fournisseurs. Lorsqu’un avis nomme un composant partagé, demandez s’il est intégré aux produits utilisés, quelles versions sont affectées et comment le correctif est vérifié. Incluez les serveurs distincts et les conteneurs.
Pour un système potentiellement exposé, corriger le logiciel et rechercher une compromission sont deux tâches distinctes. CISA recommandait de mettre à jour les produits et d’examiner les signes d’exploitation. Une mise à jour ne prouve pas ce qui s’est produit avant son installation.
Log4Shell a montré l’importance de connaître les dépendances. Pour une intervention actuelle, suivez les indications maintenues par Apache et l’éditeur, plutôt qu’une ancienne version minimale. Déterminez l’exposition à partir des logiciels réellement présents et conservez les éléments qui appuient cette conclusion.
La leçon pour l’entreprise est de pouvoir agir sur un avis urgent sans deviner quels logiciels sont présents. Les services d’impartition TI de Nuagerie peuvent aider à organiser les responsabilités, les priorités d’entretien et les suivis auprès des fournisseurs. Un examen utile distingue les correctifs confirmés des questions encore à documenter pour orienter le travail vers les bonnes applications.
Commencez par les noms et versions des produits essentiels à vos activités, ainsi que leurs responsables. Si un avis concerne un service détenu chez Nuagerie, transmettez ces précisions et la référence officielle dans l’espace client. Le soutien dispose ainsi d’une question claire, sans présumer que tous les produits liés à Java présentent la même exposition ou se corrigent de la même façon.
