De très nombreux articles expliquent comment corriger la faille Log4j et mentionnent la saga des mises à jour de sécurité fournies par Apache.

Lorsqu’un adversaire est en mesure d’exploiter cette vulnérabilité (ou une autre), il peut installer des codes malicieux,  exfiltrer des données sensibles, et même supprimer des copies de sauvegarde.

Et la question est alors, comment allons-vous vous relever, en combien de temps, et avec quelle fraicheur de données?

Historique

Le 10 décembre 2021, Apache a publié un bulletin de sécurité soulignant une vulnérabilité critique menant à l’exécution de code à distance liée à Log4j, un outil libre de journalisation JAVA très largement déployé.

La vulnérabilité identifiée en tant que CVE-2021-44228 est excessivement critique, avec un score CVSS de 10, le plus haut niveau de sévérité possible.

Il a été déterminé que la première mise à jour de sécurité Log4j 2.15.0 était elle-même vulnérable dans certaines configurations.  S’en est suivi Log4j version 2.16.0 pour corriger cette dernière vulnérabilité, identifiée comme CVE-2021-45046.

Et enfin, Apache a mis à disposition ce vendredi 17 décembre la version 2.17.0 , qui corrige une vulnérabilité de déni de service identifiée comme CVE-2021- 45105 (score CVSS de 7.5), ce qui en fait la troisième faille de Log 4j2 à être découverte après CVE-2021-45046 et CVE-2021-44228.  

Enjeux

Les risques sont tels que les gouvernements du Québec et du Canada ont mis hors ligne plusieurs centaines sites pour valider la présence de Log4j et effectuer les corrections requises.

Et plus généralement, la majorité des entreprises offrant ou utilisant des solutions web est ainsi directement affectée.

C’est dire que les organisations affectées sont excessivement nombreuses.

Il ne faut pas pour autant oublier qu’indirectement, cette vulnérabilité affecte les données et les renseignements personnels des usagers détenus par les organisations de tous types.  

Démarche

Les étapes suivantes devraient être mises en place :

Identifier les applications utilisant le service Log4j

Il s’agit de rechercher sur tous les serveurs le fichier Log4j2, et de vérifier s'il s'agit d'une version vulnérable.

Mettre à jour les applications

La version 2.17.0 de Log4j a été publiée et est disponible au téléchargement.

Mais il demeure qu’avant d’être tiré d’affaire,  vous devez surmonter 2 défis à savoir :

• Vous pourriez subir une attaque avant d’avoir effectué toutes les mises à jour, en particulier lorsque les fournisseurs tardent à publier les correctifs de sécurités pour leurs applications utilisant Log4j.
• Si l'un des dversaires télécharge des codes malicieux sur vos serveurs, vous devez disposer d’une stratégie de récupération adaptée.

Mettre en place une stratégie de recouvrement

Votre capacité de recouvrement est essentiellement fonction de 3 facteurs :

La garantie de disposer d’une copie de sécurité intègre

Vous devez utiliser les meilleures pratiques en particulier celles associées la recommandation 3-2-1-1-0.

La fraicheur de vos données

Les solutions de protection de données modernes, telles que celle de Datto, vous permettent de prendre des copies aux 5 minutes.

Le temps de remise en production

Que ce soit localement ou dans le Cloud de Datto en cas de désastre de site, vous êtes en mesure d’assurer la continuité de vos activités.

Conclusion

Nous le savons bien. Ce n’est ni la première faille majeure ni la dernière à survenir.

Et même s’il vaut mieux prévenir que guérir, tôt ou tard, vous risquez d’être frappés,  ne serait-ce que parce que notre vitesse de réaction est souvent inférieure à la vitesse d’attaque des adversaires.

Il est temps de préparer votre infrastructure aux prochaines menaces avec une solution gérée de continuités des affaires.