Les clés pour comprendre Log4Shell et ses conséquences

Introduction

Divulguée par l’équipe de sécurité d’Alibaba le 9 décembre 2021, la vulnérabilité Log4Shell, en raison de son ampleur, a cristallisé les tensions concernant l’ensemble des pratiques de cybersécurité dans les entreprises, les agences gouvernementales et les organisations open source. Pressées par la couverture médiatique, les entreprises ont sonné l’alerte générale entre le 13 et le 14 décembre. Comme cette vulnérabilité a ciblé Log4j 2, une bibliothèque open source très populaire servant à récolter des logs et des traces dans les applications Java, la très grande majorité des entreprises, des éditeurs et une bonne part de projets open source ont été touchés. Cette faille et d’autres découvertes par la suite ont été activement exploitées par les cyberattaquants..

La petite équipe derrière Log4j 2 a travaillé d’arrache-pied pour proposer des correctifs, que les éditeurs et les entreprises ont dû ensuite déployer rapidement. En parallèle, ils ont mis en place les parades nécessaires à la détection et au blocage des attaques effectuées à travers ce canal. Pour autant, la vulnérabilité demeure. Elle serait devenue « endémique » selon un rapport du Cyber Safety Review Board rendu public en juillet dernier ; Log4Shell demeure active et peut encore faire l’objet d’exploitation par les cyberattaquants. Selon un rapport mené par le spécialiste de la gestion des vulnérabilités Qualys, 30 % des instances Log4j 2 n’étaient pas encore mises à jour en mars 2022.

Donnant raison aux inquiétudes gouvernementales américaines, Log4Shell n’a fait qu’accélérer la prise de mesure pour renforcer la sécurité logicielle au sein des agences gouvernementales et des sous-traitants au service des États-Unis. En entreprise et chez les éditeurs, ces vulnérabilités d’ampleur entraînent une prise de conscience progressive du renforcement nécessaire des pratiques de cybersécurité. Les spécialistes et les éditeurs recommandent en particulier l’adoption des approches DevSecOps et Zero Trust. 

Log4Shell est devenu un symbole, une empreinte dans la mémoire collective des développeurs. Il est même possible d’acheter sur le Web une casquette portant la mention : « I survived Log4j 2 ».

Mais la vulnérabilité n’a été qu’un révélateur. De nombreux problèmes subsistent. Si dans l’ensemble, toutes les parties prenantes ont joué le jeu, cet épisode a mis en lumière plusieurs enjeux liés à la sécurité des projets open source, la protection de la supply chain logicielle, l’application des patchs, des règles de conformité et les relations parfois difficiles entre les entreprises et leurs fournisseurs logiciels. Sans oublier de mentionner les ambivalences envers les chercheurs découvrant ces failles. Applaudi, leur travail n’est pas forcément valorisé à sa juste valeur.

Ce guide essentiel rappelle ce qu’est Log4Shell et établit une chronologie des faits. Outre les mesures prises par l’administration américaine et les réactions des entreprises, il évoque les mesures prises au sein des fondations open source pour renforcer la sécurité des projets et résoudre plus rapidement ces vulnérabilités. Enfin, il met en lumière l’adoption croissante des nomenclatures logicielles (SBOM) et des nouvelles pratiques associées à l’approche DevSecOps.

1Contexte-

Log4Shell : le déroulé des faits

2Réactions et mesures-

Un appel à la standardisation de la sécurité et des patchs

3Un enjeu majeur-

La sécurité et le financement de l’open source

4DevSecOps-

Une prise de conscience progressive